el adás vázlat szerz k: beszédes Árpád és ferenc …tar.inter-studium.hu/csharp/oo.pdf•...

Objektumorientált nyelvek és módszertanok

Előadás vázlat

Szerzők: Beszédes Árpád és Ferenc Rudolf

Készült a Sysdata Kft. 2001/2002-es oktatói ösztöndíjának támogatásával

2002.03.04

2002

Tartalomjegyzék:

1 BEVEZETÉS ................................................................................................................ 5

2 OBJEKTUMORIENTÁLT ANALÍZIS ÉS DESIGN................................................. 7

2.1 BEVEZETÉS.............................................................................................................. 7 2.2 VIZUÁLIS MODELLEZÉS ............................................................................................ 8 2.3 A FOLYAMAT......................................................................................................... 10 2.4 UNIFIED MODELING LANGUAGE............................................................................. 16 2.5 A „KURZUSFELVÉTEL” PÉLDAPROJEKT ................................................................... 37

3 OBJEKTUMKOMPONENS TECHNOLÓGIÁK .................................................... 65

3.1 BEVEZETÉS............................................................................................................ 65 3.2 CORBA................................................................................................................ 66

4 OBJEKTUMORIENTÁLT NYELVEK.................................................................... 71

4.1 BEVEZETÉS............................................................................................................ 71 4.2 ABSZTRAKCIÓ ....................................................................................................... 72 4.3 OOP JELLEMZŐI .................................................................................................... 72 4.4 JAVA BEVEZETÉS ................................................................................................... 75 4.5 JAVA ÉS AZ INTERNET ............................................................................................ 77 4.6 JAVA ALKALMAZÁSOK........................................................................................... 78 4.7 MINDEN OBJEKTUM… ........................................................................................... 79 4.8 PROGRAMFUTÁS VEZÉRLÉS .................................................................................... 83 4.9 IMPLEMENTÁCIÓ ELREJTÉSE ................................................................................... 88 4.10 OSZTÁLYOK ÚJRAFELHASZNÁLÁSA ........................................................................ 91 4.11 POLIMORFIZMUS.................................................................................................... 94 4.12 INTERFÉSZEK ÉS BELSŐ OSZTÁLYOK ....................................................................... 96 4.13 OBJEKTUMOK TÁROLÁSA: KOLLEKCIÓK (KONTÉNEREK) ......................................... 98 4.14 HIBAKEZELÉS KIVÉTELEKKEL .............................................................................. 104 4.15 EGYÉB JAVA TECHNOLÓGIÁK ............................................................................... 106

1 Bevezetés 5

Objektumorientált nyelvek és módszertanok 2002, Beszédes Árpád és Ferenc Rudolf

1 Bevezetés

Az Objektumorientált (OO) programozás nem új keletű. A hagyományos szemlélet szerint az objektumorientáltság több mint egyszerűen osztályokkal és objektumokkal bővített procedurális nyelv; új szemléletmódra van szükség. Ez a szemléletmód az Objektumorientált Paradigma (OOP). Számos megfogalmazás született arra, hogy mi képezi az alapját az OOP-nek. Leginkább az alábbi három tulajdonságot tekintik ennek a szemléletmódnak az alapját: öröklődés, egységbezárás és többalakúság (polimorfizmus).

Napjainkban már az ilyen jellegű megközelítés már nem tekinthető teljesnek. Valójában, nagyon nagy területet ölel fel az objektumorientáltság fogalma: számos OO programnyelv létezik, szoftverfejlesztési módszertanok vannak, és egyéb technológiák is. Jelen kurzus egy szűk keresztmetszetét nyújthatja csak ennek a témának, a hangsúly néhány modern technológián lesz. Az első részben az objektumorientált analízis és tervezés (A/D) alapjaival ismerkedhet meg az olvasó, különös tekintettel a vizuális modellezés fontosságára, konkrét módszertan (RUP), illetve modellező nyelv (UML) bemutatásával. A második rész témája az objektumkomponens technológiák rövid ismertetése, a CORBA részletesebb bemutatásával. A kurzus záró részében az objektumorientált nyelvek tulajdonságaival foglalkozunk, a Java nyelv bemutatásán keresztül. A fenti három téma közötti kapcsolatok, és egymásra való épülésük is bemutatásra kerülnek annak érdekében, hogy az olvasó elsajátíthassa azt, hogy hogyan lehet valós méretű objektumorientált szoftverrendszereket hatékonyan elkészíteni.

Mindazonáltal, a hagyományos értelemben vett OO programozási technikákkal, mint pl. az öröklődés és a polimorfizmus helyes használata, nem foglalkozunk! Ezekre számos jó anyag jelent meg az elmúlt években. Természetesen, ez a képesség számos egyéb területtől is függ: pl. a procedurális programozás és a hagyományos algoritmusok és adatszerkezetek ismeretei továbbra is fontosak, illetve néhány egyéb újabb programozás- és programfejlesztési technika is nélkülözhetetlen lehet, mint pl. a generikus programozás.

Az alábbi ábrán láthatjuk, hogyan épülnek az OO szoftverfejlesztési módszertanok a klasszikus OOP elemeire, valamint azt, hogy egy szoftverfejlesztési ciklus analízis és tervezési (design) tevékenységei ezeket a módszertanokat alkalmazzák. Így jutunk el a modellezés fogalmához, amely alapvető módjának bizonyult a hatékony objektumorientált szoftverfejlesztésnek. Ezen témákkal indítjuk a következő fejezetet.

Klasszikus OO paradigma

OO módszertanok

Analízis és Design

programozási nyelvek, technológiák

magasabb szintű (vizuális) nyelvek, technológiák, folyamatok

modellezés

Klasszikus OO paradigma

OO módszertanok

Analízis és Design

programozási nyelvek, technológiák

magasabb szintű (vizuális) nyelvek, technológiák, folyamatok

modellezés

2 Objektumorientált analízis és design 7


2 Objektumorientált analízis és design

2.1 Bevezetés Egy teljes szoftverfejlesztési ciklus során elvégzendő tevékenységek általában különböző jellegűek, pl. a kezdeti fázisokban általában magasabb absztrakciókban gondolkodunk, míg a fejlesztési ciklus végére konkrét implementáció szintű problémákat kell megoldani. Objektumorientált rendszerek fejlesztésére különösképpen jellemző az alábbi két típusú gondolkodás és tevékenység:

• Analízis szintű gondolkodás. Egy szoftver fejlesztésének korai fázisaiban a megvalósítandó rendszer feladatait szeretnénk feltérképezni, azok funkcionális és egyéb jellegű követelményeit. Más szóval, a kérdés ilyenkor az, hogy a rendszernek mit kellene tennie. Ilyenkor határozzuk meg a szoftver (formális és informális) specifikációját, majd abból kiindulva kezdjük magasabb szintű absztrakciók segítségével előállítani a rendszer modelljét, amely a konkrét megvalósítás alapját fogja képezni.

• Tervezés (design) szintű gondolkodás. A meglévő (és folyamatosan fejlődő) modell alapján a szoftver konkrét implementációjához vezető utat tervezzük meg. Ilyenkor már arra keressük a választ, hogy a meghatározott specifikációt hogyan valósítsa meg a rendszer. Ezen a szinten már képbe kerülnek különböző alacsonyabb szintű technológiák is, mint pl. a kommunikációs protokollok és programozási nyelvek és technológiák.

Az analízis és tervezési tevékenységek hatékony és célszerű sorrendjét és módját különböző módszerekkel és folyamatokkal kell vezérelni. Az alábbiakban megadunk néhány alapfogalom általánosan használt értelmezését.

• Folyamat (Process). A fejlesztési életciklust irányítja, meghatározza annak lépéseit és a lépések sorrendjét.

• Jelölésrendszer (Notation). A jelölésrendszer szintaktikai és szemantikai szabályok összessége (más szóval egy nyelv), amely a fejlesztési ciklus során alkalmazható a terv elkészítéséhez vizuális eszközök segítségével.

• Módszer (Method). Általában egy folyamat és a hozzátartozó jelölésrendszer együttesét módszernek szokás nevezni. Általában egy jól definiált területen belül alkalmazható.

• Módszertan (Methodology). Nagyobb területet fed le, és sok esetben független az alkalmazás területétől. Valójában módszerek csoportja.

Módszerekből (és módszertanokból) számos fajta létezik. Így megkülönböztetünk strukturált, adatvezérelt, objektumorientált, stb. módszereket. Nem ritkán CASE eszközök definiálják, illetve használják saját módszertanaikat, azonban az utóbbi időben egyre jelentősebb az a törekvés, hogy szabványos módszerek, módszertanok legyenek széleskörűen használva. Az alábbiakban néhány példát sorolunk fel ismertebb módszerekre és módszertanokra:

• SA/SD módszer, Jackson (JSD) módszer

8 2.2 Vizuális modellezés

2002, Beszédes Árpád és Ferenc Rudolf Objektumorientált nyelvek és módszertanok

• SSADM módszertan (információs rendszereknél alkalmazandó)

• Metis Design módszertan (OO információs rendszerek)

• OMT (UML egyik elődje)

2.1.1 Hivatkozások

Terry Quatrani: Visual Modeling With Rational Rose and UML

• Addison-Wesley, 1998

Martin Fowler: UML Distilled Second Edition

• Addison-Wesley, 2000

OMG Unified Modeling Language Specification, Version 1.4

• Objecet Management Group, 2001

Cris Kobryn, et al.: Object Modeling with OMG UML Tutorial Series

• OMG, 1999-2001

Gary K. Evans: A Simplified Approach to RUP (fordította Győrbíró Norbert, 2002)

• http://www.therationaledge.com/content/jan_01/t_rup_ge.html

Web címek:

• http://www.rational.com/

• http://www.omg.com/

• http://www.uml.org/

• http://www.rational.com/products/rup/index.jsp

2.2 Vizuális modellezés

2.2.1 Miért modellezünk?

Hogyan lehet hatékonyan elkészíteni egy nagy méretű szoftverrendszert? Ahhoz, hogy ez a cél kezelhető legyen emberi mértékű befogadóképességgel, a megvalósítandó rendszert kisebb és a célnak megfelelő módon kell ábrázolnunk. Valójában ilyenkor a rendszer egy modelljét vizsgáljuk, és azon dolgozunk a végső megvalósításig. A modell egy adott probléma leírása a valós világból vett ötletekkel, ami azt jelenti, hogy a probléma kezelését a már megszokott problémamegoldó képességeinkre bízzuk annak érdekében, hogy azt minél hatékonyabban (ösztönszerűen) tegyük. Úgy is mondhatnánk, hogy amíg a szoftver teljes és abszolút specifikációja a számítógép számára maga a forráskód, addig nekünk embereknek egy könnyebben emészthető formában, a modellben tálaljuk.

Modellezéskor mindig a rendszer lényeges részeit vizsgálhatjuk, azokat amelyek a részfeladat megoldáshoz éppen a legalkalmasabbak. Ezzel egyidejűleg a skálázhatóság problémáját is megoldjuk, ugyanis egy való méretű szoftverrendszert (gondoljuk itt csak egy teljes banki ügyviteli-, vagy egy reptéri



irányító szoftverre) kisebb, ember által is feldolgozható részekre (nézetekre) bontjuk. Ezzel a módszerrel gyakorlatilag tetszőleges komplexitású rendszer modellezhető.

A szoftverfejlesztést mint modellezés akkor áll leginkább közelebb az emberi felfogóképességeinkhez, amikor vizuális eszközöket használunk, azaz szabványos grafikai eszközökkel végezzük a modellezést. Egy találó hasonlat szerint „1 bitmap = 1 megaword”, tehát ábrák segítségével sokszor könnyebben megérthető számunkra egy-egy probléma vagy megoldás.

Szokás a szoftver analízis és tervezés (modellezés) folyamatait sokkal inkább hasonlítani a mérnöki tudományokhoz, mint matematikai megközelítéshez. A mérnökök által használt tervezési módszerek sikeresen alkalmazhatók „szoftvermérnökök” esetében is. Jó példa erre az építészet. Egy felhőkarcolót építési tervdokumentáció nélkül képtelenség elkezdeni, míg egy kisebb szerszámtárolóhoz sokkal szerényebb terv is elegendő. Így van ez a szoftver esetében is: kis „példaprogramohoz” az ember nyilván nem készít tervet, viszont nagy méretű és bonyolultságú rendszerhez annál inkább. Mint ahogy az építészetben is több különböző szempont szerint kell a terveket elkészíteni (statikai, elektromos, …), a szoftvertervezésnél is több „nézet” segítségével írjuk le a rendszert (szerkezeti, viselkedési, használati eset).

A fentieken kívül még számos előnye van a vizuális modellezésnek, pl.:

• Esettanulmányok a felhasználó szempontjából. Ez azt jelenti, hogy egy nem szoftver szakember is könnyen megértheti bizonyos részeit a modellnek.

• Üzleti folyamatok leírására is alkalmas (forráskód mentesen).

• Jó kommunikációs eszközt képez a szoftver fejlesztésében résztvevő szereplők között: mérnökök, kódolók, tesztelők, menedzserek, a megrendelő, jogászok, …

• Fejlesztési idő és rizikó csökkentése, amely nagy projektek esetében nem elhanyagolható (anyagi) szempont.

• Szoftver architektúra definiálása. A szoftver felépítését több szemszögből lehet megjeleníteni.

• Szoftver újrafelhasználhatóság. Az objektumorientáltság hagyományos előnyein kívül (öröklődés, egységbezárás), itt még jobban jellemző az újrafelhasználhatóság, csak nagyobb méretekben (szoftverkomponensek).

2.2.2 A „siker háromszöge”

Ahhoz hogy a szoftverfejlesztési ciklus sikeres legyen az alábbi három dolog nélkülözhetetlen:

• Folyamat. A folyamat irányítja a szoftverfejlesztési ciklust, definiálja annak lépéseit és a lépések sorrendjét.

• Jelölésrendszer. Szabványos jelölésrendszer, amely leírja hogyan kell hogy kinézzen a tervezési dokumentáció.

• Eszköz. Szoftver, amellyel mindez elvégezhető.

10 2.3 A folyamat


JelölésrendszerJelölésrendszer((NotationNotation))

FolyamatFolyamat((ProcessProcess))

EszközEszköz((ToolTool))

��

��

JelölésrendszerJelölésrendszer((NotationNotation))

FolyamatFolyamat((ProcessProcess))

EszközEszköz((ToolTool))

��

��

A fenti ábra azt sugallja, hogy ha a három elem közül valamelyik is hiányzik, akkor a hatékony szoftverfejlesztés nem lehetséges: folyamat nélkül kaotikus a projekt, szabványos jelölésrendszer nélkül nincs jó kommunikáció, eszközre viszont mindig szükség van, ha más nem, legyen az papír és ceruza. A következő részben a folyamattal foglalkozunk (RUP), utána pedig a jelölésrendszer következik (UML).

2.3 A folyamat

2.3.1 Rational Unified Process

A siker háromszögének első és legfontosabb eleme a folyamat, hiszen az irányítja az egész szoftverfejlesztési életciklust. Leírja a végrehajtandó lépéseket és a végrehajtás sorrendjét. Valójában az ésszerű szoftverfejlesztés ésszerű módját írja le, amelyet sok gyakorlattal mi is elsajátíthatunk, de ebben segít a formális leírás. Két legfontosabb jellemzője, miszerint az előírt fejlesztési életciklus:

• Iteratív. Ez azt jelenti, hogy a szoftverfejlesztés kisebb mértékű „alprojektekre” van bontva, és ezek iteratívan követik egymást.

• Inkrementális. Az inkrementalitás azt jelenti, hogy minden iteráció után a szoftver egyre „jobb”, tehát a fejlesztés fokozatos.

A lényeg az, hogy az egyes iterációkra jobban lehet összpontosítani és jól definiált feladatokat kell elvégezni. Egyik alapvető irányelv az, hogy minden pillanatban jól tudjuk, hogy mi a célunk és merre halad a projektünk, tehát azt próbáljuk elkerülni, hogy a szoftver fejlesztése közben a végcél is változzon (ez megfelelő folyamat hiányában elkerülhetetlen és nagyon nem hatékony fejlesztéshez vezet).

Ha egy iteráció során valami probléma merül fel, akkor könnyebb a problémát kezelni, mert csak azon az alprojekten belül kell vizsgálódni. Minden iterációnak az a célja, hogy a részfeladat megoldásával közelebb kerüljünk a szoftver specifikált működéséhez. Minden iterációban az alábbi fő tevékenységeket kell elvégezni:

• követelmények gyűjtése az adott iteráció végével kapcsolatban

• analízis: a feladatok pontos kitűzése

• tervezés: a megoldás megtervezése

• implementáció: a terv megvalósítása (pl. kódolás)



• tesztelés: az adott iteráció követelményei megoldottak-e?

Ha a teszteléskor kiderül, hogy valami nincs rendben, akkor vissza lehet menni az iteráció elejére és megismételni azt. Egy-egy iteráció általában az egyik funkcionalitás megvalósítására vonatkozik, vagy valamely már meglévő funkcionalitás javítása a feladat. Ha az iteráció végrehajtása sikeres, akkor mondhatjuk, hogy egy részét megoldottuk a problémának vagy egy rizikót csökkentettünk (pl. hibát javítottunk). Az inkrementalitás tehát valójában a rizikó folyamatos csillapítását jelenti, mint ahogy azt az alábbi ábra is jól mutatja:

A fent vázolt folyamat valójában a Rational Unified Process (RUP) alapfilozófiáját követi. A RUP egy olyan egységes folyamat leírás, amely több már meglévő és jól működő folyamat egységesítésével jött létre, azok legjobb tulajdonságait átvéve (régebbi elnevezése a Rational Objectory Process).

A RUP nem más, mint irányelvek gyűjteménye, egy természetes nyelven íródott specifikáció. A szoftverfejlesztés különböző technikai és szervezési kérdéseivel foglalkozik, és betartásával a fejlesztési ciklus a lehető leghatékonyabban és költségkímélő módon végezhető el. A folyamat leírása két dimenzióba szerveződik:

• Idő. Egyrészt definiálja az iterációkat, és a főbb fázisokat a tervezés során.

• Fejlesztési elemek. Az időciklus során elvégzendő feladatok és aktivitások vannak leírva.

Az alábbi ábrán a fenti szerveződést láthatjuk:

12 2.3 A folyamat


Négy fő fázisa van a fejlesztési ciklusnak: kezdeti, kidolgozás, megvalósítás és átadás. Az első és az utolsó fázisok nem szigorúan a fejlesztés részei, hanem kiegészítő szakaszok. Az iterációk száma nincs rögzítve, az a konkrét feladattól függ. A kezdeti fázisokban különösen fontos az egyes iterációk megtervezése.

A fejlesztési elemek két kategóriába vannak osztva: valódi technikai folyamat komponensek (követelmények gyűjtése, analízis és tervezés, implementáció és tesztelés) és a kiegészítő szervezési komponensek (menedzsment, környezeti elemek és telepítés).

Az ábrából világosan látható az egyes elemek intenzitásának váltakozása az időciklus folyamán. Pl. a tesztelés iterációnként jellemző, de a végső fázisokban nyilván a legjelentősebb.

Maga a folyamat leírása nagy és szerteágazó annak érdekében, hogy a lehető legszélesebb körben alkalmazható legyen: különböző méretű és jellegű rendszerek tervezésére is alkalmas. Ez sajnos azt is maga után vonja, hogy viszonylag hosszú időre van szükség ahhoz, hogy elsajátítható legyen (bár, hosszútávon ez csakis jó befektetés lehet!). Az alábbiakban ismertetjük a RUP legszükségesebb lépéseit, amely ismerettel már a legtöbb esetben alkalmazható a módszer és ugyanakkor jó alapot is nyújt a teljes specifikáció elsajátításához [Evans nyomán]. Egyúttal eloszlatjuk a RUP méretéből adódó alkalmazási nehézség tévhitét is.

Ha a teljes RUP leírást látjuk, a következő kérdések merülhetnek fel a konkrét probléma megoldása kapcsán:

• mely lépéseket vegyem figyelembe?

• a lépések milyen sorrendben kövessék egymást?

• mik a legszükségesebb lépései a folyamatnak?

A RUP szerencsére „testreszabható”, jól adaptálható és hasznos lehet egy szoftverfejlesztő folyamatát javítani akaró cég számára, amennyiben megértik az alapokat.

A RUP alapját a következő (filozófiai) elvek adják:

• a szoftver projekt csapatnak előre kell tervezni

• mindenkinek és minden pillanatban tudnia kell merre tart a projekt



• a projektben felhalmozódó tudást egy tárolható és bővíthető formában kell rögzíteni

• a „legjobb módszerek” elve

A „legjobb módszerek” elve gyűjtőnév arra nézve, hogy mi a folyamat legracionálisabb felépítése. Ez nem más, mint a nagy tapasztalati tudással rendelkező szoftverfejlesztők „folklórja”, tehát az a módszer, amit nagy gyakorlat után az embernek a „józan paraszt ész” diktál. Ez egészben az a nagyszerű, hogy erre nem saját magunknak kell rájönni, mivel már mások leírták. Ez az elv szerint a következő tulajdonságai vannak a folyamatnak:

• Használati eset (Use case) vezérelt. A legfontosabb szempont a teljes folyamat során az, hogy maga a rendszer és a rendszer felhasználóinak kapcsolatai irányítják a lépéseket.

• Architektúra központú. Egy jól meghatározott architektúrára épül, az architektúra komponensei közötti kapcsolatok tisztázottak.

• Iteratív. A probléma és a megoldás kis részekre van bontva, minden iterációs ciklus egy ilyen kis részt céloz meg.

• Inkrementális. Mindegyik iterációs ciklus növekményesen épít az előző iteráció eredményére, így a rendszer egyre „jobb” lesz.

• Vezérelt. A legfontosabb, hogy az egész tevékenységet egy folyamat vezérli, ahol mindig lehet tudni mi a következő lépés. A menedzsment is lehet vezérelt, ha az összes eredmény, átadandó (deliverable), dokumentum és programkód konfigurációs menedzsment alatt van.

2.3.2 Az iterációk

(Az alábbi leírásban hivatkozunk a UML nyelv egyes elemeire, amelyek a 2.4 részben vannak ismertetve.)

Mint ahogy azt korábban is láttuk, az időciklus négy fő fázisra van osztva. Az első, kezdeti fázis a felkészülést jelenti (Inception Phase), valódi fejlesztés itt még nem történik. Itt legtöbb esetben egy iteráció van, a 0. iteráció. Ebben az iterációban lehetőség nyílik arra, hogy széltében és mélységében is megvizsgáljuk a rendszerrel szemben támasztott követelményeket és célokat. A legfontosabb célja ennek az iterációnak, hogy a megvalósíthatóságra becslést kapjunk, hogy egyáltalán bele vágjunk-e a fejlesztésbe. Általában a fejlesztést addig nem is kezdjük el, amíg a megtervezett architektúrát felépítő ötleteinkről bebizonyosodik, hogy helyesek és a rendszer üzleti modelljét teljes egészében megértettük.

A 0. iteráció lépései a következők:

1. Azonosítsuk a rendszer legfontosabb és szembeötlő funkcionális és nem-funkcionális követelményeit. Itt a felhasználó számára látható funkcionális követelményekhez készítjük el a használati eseteket. A használati esetek önmagukban azonban nem elegendőek, a nem-funkcionális követelményeket normál, szöveges dokumentumban rögzítjük.

2. Azonosítsuk a modellezni kívánt területhez (domain-hez) tartozó osztályokat. Az osztályok meghatározása a követelményekből többféleképpen is történhet: használhatunk CRC (Class/Responsibility/Collaborator) kártyákat,

14 2.3 A folyamat


adatbányászat segítségével is dolgozhatunk, előzetes területi (domain) tapasztalat alapján, vagy egyszerűen megkereshetjük a követelményeket tartalmazó dokumentumban a főneveket és a főneveket tartalmazó kifejezéseket. Próbáljunk ki több módszert is, az osztályok megtalálásához egy módszer ritkán elég.

3. Határozzuk meg az osztályok feladatát és az osztályok egymással való kapcsolatait. A feladatok az osztályok stratégiai céljai. Egy osztály feladata határozza meg, hogy milyen műveletei lesznek az osztálynak. A műveletek pedig meghatározzák az adattagokat. Soha ne az adattagok meghatározásával kezdjük egy osztály tervezését. Ez utóbbi adat-modellezés, nem pedig objektumorientált objektum-modellezés.

4. Készítsük el a terület osztálydiagramját (domain class diagram). A terület-osztálydiagram egy oldalnyi anyag osztályokkal és azok neveivel. Nem tartalmaz kapcsolatokat, műveleteket, sem adattagokat egyelőre. A feladatok definíciójával együtt ez a diagram egy közös szótárt nyújt a projekt számára.

5. Az összes eddig azonosított használati esetet (use case-t) és osztálydefinicíót tároljuk el egy OO CASE eszköz segítségével. Egy CASE eszköz használata minden nem-triviális projektben elengedhetetlen. Megkönnyíti a modellezést és az elkészített dokumentációk is áttekinthetők maradnak. Nagyon fontos, hogy a nagy rizikójú problémákat az első iterációkban dolgozzuk fel. A CASE eszköz ezek felismerésében is segít.

6. Keressük meg a legnagyobb rizikótényezőket, állítsuk fontossági sorrendbe az architektúra szempontjából jelentős használati eseteket és diagramokat. Ne foglalkozzunk az összes használati esettel és minden egyes részlettel. Azt a 20%-ot válasszuk ki, ami a 80%-t adja a legfontosabb rendszerfunkcióknak. A későbbi iterációkba vegyük bele a kevésbé fontos használati eseteket.

7. Osszuk fel a nagyobb használati eseteket és diagramokat az egyes iterációs ciklusok között (iterációk megtervezése). Minden iterációnak határozzuk meg a célját, a menetrendjét, a rizikóit és a kimenetét (eredményét).

8. Készítsünk egy iterációs tervet, amely meghatározza azt a „mini-projektet”, amit az egyes ciklusokban elkészítünk majd. Legyenek az iterációs ciklusok fókuszáltak és korlátosak (3-4 hét egy iterációra jó becslés). Törekedjünk arra, hogy minden iteráció egy mini-vízesés projekt legyen, részenként teljesítve a rendszer követelményeit. Minden egyes iteráció leírásának tartalmaznia kell a követelményeket, az analízist, tervezést, implementációt és a tesztelést.

A 0. iterációban a projekt teljes méretet és legfontosabb jellemzőit vizsgáltuk meg, és végeredményként egy „csináljuk – ne csináljuk” döntést hozunk a projekttel kapcsolatban.

Mint ahogyan azt már korábban említettük, a folyamat szerint a részleteket iteratívan alakítjuk ki, ami azt jelenti, hogy a további iterációk lépéseit ismételve hajtjuk végre minden egyes iterációban, ahogyan azt a kezdeti iteráció(k)ban megterveztük. Ezen iterációk mindegyikében szükség szerint analízis (mit csinál a rendszer) vagy tervezési (hogyan csinálja a rendszer) jellegű feladatokat végzünk el.

A további iterációk lépései a következők:



1. Teremtsünk kapcsolatot a használati esetekben található működési leírás és a terület-osztálydiagram között. Ezzel analízis-szintű kölcsönhatás diagramokat (szekvencia és együttműködési) hozunk létre az iterációban kijelölt minden egyes használati esetre. Ezen dinamikus diagramok használatának legnagyobb előnye, hogy segítenek megtalálni az osztályok műveleteit.

2. Próbáljuk ki és ellenőrizzük az analízis-szintű szekvencia diagramokat papíron, táblánál vagy a gépünk képernyőjén. Ez konkrétan azt jelenti, hogy kövessük az üzenetek folyását a kölcsönhatás diagramokon. Bővítsük az osztálydiagramokat a megtalált műveletekkel és adattagokkal. Ne foglalkozzunk teljesítmény vagy technológiai vonatkozásokkal az analízis fázisában. Az analízis során a problémákat derítjük fel, a tervezés során határozzuk meg a megoldást. Próbáljuk ezeket a fázisokat gondolatban is elkülöníteni.

3. Készítsünk analízis-szintű állapotátmeneti (statechart) diagramokat minden olyan osztályhoz, amely „kitüntetett” állapottal rendelkezik. Az állapotátmeneti diagramok egy osztály „állapotterét” határozzák meg, azaz egy objektummal foglalkoznak és ez már sokkal részletesebb leírás, mint a szekvencia diagramok esetében, ahol több objektum egymás közötti üzenetváltásait ábrázoljuk egy használati esetet megvalósítandó.

4. Bővítsük a szekvencia és állapotátmeneti diagramokat tervezési szintű tartalommal. A tervezés-szintű gondolkodásban az osztálydiagramokat és a szekvencia diagramokat bővítjük kiegészítő- és tervezés-szintű osztályokkal (tároló osztályok, GUI és más technikai osztályok, adattípusok, stb.) A tervezés során minden iterációban a teljesítményt és technikai meggondolásokat is figyelembe kell venni.

5. Próbáljuk ki a tervezési-szintű szekvencia és állapotátmeneti diagramokat. Ha új műveleteket vagy új adattagokat fedezünk fel, adjuk azokat hozzá a megfelelő osztályokhoz. A tervezés eredménye már tartalmaz konkrét operáció (metódus) neveket, paramétereket és visszatérési típust.

6. Frissítsük az OO CASE programunkban tárolt információkat és az új változatot a projekt többi tagjának is jutassuk el. Az összes diagramot és egyéb dokumentumot frissítsük az iteráció végén. A frissítést a projekt többi tagjához is jutassuk el. (A dokumentáció nem lehet 24 óránál régebbi!)

7. Implementáljuk a jelenlegi iterációban kijelölt használati eseteket az aktuális diagramok segítségével (programkódot elkészítése). Ne feledjük el, hogy a tervezés nem programkód készítés. A tervezés a szükséges előkészület a kódoláshoz.

8. Teszteljük a kódot az aktuális iterációban. A tesztelés folyamatos: teszteljünk a legfelső (projekt) szinten és a legkisebb (unit) szinten is.

9. Értékeljük ki az iteráció eredményeit. Az eredmény kiértékelése a legfontosabbakra koncentrálódjon: nézzük meg mi sikerült és mi nem az iteráció során. Sikerült-e elérni kitűzött célokat az iterációra vonatkozólag? Tovább tartott-e az iteráció a tervezettnél? Sikerült-e hozzáadni minden tervezett funkciót? Ha valami nem sikerült, határozzuk meg a probléma okát és javítsuk ki (szükség szerint visszatérve az aktuális iteráció korábbi lépései valamelyikére). Döntsük el, hogy tudjuk-e követni a meghatározott tervet. Ha nem, akkor megfelelően módosítsuk az iterációs tervet.

16 2.4 Unified Modeling Language


10. Lássunk neki a következő iterációnak az 1. lépéstől kezdve további használati esetek hozzávételével. Az iterációk 1–9 lépéseit addig hajtsuk végre, amíg rendszerünk teljesen el nem készül. Ez a lényege az iterációs és inkrementális fejlesztésnek: hajtsunk végre egy új iterációt, növekményesen építve az eddigi eredményekre.

A fent ismertetett folyamat nem tartalmazza az összes lépést, amely egy teljes, minimális RUP végrehajtásához szükséges. Egy járható utat mégis biztosít a UML és RUP fontosabb elemeinek megismerésére, megkönnyítve a további elemek elsajátítását, és ezáltal a folyamat későbbi igények szerinti testreszabását. Nem árt azonban szem előtt tartani, hogy a folyamat önmagában sem annak mechanikus alkalmazása a sikert nem garantálja. A fent leírt egyszerűsített változat azonban hasznos útmutató lehet a teljes RUP-ra való átálláshoz.

Összegzésként jegyezzük meg, hogy a folyamat alapfilozófiája nagyon egyszerű: tudd, hogy merre tartasz, és a feladatot részenként oldd meg! A legfontosabb szabály: a folyamat szolgálja a fejlesztést, és ne fordítva!

2.4 Unified Modeling Language

2.4.1 Bevezetés helyett: az architektúra

Ahogy az a korábbiakból ismeretes, a szoftverfejlesztés során a folyamat segítségével folyamatosan analizáljuk, tervezzük és építjük meg a rendszerünket. A folyamat közben azonban a rendszert minden pillanatban egy bizonyos szemszögből vizsgáljuk, attól függően, hogy éppen mi az aktuális vizsgálati szempont vagy fejlesztési cél. A modellezéskor keletkező modell, mint a rendszer teljes leírása ilyen nézetek (view) által jelenik meg a tervezési dokumentációban. Minden nézetre jellemző, hogy a rendszer architektúráját írja le a reá jellemző módon. Más szóval, amikor a nézetekről beszélünk, azokat együttesen rendszerarchitektúrának is nevezhetjük.

Ezen belül, az egyes nézetekben a jelölésrendszer által nyújtott diagramokat használjuk. Az alábbi ábra mutatja, ahogyan a folyamat vezérli a tervezést és ezáltal a rendszer architektúrája épül. Az architektúra különböző nézeteinek megvalósulásai maguk a diagramok, amiket a jelölésrendszer definiál.

Folyamat (RUP)

Architektúra (4+1)

Jelölés (UML)

Folyamat (RUP)

Architektúra (4+1)

Jelölés (UML)

Modellezéskor a rendszer architektúráját az alábbi alapvető nézet típusokkal írjuk le (az architektúra „4+1” nézete):



Elvi (log ikai) F iz ikai

Log ika i n ézet(Log ical Vie w )

V égfelh asz n á lóF unkciona li tás

K om p on en s n éze t(C om p on en t View )

P ro g ram oz ókS zoftve r m enedzsm en tÚ jra felhaszná lhatóság

P o rtab ilitás

F olyam at n ézet(P rocess V iew )

R en d sz er integ rá toro kT e ljes ítm ényS ká lázha tóságH iba tű rés

Te lep ítési n ézet(D ep loym en t View )

R en dsz er te rvez ésR endszertopo lóg ia

Á tadás, te lep ítésK apcso la tta rtás

H aszn á lati E set n éze t

(U se C ase V iew )

- Im ple me nta tio n

Elvi (log ikai) F iz ikai

Log ika i n ézet(Log ical Vie w )

V égfelh asz n á lóF unkciona li tás

K om p on en s n éze t(C om p on en t View )

P ro g ram oz ókS zoftve r m enedzsm en tÚ jra felhaszná lhatóság

P o rtab ilitás

F olyam at n ézet(P rocess V iew )

R en d sz er integ rá toro kT e ljes ítm ényS ká lázha tóságH iba tű rés

Te lep ítési n ézet(D ep loym en t View )

R en dsz er te rvez ésR endszertopo lóg ia

Á tadás, te lep ítésK apcso la tta rtás

H aszn á lati E set n éze t

(U se C ase V iew )

- Im ple me nta tio n

• Logikai nézet. A rendszer logikai szerkezeti felépítésének ábrázolására használatos. Szerkezeti és viselkedési modellezéskor tipikusan használt diagramfajta az osztálydiagram és a kölcsönhatás diagramok.

• Komponens (implementációs) nézet. Implementáció-közeli szerkezetet ábrázol, a használt diagramfajta a komponens diagram.

• Folyamat nézet. A folyamat egyéb jellemzőinek fenntartott nézet, különböző nem-funkcionális szempontok szerint ábrázolja az architektúrát: pl. futás közbeni kérdések.

• Telepítési (feladatkiosztási) nézet. Magasabb szintű fizikai nézet, a rendszer magas szintű szerkezetére vonatkozóan, telepítési diagram használatos.

• Használati eset nézet (esettanulmány). Az egészet összefogja és közös kommunikációs platformot létesít a résztvevő felek között. Használati eset- és kölcsönhatás diagramok alkalmasak.

Természetesen nem minden tervezendő rendszer igényli az összes nézet használatát. A folyamat határozza meg, hogy mely nézeteket és diagramok kell alkalmazni az egyes lépésekben. Másfelől, ha szükséges, új nézetek is definiálhatók, ha a rendszer speciális tulajdonságokkal rendelkezik (pl. adat, biztonság).

További fogalmak. Modellnek nevezzük a rendszer teljes leírását egy bizonyos szemszögből (a szoftverfejlesztéshez szükséges szempontok szerint), tehát a modell tartalmazza az elkészítendő szoftverrendszer szabványos ábrázolását. A modell egy-egy nézete adja az analízis és tervezés során szükséges vetületeket, például a fenti architektúra „4+1” nézetet. Maguk a diagramok (mint a jelölésrendszer alapelemei) ezen nézetek megvalósulásai. A diagramra jellemző, hogy:

• Mindig valamely résztvevő szemszögéből ábrázolja a rendszert, pl. tervező, kódoló, megrendelő, …

• Csak részleges reprezentációja a rendszernek.

• A modell egy-egy eleme több nézetben (diagramban) is megjelenhet egyidejűleg.



• Szemantikailag konzisztens a többi nézettel.

• Két alapvető nézet típust különböztetünk meg, amelyek általában minden diagramra vonatkoztathatók:

• osztályozási nézet, pl.

Element

Carbon Hydrogen

<<covalent>>

<<covalent>>C

C

C H

Element

Carbon Hydrogen

<<covalent>>

<<covalent>>C

C

C H

• példányosítási nézet, pl.

:Carbon :Carbon

:Hydrogen

:Hydrogen

:Hydrogen

:Hydrogen

:Hydrogen:Hydrogen

2.4.2 UML áttekintése

A UML (Unified Modeling Language) magyarul annyit jelent, mint egységesített modellező nyelv. Azért nyelv, mert egy nyelvezetet biztosít vizuális dokumentáció készítéséhez. Az általa definiált elemek, kapcsolatok, diagramok, stb. bizonyos szintaktikai és szemantikai szabályok összességének felelnek meg, mint minden más nyelv esetében is. Egy vizuális nyelv esetében a szintaktika a grafikus kinézetet jelenti, a szemantika meg a megjelenített elemeknek értelmezést ad és további szemantikai szabályokat definiál. A UML egységesített, mert számos korábban meglévő nyelv ötvözésével keletkezett, azokból kiragadva a legjobb tulajdonságokat. A UML egyik legfontosabb jó tulajdonsága éppen ez, ugyanis hatalmas tapasztalati tudásra épít. Ezáltal nyugodtak lehetünk afelől, hogy a nyelv alkalmazásával csakis nyerhetünk. Tehát a UML nem egy cég által kifejlesztett és jól marketingelt termék, hanem egy megbízható, és jól bevált módszer.

A UML olyan rendszerek kezelésére alkalmas, amelyek nagy mértékben szoftver alapúak (elvileg nem szoftver-jellegű elemek is használhatók). Konkrétan, ezen rendszerek elemeinek:

• vizualizálására,



• specifikálására,

• létrehozására, és

• dokumentálására használatos.

A UML nyílt szabványként tekinthető (Object Management Group – OMG által), hiszen a hivatalos specifikációjáért egy komoly testület felelős, amely mögött számos neves intézmény áll, mint pl. Rational, HP, IBM, Microsoft, Oracle, Platinum, TI, Sun, DEC, Compaq, stb. Ezen kívül, a nyelvet támogató szoftver-eszközök skálája is egyre bővül (pl. Rational Rose, Microsoft Visual Studio, Microsoft Visio, GDPro, Telelogic Tau, dia…).

A UML-nek számos nyilvánvaló előnye van, ezek közül néhány:

• Könnyű elsajátítani, de ugyanakkor tetszőleges bonyolultságú modelleket is lehet vele készíteni, különböző kifinomult technikák segítségével.

• Mindössze 10-20 % része van használva az esetek 80-90 %-ban, ami azt jelenti, hogy általában nem szükséges a teljes specifikációt ismerni, csak annak egy jól körülhatárolható részét.

• Implementációtól független tervezést tesz lehetővé.

• Teljes szoftverfejlesztési életciklust támogatja (ld. RUP).

• Különböző alkalmazás területeken használható alkalmazható: üzleti, valósidejű, beágyazott, stb.).

UML története. Számos módszertan és jelölés járult hozzá a UML létrejöttéhez, de alapvetően az OMT, Booch és OOSE módszerek egyesítésével jött létre 1995 októberében. Ezekből elsődlegesen a szemantikus modellek (mi az amit ábrázolni kell), a szintaktikus jelölések (grafikus megjelenés) és nyilván a diagramok lettek „unifikálva”. Az első szabványosított specifikációt (1.0) 1997 júliusában adta ki az OMG (Object Management Group). A jegyzet írásakor aktuális verzió az OMG UML 1.4 (2001 szeptember).

Maga a UML specifikáció egy vaskos dokumentum (az 1.4-es verzió 566 oldalas) és a következő főbb részei vannak:

• Jelölés (Notation). A szintaxist definiálja, azaz a jelölésrendszer elemeit.

• Szemantika (Semantics). A szintaxisnak értelmet ad, leírja az egyes jelölések jelentését.

• Object Constraint Language (OCL). További megszorítások megadására szolgáló nyelv definiálása, amellyel a UML hatékonyan bővíthető.

• Modellek cseréjére (szoftver eszközök együttműködésére) vonatkozó megoldások: XMI és CORBA IDL.

• Testreszabott UML. 2 speciális profile van definiálva (üzleti és valósidejű) a szabványos bővíthetőségi mechanizmusok segítségével.

• Standard elemek. Néhány elem előre van definiálva, mint „foglalt kulcsszavak”.

UML metamodell architektúra. A specifikáció egy háromszintű metamodell szerkezet segítségével definiálja a nyelvet. E rendszer lehetővé teszi a lehető



legáltalánosabb leírást és a bővíthetőséget is precízen definiálja. Azért előnyös a használata, mert mindegyik szinten maga a UML van használva a leírásra. A legfelső szint a meta-metamodell, amely azt írja le, hogyan kell a metamodell szinten definiálni a UML nyelvet. A második szint a metamodell, amely magát a UML nyelv szintaxisát írja le. Ez alatt helyezkedik el a felhasználó analízis szintű modellje a konkrét modellezési elemekkel. Ez alatt még elhelyezkedhet az objektumok rétege, ahol az analízis szintű modell osztályainak példányai szerepelnek. A specifikáció szempontjából a legfontosabb a metamodell, amely megfelelően csoportosítva részletesen leírja, hogy hogyan kell hogy kinézzenek az egyes UML diagramok.

<<metamodel>>MOF Meta-metamodel

<<metamodel>>UML Metamodel

User Model

:Foo

Meta-Metamodel Layer(M3): meta-meta-osztályok aUML metamodellhez

Metamodel Layer (M2):metaosztályoka UML modellhezpl. Class

Model Layer (M1):osztályok a felhasználómodelljéhezpl. Passenger, Ticket,TravelAgency

User Objects Layer (M0):Felhasználói objektumok,a UML model oszályainakpéldányai

:Bar :Baz

<<metamodel>>MOF Meta-metamodel

<<metamodel>>UML Metamodel

User Model

:Foo

Meta-Metamodel Layer(M3): meta-meta-osztályok aUML metamodellhez

Metamodel Layer (M2):metaosztályoka UML modellhezpl. Class

Model Layer (M1):osztályok a felhasználómodelljéhezpl. Passenger, Ticket,TravelAgency

User Objects Layer (M0):Felhasználói objektumok,a UML model oszályainakpéldányai

:Bar :Baz

A metamodell az alábbi építőkövek segítségével írja le a nyelvet. Minden használatos diagramfajtánál ezeknek valamilyen kombinációját alkalmazzák:

• Modellezési elemek. A modellezési elemek azok az entitások, amelyek valamilyen részét modellezik a rendszernek. A következő alapvető modellezési elemek léteznek:

� szerkezeti elemek: class, interface, collaboration, use case, component, node

� viselkedési elemek: interaction, state machine

� csoportosítási elemek: package, subsystem

� egyéb: note

• Kapcsolatok (relationships). A modellezési elemeket, mint csomópontokat összekötő élek. A kapcsolatok fajtái:

� függőségi kapcsolat (dependency)

� asszociációs kapcsolat (association)

� általánosítás, öröklődés (generalization)

� megvalósítás (realization)



• Bővíthetőség (Extensibility Mechanisms). A UML nyelv bővítésére nyújtott támogatások:

� sztereótípus (stereotype)

� címke-érték (tagged value)

� megszorítás (constraint)

• Diagramok. 9 diagramfajta van definiálva:

� Használati eset (Use Case D.). Funkcionalitás felhasználó szemszögéből.

� Osztálydiagram (Class D.). A rendszer „szótára”: osztályok és kapcsolataik.

� Objektum diagram (Object D.). Osztály példányok és kapcsolataik.

� Komponensdiagram (Component D.). Implementáció fizikai szerkezete.

� Telepítési diagram (Deployment D.). A rendszer hardver topológiája.

� Szekvenciadiagram (Sequence D.). Dinamikus viselkedés (idő-orientált).

� Együttműködési diagram (Collaboration D.). Dinamikus viselkedés (üzenet-orientált).

� Állapotátmeneti diagram (Statechart). Dinamikus viselkedés egy objektumra (esemény-orientált).

� Aktivitás diagram (Activity D.). Dinamikus viselkedés egy objektumra (aktivitás-orientált).

UM L d iag ram

S ta tiku s d iag ram

O sztály D .(C lass)

O b jektu m D .(O bject)

K om p on en s D .(Com p on en t)

Telep ítés i(D ep loym en t)

Din am iku s d iag ram

H aszn álati E se t(Use Case)

E g yüttmű köd és i(Co llab oration )

Ál lap otátm en eti(S tatech art)

S zekven c ia(S eq u en ce)

Aktivitás D .(Activity )

UM L d iag ram

S ta tiku s d iag ram

O sztály D .(C lass)

O b jektu m D .(O bject)

K om p on en s D .(Com p on en t)

Telep ítés i(D ep loym en t)

Din am iku s d iag ram

H aszn álati E se t(Use Case)

E g yüttmű köd és i(Co llab oration )

Ál lap otátm en eti(S tatech art)

S zekven c ia(S eq u en ce)

Aktivitás D .(Activity )

A fenti építőkövek segítségével nagyon sok szempontból leírható a modellezni kívánt rendszer. Általában három csoportra osztják a modellezés mibenlétét (és ezáltal a használt elemeket és diagramokat):

• Szerkezeti modellezés. Ez a fajta modellezést a rendszer szerkezetének leírásánál használják. Jellemző diagramok az osztály-, objektum-, komponens- és telepítési diagram.

• Használati eset modellezés. A rendszer viselkedésének leírására alkalmas ahogyan az kívülről látszik. Használati diagram használatos.



• Viselkedési modellezés. A rendszer (futás közbeni) viselkedésének leírásakor modellezünk ily módon.

Konzisztencia. A UML specifikáció különböző módon segíti azt, hogy a modell és a diagramok a modellezés minden pillanatában konzisztens maradjon. A legalapvetőbb szempont a UML által definiált szintaktikus és szemantikai szabályok betartása, azaz hogy a modell megfeleljen a nyelvnek. Ezen kívül, egyéb apróságoknak is fontos figyelmet szentelni, mint pl. a nevek stílusa, láthatósági szabályok betartása, a diagramok integritása, stb. Nagy segítség még az OCL OCL (Object Constraint Language), mint bővíthetőségi technika, mely segítségével pontosabbá tehető a modell. A specifikáció különböző szinteken segít:

• Először is, definiálja a jelölést (notation). Ez kötelezően betartandó. Ide tartozik pl. az, hogy egy asszociáció végpontot mivel lehet kiegészíteni.

• Megadja a lehetséges jelölési módozatokat, prezentáció (presentation options). Azt határozza meg, hogy a használható jelölés-kombinációknak melyek az értelmes módozatai.

• Stílus (style guidelines). További stilisztikai megoldásokat javasol, amelyek egységes megjelenésű ábrákat eredményez, pl. osztálynevek nagybetűvel kezdődjenek.

2.4.3 Szerkezeti modellezés

A rendszer olyan nézetét, amely az objektumok és egyéb dolgok szerkezetét írja le, szerkezeti modellnek nevezzük. Szerkezeti modellezéskor a rendszer vázát írjuk le, amely valójában a felépítést ábrázolja különböző szempontok szerint:

• logikai és fizikai szerkezet,

• különböző osztályozások (pl. osztálydiagram),

• objektumok szerkezete,

• kapcsolatok,

Egyik alapvető ismérve a szerkezeti modelleknek, hogy azok nem ábrázolnak semmiféle időtől való összefüggéseket, mint pl. állapotok, üzenetek, …

A szerkezeti modellek alapvető elemei a következők:

lem Leírás Szintaxis

sztály (class) azonos tulajdonságú objektumok halmazának leírása

nterface operációk nevesített halmaza, amely egy viselkedést ír le

«interface»«interface»

omponens component)

moduláris és cserélhető egysége a rendszernek, amely interfészeket implementál

somópont node)

futás közbeni fizikai feldolgozó egység



egszorítás constraint)

szemantikus feltétel vagy megszorítás {constraint}

A fenti elemeket a szerkezeti modellek kapcsolataival lehet összekapcsolni:

Elem Leírás Szintaxis

asszociáció (association)

kettő vagy több osztályozási elem közötti szemantikus kapcsolat, amely a létrejövő objektumok között fog összeköttetést eredményezni

aggregáció (aggregation)

speciális asszociáció, amely rész-egész kapcsolatot ír le

általánosítás (generalization)

osztályozó kapcsolat egy általánosabb és egy speciálisabb elem között

függőség (dependency)

két elem közötti kapcsolat, amelyeknél az egyik változása befolyásolja a másikat

megvalósítás (realization)

egy specifikáció és annak megvalósítása közötti kapcsolat (pl. osztály és interface)

A fenti elemek és kapcsolatok felhasználásával a következő szerkezeti diagramokat definiálja a UML:

• Statikus szerkezeti diagramok (logikai, elvi): osztálydiagram (class diagram) és objektum diagram (object diagram).

• Implementációs diagramok (fizikai): komponens diagram (component diagram) és telepítési diagram (deployment diagram).

Példák osztályokra:

Window

display ()

size: Areavisibility: Boolean

hide ()

Window

Window

+default-size: Rectangle#maximum-size: Rectangle

+create ()

+display ()

+size: Area = (100,100)#visibility: Boolean = true

+hide ()

-xptr: XWindow*

-attachXWindow(xwin:Xwindow*)

{abstract,author=Joe,status=tested}

Példák asszociációs kapcsolatra:



Person

Manages

JobCompany

boss

worker

employeeemployer1..∗

∗

∗

0..1

Job

Account

Person

Corporation

{Xor}

salary

Példák kapcsolat végpontjaira:

Polygon PointContains

{ordered}

3..∗1

GraphicsBundle

colortexturedensity

1

1

-bundle

+vertex

Példa kompozíciós kapcsolatra:

Window

scrollbar [2]: Slidertitle: Headerbody: Panel

Window

scrollbar title body

Header Panel

2 1 1

Slider

111

Példa az általánosítás kapcsolat (öröklődés) kétféle ábrázolására:



Shape

SplineEllipsePolygon

Shape

SplineEllipsePolygon

Shared Target Style

Separate Target Style

. . .

. . .

Példák függőségekre:

«friend»ClassA ClassB

ClassC

«instantiate»

«call»

ClassD

operationZ()«friend»

ClassD ClassE

«refine»ClassC combines

two logical classes

Controller

DiagramElements

DomainElements

GraphicsCore

«access»

«access»

«access»

«access»

«access»

Az objektum diagram olyan osztály diagram, amelyben csak objektumok szerepelnek és a közöttük levő összeköttetések (link). Példa objektumokra és objektum diagramra:



trian g le : P olyg on

cen te r = (0 ,0 )vertice s = ( (0 ,0 ),(4 ,0) ,( 4,3 ))bo rd e rC olo r = bla ckfillCo lo r = wh ite

tria ng le : P o lyg o n

tria ng le

:P olyg on

s ch ed u le r

horizontalBar:ScrollBar

verticalBar:ScrollBar

awindow : Window

surface:Pane

title:TitleBar

moves

moves

downhillSkiClub:Club Joe:Person

Jill:Person

Chris:Person

member

member

member

treasurer

officer

president

officer

Szerkezeti diagramok egyéb elemei közé tartoznak a megszorítások és megjegyzések, pl.:

Mem b e r-of

C h a ir-o f

{s ub s e t}P e rs o n Co mm itte e

P e rs o n Co m pa ny

b os s

{P e rs o n. em p loye r =P e rs o n.bo s s .e m p lo ye r}

em p loye re m p lo ye e

0 .. 1

∗ ∗

∗

∗

∗ 0 ..1

1

R ep re s e n tsa n in c o rpo ra te d e n tity.



Példa komponens diagramra:

<<ejbEntity>>Catalog

<<auxiliary>>CatalogInfo

<<focus>>Catalog

<<reside>> <<reside>>

<<auxiliary>>CatalogPK

<<reside>>

<<file>>CatalogJAR

<<implement>>

Példa telepítési diagramra:

backupServer:AppServer

backupBroker:BondBroker

:QuoteService <<database>>:AccountsDB

primaryServer:AppServer

primaryBroker:BondBroker

:QuoteService

<<database>>:AccountsDB

<<become>>

2.4.4 Használati eset modellezés

Használati eset modellezéskor a rendszer viselkedését írjuk le, ahogyan az egy külső szemlélő szemszögéből látszik. Ez azt jelenti, hogy a rendszer belső szerkezetéről vagy viselkedéséről nem tesz említést. Leírja a rendszer funkcionalitását, a főbb tevékenységeit és kapcsolatát a külvilággal. Használati eset modellezés a fejlesztési ciklus kezdeti fázisaira jellemző, amikor a rendszer funkcionalitását definiáljuk vagy fedjük fel.

Használati eset modellezésnek fő kellékei a használati esetek és a szereplők, amelyekből maguk a használati eset diagramok épülnek fel. A használati eset diagram jó kommunikációs eszköz a fejlesztőcsapat és egyéb résztvevők között.



A használati eset modellezés alapvető elemei a következők:


használati eset (use case)

tevékenységek sorozata, amelyet a rendszer végre tud hajtani a szereplőkkel kommunikálva

UseCaseName

szereplő (actor)

szerepek összefüggő halmaza, amelyeket a használati eseteket használók játszhatnak

ActorName

rendszerhatár fizikai rendszer és a szereplők közötti határvonal

A fenti elemeket összekötő kapcsolatok a következők:


asszociáció (association)

jelzi, hogy a szereplő részt vesz a használati esetben

általánosítás (generalization)

osztályozó kapcsolat egy általánosabb és egy speciálisabb elem között (itt: használati eset)

kibővítés (extend)

kibővített használati esettől alap használati eset felé (bővített tevékenység)

<<extend>><<extend>>

magábanfoglalás (include)

alap használati esettől magában foglalt használati eset felé (résztevékenység)

<<include>><<include>>

Példák használati eset diagramokra:

Cus tomer

Supe rviso r

S ales pe rso nPlace

Es ta bl is hc re di t

Che c k

Telep hone Catalog

Fill orders

S hipping Cle rk

s tatus

orde r



additional requests :

OrderProduct

Supply Arrange

«include»«include»«include»

RequestCatalog

«extend»Extension points

PaymentCustomer Data

after creation of the order

Place Order

1 * the salesperson asks forthe catalog

2.4.5 Viselkedési modellezés

A harmadik típusú modellezés a viselkedési modellezés, amikor a rendszer működés közbeni viselkedését írjuk le. A viselkedés leírásakor a belső működés részleteit adjuk meg, ahogy az az időtől való függés szerint történik. A viselkedést különböző típusú kölcsönhatások (interakciók) segítségével adjuk meg. Ezek lehetnek:

• objektumok között (ezek a kölcsönhatás diagramok: szekvencia- és együttműködési-),

• objektumon belül (állapotátmeneti- és aktivitás-) és

• egyéb fajta példány elemek között (pl. adatérték, komponens-példány)

A szekvencia diagram főbb elemei példán bemutatva:

name : Classobject symbol

lifeline

activation

other

stimulus

name (…)

return

: Class

create

new (…)

delete

name : Classname : Classobject symbolobject symbol

lifelinelifeline

activationactivationactivation

otherother

stimulus

name (…)

stimulusstimulus

name (…)

returnreturnreturn

: Class

create

new (…): Class

createcreate

new (…)

deletedeletedelete

További példa vezérlési szerkezetekkel és feltételekkel:



calculator filter value

[ x < 0]: transform ()

[ x > 0]: getValue ()

getValue ()

iterate ()

calculator filter valuevaluevalue

[ x < 0]: transform ()

[ x > 0]: getValue ()[ x > 0]: getValue ()

getValue ()getValue ()

iterate ()iterate ()

Példa együttműködési (collaboration) diagramra:

redisplay ()stimulus

1: displayPositions (window)

1.1 *[i := 1..n]: drawSegment (i)

: Controller : Window

wire :Wire{new}: Line

left : Bead right : Bead

1.1.1a: r0 := position () 1.1.1b: r1 := position ()

wire

«local» line

contents {new}

window

«self»

window «parameter»

1.1.2: create (r0, r1)1.1.3: display (window)

1.1.3.1 add (self)

object symbol link symbol

standard stereotype

standard stereotype

standard stereotype

standard constraint

standard constraint

redisplay ()stimulus


stimulus


1.1 *[i := 1..n]: drawSegment (i)1.1 *[i := 1..n]: drawSegment (i)







1.1.1a: r0 := position () 1.1.1b: r1 := position ()1.1.1a: r0 := position ()1.1.1a: r0 := position () 1.1.1b: r1 := position ()1.1.1b: r1 := position ()

wire

«local» line

contents {new}

window

«self»


wire

«local» line

contents {new}

window

«self»


1.1.2: create (r0, r1)1.1.3: display (window)1.1.2: create (r0, r1)1.1.3: display (window)

1.1.3.1 add (self)1.1.3.1 add (self)

object symbol link symbolobject symbol link symbol

standard stereotype

standard stereotype

standard stereotype

standard stereotype

standard stereotype

standard stereotype

standard constraint

standard constraint

standard constraint

standard constraint

Állapotátmeneti diagram főbb elemei:

top

ReadyReadyReady

stop

/ctr := 0stop

ÁllapotÁllapotÁllapot

IndítóeseményIndítóeseményIndítóesemény

AkcióAkcióAkció

Kezdőpszeudo-állapot

KezdőKezdőppsszzeudoeudo--állapotállapot

ÁtmenetÁtmenetÁtmenet

VégállapotVégállapotVégállapotDoneDoneDone

felső szintűfelső szintűfelső szintű

toptop

ReadyReadyReady

stopstop

/ctr := 0stop

ÁllapotÁllapotÁllapot

IndítóeseményIndítóeseményIndítóesemény

AkcióAkcióAkció

Kezdőpszeudo-állapot

KezdőKezdőppsszzeudoeudo--állapotállapot

ÁtmenetÁtmenetÁtmenet

VégállapotVégállapotVégállapotDoneDoneDone

felső szintűfelső szintűfelső szintű



Példa állapotátmeneti diagramra:

Példák aktivitás diagramra:

CalculateCost

ChargeAccount

GetAuthorization

[cost < $50]

[cost >= $50]

CalculateCost

ChargeAccount

GetAuthorization

[cost < $50]

[cost >= $50]

RequestReturn

Get ReturnNumber

Ship Item

Item[returned]

ReceiveItem

RestockItem

CreditAccount Item

[available]

Customer Telesales WarehouseAccounting

RequestReturn

Get ReturnNumber

Ship Item

Item[returned]

ReceiveItem

RestockItem

CreditAccount Item

[available]

Customer Telesales WarehouseAccounting

2.4.6 UML modell szervezése

Vizuális modellezéskor szinte kizárólag nagy méretű és bonyolult szoftver rendszerek megvalósítása a cél (végső soron ezért használunk vizuális modellezési technikákat, ld. bevezetésben). Ekkor viszont elkerülhetetlen az, hogy a nagy



modellünket valamilyen módon emészthető formában tálaljuk, azaz megfelelő módon osszuk kisebb egységekre.

A triviális objektumorientált csoportosítási elemek az osztályok, illetve magasabb szinten a komponensek. Azonban a UML további hatékony eszközöket is nyújt a csoportosításra, ezek a következők:

• csomagok (package),

• alrendszerek (subsystem) és

• modellek (model)

Csomagok. A csomag modellezési elemek csoportosítására szolgál és általánosan használható, de legnagyobb jelentősége a szerkezeti modellezésnél van. Különböző elemeket is tartalmazhat, további csomagokat is, így egy hierarchikus szerkezetet képezve. Egy csomag elemeinek láthatósági attribútumokat lehet megadni, amelyek más csomag elemei számára korlátozzák az elérhetőséget. Csomagok között függőségi kapcsolatok lehetnek.

Példa csomag jelölésre:

Pl. UML metamodell legfelsőbb szintű csomagja:

«metamodel»UML

Foundation

Model Management

Behavioral Elements

«metamodel»UML

«metamodel»UML

FoundationFoundation

Model ManagementModel Management

Behavioral ElementsBehavioral Elements

Alrendszerek. Míg a csomagokba történő szervezés főleg a logikai szerkezet felé irányul, az alrendszer olyan fajta csoportosítás, amelyet a fizikai felépítés ábrázolásánál alkalmazunk. Tehát az alrendszerek összessége a végső elkészült



rendszerünket alkotja. Az alrendszer megmutatja a kapcsolatot a specifikáció és a megvalósítás között, pl. használati esetek és osztályok között. Általában osztott rendszerek modellezésekor szokták alkalmazni.

Az alrendszer általános jelölése:

Realization elements

Specification elements

changeDigitAnalysisInformation ( )

Initiate Call

Receive Digit and Connect

Hook Signal and Disconnect

Traffic Control

Operations

changeDigitAnalysisInformation ( )::

«realize»

Realization elements


changeDigitAnalysisInformation ( )

Initiate Call

Receive Digit and Connect

Hook Signal and Disconnect

Traffic Control

Operations

changeDigitAnalysisInformation ( )::

«realize»«realize»

Az alrendszer jelölés használatára számos lehetőség van, pl. állapotátmeneti megközelítés:


Stopped Running

Error

Maintenance

Exhausted

Traffic Control

Pl. alrendszerek és interfészek kapcsolataira:

TrunkTraffic Control Subscription




Modellek. A korábban megismert modell fogalmát UML diagram szinten is meg lehet jeleníteni. A modell tehát a rendszernek egy olyan leképezése, amely egy bizonyos céllal készül és ez a leképezés a rendszer teljes reprezentációját adja, a teljes modellezési adathalmazt ábrázolja. A modelleket diagramok formájában



nagyon ritkán ábrázolják, az inkább a modellező eszköz belső tárolási formájaként jelenik meg és valamilyen strukturális formában szerkeszthető. A UML metamodell leírására viszont például ez a jelölés alkalmas.

Az alábbi példa mutatja az analízis és tervezés szintű ábrázolását ugyanazon rendszernek (a függőségi kapcsolat ugyanazon elem két nézetét köti össze):

Analysis

Design

«trace»

Analysis

Design

«trace»

2.4.7 Bővíthetőségi mechanizmusok

Mint ismeretes, a UML nyelv egyik legfontosabb tulajdonsága, hogy általános, azaz tetszőleges típusú szoftver rendszer modellezésére alkalmas. Mégis, lehetnek esetek, amikor a modellezni kívánt rendszer tartománya (domain-je) további jelöléseket kíván, vagy olyan tulajdonságok ábrázolására van szükség, amelyeket a UML nyelv nem tesz lehetővé. Erre adnak megoldást a UML bővíthetőségi mechanizmusai, a sztereótípusok, az OCL és a címke-érték (tagged value).

Sztereótípusok. A stereotype olyan fajta bővítését teszi lehetővé a UML-nek, amely segítségével további szemantikát lehet definiálni az egyes UML elemekhez. Szinte minden elemhez definiálható sztereótípus (osztályokhoz, kapcsolatokhoz, csomagokhoz, …). Vannak azonban előredefiniált sztereótípusok is. Egy sztereótípus gyakorlatilag a UML metamodellt egészíti ki újabb meta-osztályokkal, amelyeket a modell használhat. Alapvető jelölés a « » jelek közé írt név, de újabb grafikus ikonizált forma is létezik, pl.:

«capsule»aCapsuleClass

«capsule»«capsule»aCapsuleClassaCapsuleClass aCapsuleClassaCapsuleClassaCapsuleClass

Sztereótípusikon

Sztereótípusikon


«capsule»«capsule»aCapsuleClassaCapsuleClass


«capsule»«capsule»aCapsuleClassaCapsuleClass aCapsuleClassaCapsuleClassaCapsuleClassaCapsuleClassaCapsuleClassaCapsuleClass

Sztereótípusikon

Sztereótípusikon



OCL. Az OCL (Object Constraint Language) egy olyan nyelv, amely segítségével további szemantikai értelmezéssel lehet finomítani a modellt. Maga a nyelv egy szöveges leírást tesz lehetővé, amely meglehetősen kifinomult kapcsolatokat is definiálhat az egyes modellezési elemek között. Ugyanakkor a nyelv strukturált leírást biztosít, amely a szoftver eszközök általi automatikus felismerést is elősegíti. Pl. a UML metamodell szemantikájának leírásához is az OCL-t használják. Az OCL-t a UML specifikáció definiálja. Egyébként, a megszorítás általános jelölése a { } jelek között történik, általában megjegyzés dobozkák részeként.

Példa arra, hogy egy természetes nyelven megfogalmazott megszorítás hogyan néz ki OCL-ben:

„Ha egy osztály konkrét (nem absztrakt), annak minden operációjának kell hogy legyen megvalósítása.”

not self.isAbstract implies self.allOperations-> forAll (op | self.allMethods-> exists (m | m.specification-> includes(op)))

Címke-érték (tagged value). Címke-érték párok segítségével úgy bővíthetjük a UML nyelvet, hogy az egyes modellezési elemekhez további adatokat, tulajdonságokat rendelhetünk. Ezt úgy tehetjük, hogy a címkével megnevezünk egy új tulajdonságot a metamodellben, majd a modellünkben ezen címkékhez értéket rendelhetünk hozzá. Legtöbb esetben a tagged value sztereótípusokat kiegészítve alkalmazandó, annak további attribútumaként megjelenítve. Jelölése, pl.: “staus = unit_tested”.

Az alábbi ábrán láthatjuk mindhárom bővíthetőségi mechanizmus jelölését:

Profile-ok. A fenti három bővíthetőségi mechanizmust felhasználva, azok egy kombinációjával a UML-nek nevesített bővítéseit hozhatjuk létre, ezek a profile-ok. A profile általában egy alkalmazási terület, domain vagy valamilyen speciális környezet, vagy felhasználási minta rögzítésére szolgál. A UML (pontosabban, az OMG) néhány előredefiniált profile-t rögzít, ezek közül a legfontosabbak: üzleti alkalmazásokhoz, valósidejű, CORBA, stb.

2.4.8 A UML jövője

A UML nyelv folyamatos fejlesztés alatt áll. Az OMG szervezetnek külön munkacsoportjai vannak az egyes fejlesztési tevékenységekre, így a jelenlegi verziók javításaira, illetve az új verziók kiadására. A tizedessel jelölt verziónövelések főleg kisebb-nagyobb javításokat és bővítéseket jelentenek, viszont már tervezés alatt van a 2.0 UML verzió, amely a specifikáció teljes átdolgozását és modernizálását ígéri (nem tudni mikorra lesz meg).



A másik aktuális fejlesztési irány az ún. „akció-szemantikával” bővített UML (UML with Action Semantics), amely radikális előrelépést jelenthet a vizuális modellezés terén. Itt ugyanis, hosszútávon az a cél, hogy olyan nyelvet fejlesszenek ki, amely lehetővé teszi, hogy a modell teljes egészében specifikálja a rendszert és a UML terv önállóan is végrehajtható legyen! Ez azt jelenti, hogy programozási nyelvben nem is kellene implementálni a modellt és egyéb külső dokumentációra se lenne szükség, mert az akciók révén az már tartalmazna minden funkcionális és procedurális tevékenység leírását. Ez az elképzelés eléggé merész, és jelenleg még nem látszik, hogy megvalósítható-e. Mindenesetre, vázlat már van hozzá, az akciók leírására már nyelvek is vannak (ASL, AL) és a 2002 év végére ígérik az első verziót. Ha az eredeti cél nem is lesz megvalósítva, az akció-szemantika minden bizonnyal jelentős mértékben fogja növelni a UML kifejezőképességét.

2.4.9 Eszközök

Mint ahogy a bevezetőben már említettük, számos szoftver eszköz van, amely támogatja a UML nyelvet. Ezek között vannak speciálisan vizuális modellezésre alkalmas eszközök, mások egy teljes CASE részét képezik, míg fellelhetők egyéb jellegű szoftverek kiegészítő szolgáltatásaként a UML támogatás is (pl. általános rajzolóprogram UML elemekkel).

A Rational cég Rose nevű eszköze az egyik legelterjedtebb és az iparban széles körben alkalmazott eszköz, amely UML támogatásával a teljes szoftverfejlesztési folyamat támogatható. A Rational Rose vizuális modellezését teszi lehetővé különféle típusú rendszerekhez, pl. kliens/szerver-, osztott-, valósidejű-rendszerek. Az aktuális verzió a Rose 2001, de van demo, illetve student verzió is ingyenes használatra. A Rose számos beépített támogatást tartalmaz a legkülönfélébb objektumorientált nyelvekhez és technológiákhoz, pl.: C++, Java, DDL, IDL, WinDNA, MFC, COM, ATL, CORBA, XML/DTD, XMI, Oracle 8, stb. A Rose motor egy egyszerűsített változata a Microsoft Visual Studio 6.0 részeként is fellelhető (Microsoft Visual Modeler).



2.5 A „kurzusfelvétel” példaprojekt

2.5.1 A szoftverrendszer modellezésének áttekintése

Ebben a fejezetben egy elképzelt felsőoktatási intézmény kurzusfelvételi szoftverrendszer modellezését tekintjük át. A példaprojekt nem lesz teljesen kidolgozva, célja a UML használatának bemutatása. A modell kidolgozását a RUP folyamat elvei alapján végezzük, bár nem követve szigorúan annak lépéseit. A folyamat szerinti iterációkat nem követjük végig, hanem kiragadva egy-egy példát megismerjük a UML jelöléseit olyan sorrendben, amelyet egy-egy iteráción belül általában alkalmaznak.

A következő tizenegy lépés szerint haladunk:

• projekt megkezdése,

• használati esetek modellezése,

• osztályok felfedése,

• kölcsönhatás diagramok,

• kapcsolatok megadása,

• viselkedés és szerkezet hozzáadása,

• öröklődések,

• objektum viselkedése,

• modell végegesítés,

• rendszer architektúra,

38 2.5 A „kurzusfelvétel” példaprojekt


• folyamat iterációi.

2.5.2 Projekt megkezdése

Mint ismeretes, a fejlesztési folyamat kezdeti fázisának legfontosabb kérdése: „Vajon tényleg ezt a rendszert kell elkészíteni?” Ez a nulladik iterációnak a feladat. Ezt a kérdést általában bonyolult megválaszolni, hiszen a fejlesztés minden szereplőjét érinti: ügyfél, külső szakértők, szoftverfejlesztők. Sokszor prototípusokat készítenek el a koncepciók helyességének bizonyítására. Egyéb üzleti-, technológiai-, erőforrás-, stb. meggondolások is szükségesek lehetnek.

A „Kurzusfelvétel” alkalmazás. Feltesszük, hogy a megrendelő a következő igénnyel fordul hozzánk. Jelenleg a kurzusok kiosztása oktatóknak és a kurzusok felvétele hallgatók által következőképpen történik:

• Az oktatók leadják a tanulmányi osztályon a meghirdetett kurzusait.

• A hallgatók ezen lista alapján jelentkeznek a kurzusokra (nyomtatványokon).

• A tanulmányi osztályon számítógéppel hozzárendeli a hallgatókat a kurzusokhoz, utólagos egyeztetés lehetséges, ha nem sikerült.

• Jelenleg kézzel és egy központi számítógéppel történik.

• Szükség van az áttérésre egy teljesen „online” megoldásra.

• Nem a teljes hallgatói nyilvántartás megvalósítása a cél, hanem csak a kurzusfelvételé.

• Ezután az új alkalmazást kicsit pontosabban specifikáljuk:

• Minden félév elején a hallgatók megkapják a meghirdetett kurzusok részletes listáját.

• Négy kurzust és mindegyikhez két alternatívát lehet választani telítettség esetére.

• A kurzusokat 3–10 hallgató esetében indítják.

• Az oktatók meghirdetik a kurzusaikat és lekérhetik a feliratkozott diákok listáját.

• A hallgatók a kurzusfelvételi időszakban módosíthatják a választásukat.

• A hallgatók tandíjat fizetnek a választott kurzusok alapján.

2.5.3 Használati Esettanulmány

A fenti rövid specifikáció alapján el lehet kezdeni a modellezést a használati esettanulmány elkészítésével. A használati eset modellezés elveit követjük, miközben az architektúra használati eset nézetét készítjük el (Use Case View).

Mint ismeretes, a használati eset modellezéskor a rendszer viselkedését modellezzük a funkcionalitás szempontjából. Ez a legmagasabb absztrakciót jelenti és jó kommunikációs eszközt képez (a felhasználó felé is). Megvilágítja rendszer tervezett funkcióit (használati eseteit), a rendszer környezetét (szereplők – Actor) és az ezek közötti kapcsolatokat (ebből lesz a használati eset diagram – Use Case Diagram).



Szereplők (aktorok). Az szerplők nem részei a rendszernek, akárki vagy akármi lehet, ami a rendszerrel kapcsolatban van. A szereplő továbbít és/vagy fogad információt a rendszer felé, -től. A szereplőket óvatosan kell megválasztani, hiszen számos buktató lehet, és ezek kihatással vannak a teljes későbbi modellezés sikerére. A következő szempontokat érdemes figyelembe venni:

• Funkcionalitások mérlegelésével kell dönteni.

• Látszólag azonos szereplőkből kettő lesz, ha a rendszert teljesen különbözőképpen használják.

• Nem kell bevezetni új szereplőt, ha az általa használt funkcionalitásokat más szereplők már használják.

• Iteratív folyamat eredménye.

Student

A „Kurzusfelvétel” szereplőit a következőképpen választjuk ki:

• Hallgató (Student). Személy, aki az egyetemen órát választ.

• Oktató (Professor). Személy, aki az egyetemen órát hirdet meg.

• Tanulmányi Osztály (Registrar). A Kurzusfelvétel rendszer adatainak karbantartója.

• Számlázó Rendszer (Billing System). Külső információs rendszer, amely a hallgatók felé a számlázásért felelős.

Használati Esetek. A használati esetek képezik a használati eset modellezés azon elemeit, amellyel a rendszer funkcionalitását írjuk le. Nagyon fontos, hogy ez a funkcionalitás úgy legyen megfogalmazva, ahogy az a szereplő számára, azaz kívülről látható, (tehát nem a működés megvalósulását írjuk le). Valójában a használati eset nem más, mint a szereplő és rendszer közötti „párbeszéd”. Ha a használati eseteket sikerült jól megválasztani, akkor egy legfelsőbb szintű diagram használati eseteinek összessége megadja a rendszer összes működési módját, se többet, se kevesebbet.

Register for courses

A használati eset megválasztása általában nem könnyű feladat, kérdéses szokott lenni pl. hogy milyen részletességű funkcionalitásból legyen egy-egy új használati eset. Általában úgy célszerű ezeket megválasztani, hogy nagyobb funkcionalitást foglaljanak magukba, amelyek egy kerek egészet alkotnak. Hasonló, közös részeket tartalmazó esetekre van megoldás a használati eset kapcsolatok segítségével.

A „Kurzusfelvétel” felső szintű használati esetei a következők:

• Kurzus választása.

• Kurzus meghirdetése.



• Hallgatók névsorának lekérése.

• Kurzusok adatainak kezelése.

• Oktatók adatainak kezelése.

• Hallgatók adatainak kezelése.

• Kurzuslista készítése.

Használati esetek dokumentációja. A teljes fejlesztési folyamat során, de a használati eset modellezésnél különösképpen fontos a részletes dokumentáció. Mivel kevés technikai részlet elérhető ebben a fázisban, a konkrét funkcionalitások dokumentálására természetes nyelven történő leírás tartozik (amely általában külső dokumentum, pl. Word). Ide azt kell leírni, hogy mit csinál a rendszer és nem azt, hogy hogyan. A dokumentáció során nagy segítség az ún. „eseményáramlás” (Flow of Events) alkalmazása, amellyel egy-egy használati eset részleteit adjuk meg:

• használati eset kezdete és vége,

• adatok áramlása,

• események pontos sorrendje,

• egyéb feltételek, kivételes viselkedés leírása,

Példaként projektünk Kurzus meghirdetése használati esetének eseményáramlását adjuk meg:

• Oktató belép a rendszerbe jelszó megadásával.

• A rendszer megkérdezi az oktatótól, hogy melyik félévre meghirdetett órákat kezeljen.

• Menürendszer segítségével választhat: add, delete, review, print, quit.

• Összes bevitelnél adat helyességét ellenőrzi a rendszer.

• stb.

Használati eset kapcsolatok. A használati eset diagramokon a következő kapcsolatok használhatók: asszociáció szereplő–használati eset között, kibővítés, magábanfoglalás és általánosítás kapcsolatok használati eset–használati eset között. Ritka esetekben szereplők között is használható az általánosítás kapcsolat. Az alábbi ábrán láthatunk példát ezen kapcsolatokra:

*1

<<include>>

*1

Az asszociációs kapcsolat valójában egy kommunikációs kapcsolatot jelent, amely a szereplő és a használati eset kommunikációját írja le («communicates»



sztereótípussal ellátott asszociáció). A kapcsolat lehet irányítás nélküli, ez esetben kétirányú kommunikációt jelent, ellenkező esetben viszont az irány a kezdeményezés irányát adja meg. Multiplicitás is megadható.

Amikor két használati eset közé adunk meg kapcsolatot, akkor az kétféle specialitás függőségi (dependency) kapcsolat lehet, sztereótípusokkal megadva: „magábanfoglalja” és „bővíti” («include» és «extend»). A „magábanfoglalja” esetében részfunkcionalitást ábrázolunk, amikor az egyik (rész)funkció többször is szerepel. Ez azt jelenti, hogy a részfunkcionalitás minden esetben végre hajtandó. A „bővíti” esetében viszont, valamilyen speciális funkcionalitással történő kibővítést írunk le (pl. kivételes viselkedés) és esetleg opcionális végrehajtást is jelenthet. Az általánosítás a szokásos szemantikai általános/speciális viszonyt fejezi ki.

Használati eset diagramok. A használati esetekből és szereplőkből felépített diagramok a modell olyan nézeteit adják meg, amelyek vagy a rendszer áttekintését szolgálják (fő diagram), vagy az egyes szereplő és/vagy funkcionalitások szemszögéből vizsgálják. Amikor szükséges, a rendszer határát is meg kell rajzolni (téglalappal bekeretezni), pl. a fő diagramon.

A „Kurzusfelvétel” fő használati eset diagramját az alábbi ábrán láthatjuk:

Student

Billing System

Register for courses

Select courses to teach

Request course roster

Professor

Maintain student information

Maintain course information Maintain professor information

Create course catalogue

Registrar

Az alábbi ábra egy segéd használati eset diagramot mutat, amely az oktató szempontjából ábrázolja a rendszert, kicsit részletesebben feltüntetve a használati eseteket:

Professor

Select courses to teach

Validate user

<<include>>

Request course roster

<<include>>



2.5.4 Osztályok azonosítása

A kezdeti használati eset diagramok és a hozzá tartozó dokumentációból kiindulva elkezdhetjük megtervezni a rendszerünk logikai szerkezetét, azaz a kezdeti osztálydiagramokat. Először is, beazonosítjuk a főbb objektumokat, majd a hozzájuk tartozó osztályokat, amelyeket sztereótípusokkal látunk el és csomagokba csoportosítunk.

Az osztályok beazonosítás sokszor triviálisnak tűnik, de nagyobb rendszerek esetében ritkán egyértelmű az első ránézésre, hogy milyen egységekből legyen egy-egy osztály. Ilyen esetben mindig abból induljunk ki, hogy mik azok az objektumok, amelyek a rendszer futásakor képződhetnek. Ezt is általában az intuíciónk szerint végezzük, de nem árt, ha jobban megértjük, mi is rejlik a megérzéseink mögött. Mint ahogy azt az OOP alapjaiból ismerjük, egy objektum olyan entitás (valós világból vagy elvonatkoztatott), rendelkezik:

• állapottal (attribútumok határozzák meg),

• viselkedéssel (operációk határozzák meg és annak módját írja le, hogyan reagál más objektumok kéréseire) és

• identitással.

Egy objektum identitása annyit jelent, hogy minden objektumi egyedi, még akkor is, ha az állapotuk azonos. Az identitás nyilván úgy valósul meg, hogy a minden objektumnak különálló memóriaterület van fenntartva (eltekintve a megosztott objektumoktól, de az más lapra tartozik). Az objektum UML szerinti jelölése:

Algebra

A fentiek figyelembevételével először próbáljuk felfedezni, hogy milyen objektumok létezhetnek az alkalmazásunkban, majd az azonos állapottal és viselkedéssel (más objektumok felé, ill. belső szemantika) rendelkezőknek hozzunk létre osztályokat. (Itt jegyezzük meg, hogy az öröklődéssel megvalósítható általánosítást egy későbbi fázisban határozzuk meg, amikor már több ismeretünk van.)

Ebben a fázisban is nagyon fontos az egyes osztályok dokumentálása, aminek az a lényege, hogy az osztály szerepét írjuk le, és nem a szerkezetét. Pl. az nem jó dokumentáció, hogy a CourseOffering osztály „egy egészet és egy sztringet tartalmazó osztály”. Ennél többet mond az, hogy „a Kurzusfelvétel alkalmazásban a meghirdetett kurzus adatainak tárolására és kezelésére szolgál”. Konkrétan ez az osztály attribútumai a tanterem és időpont, operációi pedig a tanterem és időpont lekérése, új hallgató hozzáadása, stb. Figyelem: itt még nem adunk meg konkrét típusokat, szignatúrákat, csak a lényegi működés elvét!

Ezt az osztályt UML szerinti jelöléssel a következőképpen ábrázolhatnánk:

CourseOffering

getOffering()addProfessor()

(f rom Univ ersity Artif acts)

<<entity>>

CourseOffering

(from UniversityArtifacts)

A második jelölésmód a speciális sztereótípus szerinti ikonizált forma. A fenti Algebra nevű objektum e osztály egy példánya.



A fenti példában az osztály sztereótípusa az entity volt, amely egy speciális előre definiált osztály-fajta. A kezdeti fázisban nagy segítség lehet azonnal alkalmazni néhány tipikus sztereótípust, mert általában nehéz feladat. Maga a RUP folyamat ad egy javaslatot is arra nézve, hogy milyen sorrendben célszerű elindulni (boundary-val kezdjük, majd control, végül entity). Az alábbi alapvető osztály sztereótípusokat használhatjuk:

• «Entity». Entitás osztályok modellezésére, általában hosszú életű információt, viselkedést tartalmaz. Ezek az osztályok a valós világ entitásai, amelyek kevésbé érzékenyek a környezetük változásaira. Sok esetben más alkalmazásokban is felhasználhatók. Felfedezésükhöz jó kiindulás lehet a használati eset leírásokban a feladatkiosztások főnevei. Pl.: személyek adatai, kurzus adatai, stb.

• «Boundary» (határ). Ezen osztályok a rendszer környezete és belseje közötti kommunikációt valósítják meg és valójában interfészt képeznek a felhasználó vagy más rendszer (szereplő) felé. Pl. a felhasználói interfész is ide tartozik. Jelen példánkban a „kurzus meghirdetése” egy boundary osztály.

• «Control». A control (vezérlő) osztályok a használati esetek szekvenciális viselkedését valósítják meg, azaz a használati eset „végrehajtását”. Általában egy szereplő/használati eset párhoz hozzátartozik egy-egy ilyen osztály. A vezérlő osztályok megválasztása már nem olyan egyértelmű, mert a funkcionalitás az entitás osztályhoz tartozhat. Általában modulárisabb lesz a rendszerünk, új a funkcionalitás vezérlő osztályba kerül. Pl. „oktató és kurzus kezelője” egy vezérlő osztály az alkalmazásunkban.

• Egyéb (pl. utility, exception).

Példaképpen nézzük a Kurzusfelvétel osztályait a „Kurzus meghirdetése” használati esethez (e használati eset lehetőséget ad az oktatónak, hogy válasszon egy kurzust amelyet oktatni fog). Boundary osztályok: olyan osztályokat vizsgálunk itt, amelyek csak az Oktató szereplővel vannak kapcsolatban, pl. az esettanulmányban leírtak alapján az oktató módosítani tudja az adatokat, erre szolgáljon a ProfessorCourseOptions osztály, új kurzus hozzáadására pedig AddACourseOffering. Az entity osztályok az esettanulmány alapján könnyen beazonosíthatók: Course, CourseOffering, ProfessorInformation. Control osztályként új osztályt hozunk létre esemény áramlások kezelésére ProfessorCourseManager néven.

Mint már megismertük, a csomagok (Package) használata nagy rendszereknél elkerülhetetlen az osztályok csoportosításához. Minden UML csomagban megadhatunk interface osztályokat (publikus elérésűek) és implementációs osztályokat (ezek belső, privát osztályok, amelyek a csomagon kívül nem használhatók). Az eddigi osztályain három logikai csoportba oszthatók:

• Az egyetemre vonatkozó dolgok: UniversityArtifacts a Course, CourseOffering és ProfessorCourseManager osztályokkal.

• Személyekre vonatkozó adatok: PeopleInfo a ProfessorInformation osztállyal.

• Az esettanulmány szereplőihez kapcsolódó interfészek: Interfaces a ProfessorCourseOptions és AddACourseOffering osztályokkal.



Az eddigiek alapján elkészíthetjük az első osztálydiagramjainkat. Az előbbi három csomagba osztott osztályaink a modellt képezik, amelyből különböző nézetek szerint készíthetünk osztálydiagramokat. Általában minden csomaghoz tartozik egy fő diagram (Main), valamint az egész rendszer logikai nézetéhez egy fő diagram, amely a felsőszintű csomagokat ábrázolja. A csomagok fő diagramjai általában csak a csomag publikus osztályait tartalmazzák. A fő diagramok mellet egyéb osztálydiagramokat is szokás használni, pl. csomag implementációs osztályait ábrázoljuk vagy az öröklődési hierarchia megjelenítése. A teljes diagramokhoz hozzátartoznak a kapcsolatok is, de ezeket később adjuk hozzá.

Tehát a példaalkalmazásunk fő osztálydiagramja a következő (figyeljük meg a függőségi kapcsolatot):

Interfaces

UniversityArtifacts PeopleInfo

A UniversityArtifacts csomag fő diagramja (a CourseOffering osztály hiányzik, mert az belső implementációs osztály):

Course

ProfessorCourseManager

Az alábbi ábrán egy példát láthatunk osztálydiagramra sztereótípusok megjelölésével:

AddACourseOffering(from Interfaces)

<<boundary>>

ProfessorCourseOptions(from Interfaces)

<<boundary>>

Professor(from PeopleInfo)

<<entity>>

Course(from UniversityArtifacts)

<<entity>>

CourseOffering(from UniversityArtifacts)

<<entity>>

ProfessorCourseManager(from UniversityArtifacts)

<<control>>



2.5.5 Objektumok kölcsönhatása – scenario, interaction

A következő lépésként elkezdjük vizsgálni az objektumok dinamikus viselkedését. Ehhez szükségesek a használati eset ismeretei, valamint felhasználhatjuk az előző részben beazonosított osztályainkat.

Valójában a használati eset megvalósítását modellezzük az objektumok egymás közti kölcsönhatások vizsgálatával. Ehhez használni fogjuk a szcenárió fogalmát. Szcenáriónak nevezzük a használati eset megvalósulását az objektumok közötti kölcsönhatások (egymásnak küldött üzenetek) leírásával, azaz a használati eset egy „példánya”, az eseményáramlás egy útvonala. Más szóval, amíg az eseményáramlás leírása természetes nyelven történik, addig ugyanezt a dolgot UML nyelv segítségével a szcenárió valósítja meg a kölcsönhatás diagramokkal, mint grafikus nézetekkel. Kétféle kölcsönhatás diagramot használhatunk:

• szekvencia diagram (Sequence Diagram) és

• együttműködési diagram (Collaboration Diagram).

Szekvencia diagramok. A szekvencia diagram objektum-kölcsönhatásokat mutat be az idő függvényében, a szcenárióban szereplő objektumokat és osztályokat ábrázolja a közöttük küldött üzenetekkel. A legfontosabb ismérve, hogy idő-orientáltan mutatja be az üzeneteket, tehát az időbeli változások jól követhetők rajta. Egy-egy szekvencia diagram mindig egy konkrét végrehajtást ábrázol, tehát sok esetben elég nagy lehet. Ezért célszerű a szcenárió kis egységeit ábrázolni egyszerre. Azonban, a UML megad néhány jelölést, amelyek segítségével vezérlési szerkezetekkel lehet bővíteni a szekvencia diagramokat, így nem csak egy végrehajtás ábrázolható, de ezek használata korlátozott. Elemei az objektumok, amelyek megnevezett objektum, megnevezett objektum + hozzátartozó osztály vagy anonymous (csak osztálynév) lehetnek. A szekvencia diagramokon szereplő üzenetek (Message) a szcenárió funkcionalitását valósítják meg, amelyek sokszor az üzenetet fogadó objektum metódus hívását jelenti. A szekvencia diagramok a használati esetekkel szoros kapcsolatban állnak, ezért általában a Használati Eset nézetnek a részei.

Példa szekvencia diagram a „Kurzusok adatainak kezelése” használati esetnek „Kurzus létrehozása” szcenáriójához (figyeljük meg, hogy itt még nem konkrét metódusnevek szerepelnek, hanem csak elvi üzenetek):

: Registrar

a course form the managera course : Course

set course info

process

add course

new course



Itt érdemes megfigyelni, hogy az első objektum az egy külső szereplő egy példánya, ezek szerint az ő általa küldött üzenetek valószínűleg valamilyen boundary osztályhoz szólnak, jelen esetben a felhasználói felületen keresztül.

Együttműködési diagramok. Az együttműködési diagramok a szekvencia diagram mellett a szcenárió alternatív ábrázolására szolgálnak. Valójában a kettő teljesen kompatíbilis, egymásból származtathatók. Míg a szekvencia diagramok inkább a megrendelő számára nyújthatnak hasznos információt és a tervezés korai fázisaira jellemzők, addig az együttműködési diagramok a kapcsolatok implementációjánál lehetnek fontosak. Ezen diagramok az objektumok kölcsönhatásait mutatja be maguk az objektumok és kapcsolataik szemszögéből, azaz ez egy üzenet-orientált nézet. Elemei úgyszintén az objektumok, kapcsolatok objektumok között, az üzenetek nyilakkal ábrázolva.

A fenti szekvencia diagramnak megfelelő együttműködési diagram:

: Registrar

a course form

the manager

a course : Course

1: set course info2: process

3: add course

4: new course

2.5.6 Kapcsolatok megadása (relationships)

Az eddigi ismereteinket felhasználhatjuk arra, hogy a szerkezeti modellünket tovább bővítsük asszociációs kapcsolatok megadásával (association). Egy-egy asszociációs kapcsolat az osztályok között gyakorlatilag mindig egy objektum-kölcsönhatás megvalósulása, más szóval a kapcsolatok az objektum-üzeneteknek a „csatornái”. Az asszociációs kapcsolat speciális fajtájaként az aggregációs kapcsolatokat (rész-egész kapcsolat) is felfedjük (aggregation). A kapcsolatok különböző tulajdonságokkal fogjuk kiegészíteni: név, irány, szerep, multiplicitás, stb. Ezen kívül, függőségi kapcsolatok is használhatunk gyengébb összefüggések ábrázolására. Az osztályokon kívül, csomagok között is megadhatunk bizonyos kapcsolatokat.

Asszociáció kapcsolat. Az általános asszociáció kapcsolat egy osztályok közötti kétirányú összeköttetés, amelynél navigálási irány megadható az üzenet irányának jelzésére. Általában valamilyen használati kapcsolatot jelent a két osztály között, amelyek léte egymástól általában független, de legalább az egyik ismeri és/vagy használja a másikat (az ismeretség irányát megadhatjuk a navigálási irány segítségével). A kapcsolat szemantikus összefüggést ábrázol és nem adatfolyamot (mindkét irányba lehet információ/adat továbbítás). A valódi összefüggés az osztályokból létrejövő objektumok között jön létre, amely különböző



kölcsönhatásokat jelent. UML jelölés szerint az asszociációs kapcsolat egyszerű tömör vonal a két osztály között, amelyekre különböző tulajdonságok is elhelyezhetők:

ProfessorCourseManager Course

0..n 1..n0..n 1..n

manages

Aggregációs kapcsolat. Ez a kapcsolat az asszociáció egy speciális formája, amely „rész-egész” viszonyt fejez ki a résztvevő osztályok között (erősebb mint az asszociáció), vagyis azt, hogy az egyik objektum fizikailag tartalmazza vagy birtokolja a másikat. Ezt a kapcsolatot sok esetben nagyon nehéz precízen meghatározni, hiszen nem mindig egyértelmű, hogy a kapcsolat teljes vagy részleges tartalmazást jelent, vagy csak hivatkozást a másik objektumra. Egy asszociációból általában akkor célszerű aggregációt csinálni, amikor a kapcsolat leírásánál a „része” kifejezés egyértelműen használható vagy amikor az egész-objektum bizonyos műveletei automatikusan a rész-objektumokra is vonatkoznak (pl. megszűnés).

UML jelölés szerint a rombusz a tartalmazó oldalán jelzi az aggregációt:

CourseOfferingCourse

1 1..n1 1..n

Alapvetően kétféle aggregációt különböztetünk meg:

• gyenge tartalmazás – általános aggregáció (teli rombusszal jelölve)

• erős tartalmazás, vagy más néven kompozíció – akkor használjuk amikor rész(ek) élettartama szigorúan megegyezik az egészével (üres rombusz)

B

A

C

A kompozíciót általában könnyű felismerni, pl. arról, hogy ha a tartalmazó megszűnik, akkor biztos a tartalmazottnak is meg szűnnie, vagy ha a tartalmazónak valamilyen művelet végrehajtása minden esetben maga után vonja ugyanazon művelet végrehajtását a tartalmazotton is.

Az alábbi példa szemlélteti az általános asszociáció és a gyenge és erős aggregáció közti különbséget.



Person

Head

Dog

10..*

-owner

1

-pet

0..*

Owns

Has

Flea

0..100

Carries

0..100

Kapcsolatok nevei. Az asszociáció kapcsolatnak opcionálisan lehet neve, amely általában egy igés kifejezés (pl. Owns, Carries, Has). A név olvasásának iránya is fontos (melyik osztálytól melyik felé), ha nem egyértelmű, akkor egy kis háromszög a név mellett mutathatja meg. A nevet szenvedő módba is lehet rakni, ha a fordított irány kifejezése fontosabb (pl. Is owned by). Az aggregációknak általában nincs nevük, mert egyébként is oda kell érteni és mindig a következőkhöz hasonló: Has, Contains, …

Kapcsolat végpontok. A kapcsolatok további fontos tulajdonságait a végpontokhoz rendelhetjük hozzá. Így ezen tulajdonságok az adott végpontoknál szereplő osztállyal való kapcsolatra vonatkoznak, míg a kapcsolat név az egész kapcsolatra.

Az egyik végpont tulajdonság a szerepnév (role names). A szerepnév általában egy főnév, amely a kapcsolat adott végpontján levő osztály szerepét írja le az adott kapcsolatban. Az alábbi példában az oktató mint személy-entitás (Professor osztály) a feltüntetett kapcsolatban tanárként szerepel (Teacher), tehát a szerepnév további pontosítása az osztálynak az adott kapcsolat szempontjából:

Professor<<entity>>


<<entity>>

10..4

+Teacher

10..4

Sok esetben nem szükséges egyszerre kapcsolat nevet és szerepnevet is megadni. A szerepnév általában helyettesítheti a kapcsolat nevét, hiszen kifejezőbb és pontosabb lehet annál. Másfelől viszont, csak akkor használjunk kapcsolat nevet ha az szükséges az érthetőség miatt. Az alábbi példában a két szerepnév fölösleges, hiszen a kapcsolat nevéből egyértelműek a szerepek, és fölöslegesen nem kell hizlalnunk a diagramunkat.



Person

Employer EmployeeEmploys

+employed person+the employer

Ezek nem kellenek!

Multiplicitás. Multiplicitást a kapcsolatok végpontjainál definiálhatunk a hozzá tartozó osztályokhoz annak érdekében, hogy a kapcsolat megvalósulásánál résztvevő objektumoknak számát pontosítsuk. Példák a megadásra:

• 1 – pontosan egy

• 0..* (vagy *) – nulla vagy több (akárhány)

• 1..* – egy vagy több

• 0..1 – nulla vagy egy

• 5..8,11 – 5, 6, 7, 8 vagy 11

A fenti példában azt ábrázoltuk a multiplicitások segítségével, hogy minden oktató 0–4 kurzust hirdethet meg és hogy minden kurzust pontosan egy oktató hirdethet meg.

Reflexív kapcsolatok. Kapcsolat természetesen létesíthetünk egyazon osztályból kiindulva saját magával is, hiszen az azonos osztályhoz tartozó különböző objektum példányok egymással is kommunikálhatnak. Az osztálydiagramon ezek a reflexív asszociációk és aggregációk. A reflexív kapcsolatoknál általában a szerepek vannak megnevezve és nem maga a kapcsolat.

Kapcsolatok keresése. Ahhoz hogy a kapcsolatokat sikeresen beazonosítsuk, a szcenáriókat kell vizsgálni, hiszen a kölcsönhatási diagramokon az objektumok közötti üzenetek mindenféleképpen valamilyen osztályok közötti kapcsolatot sejtetnek. Általában biztos út az, ha első közelítésben asszociációt hozunk létre minden kölcsönhatásra, majd ha erre a kapcsolatra ráillik az, hogy „része” vagy „tartalmazza”, akkor az legyen inkább aggregáció. Kapcsolat létrejöhet egyéb megfontolásból is, mint. pl. öröklődések tervezésekor (ld. később).

A Kurzusfelvétel alkalmazásban a fent megadott „Kurzus meghirdetése” használati esetnek „Új kurzus hozzáadása” szcenáriója alapján a következő üzeneteket lehet felismerni:

• ProfessorCourseOptions → AddACourseOffering

• AddACourseOffering → ProfessorCourseManager

• ProfessorCourseManager → Course

• Course → CourseOffering



Ezen üzenetek és egyéb, használati esettanulmányban leírtak (pl. Kurzus előfeltétele), alapján a következő osztálydiagramot adhatjuk meg most már a kapcsolatok feltüntetésével:

ProfessorCourseOptions(from Interfaces) ProfessorCourseManager

AddACourseOffering(from Interfaces)

1

1

1

11

1

1

1

CourseOffering

Course

0..n

1..n

0..n

1..n

manages

0..n0..n0..n

+Pre-requisite

0..n1

11

1 1

1..n

1

1..n

Kapcsolatok csomagok között. Korábban már csoportosítottuk a szerkezeti modellünket csomagokba. A jelenlegi kapcsolatok alapján a csomagok között is létrehozhatunk kapcsolatokat. A csomagok közötti kapcsolat típusa a függőségi kapcsolat (Dependency Relationship), amelyet szaggatott nyíllal jelölünk. Függőség akkor van, ha a függő csomag (Client) legalább egyik osztálya kommunikációt kezdeményez a másik csomag (Supplier) valamely publikus osztályával („használja” azt), azaz:

Package A Package B

Client Supplier

A jelenlegi tudás alapján az „Új kurzus hozzáadása” szcenárióban az AddACourseOffering osztály üzenetet küld a ProfessorCourseManager osztálynak és emiatt hozunk létre egy függőségi kapcsolatot az Interfaces és a UniversityArtifacts csomagok között (ld. fent).

2.5.7 Viselkedés és struktúra

Az eddigiek alapján már elegendő információval rendelkezünk ahhoz, hogy az osztályainkat pontosítsuk a viselkedés (operációk) és a struktúra (attribútumok) hozzáadásával. Valójában ezen két tulajdonsággal együtt lesz teljes egy osztály.

Az objektumok viselkedését a hozzátartozó osztályok foglalják magukba, és az operációk (metódusok) határozzák meg. Az operációk megválasztásakor ügyeljünk arra, hogy egy operáció csak egy valamit csináljon, de azt az egyet jól tegye! Pl. a CourseOffering osztálynak képesnek kell lennie felvenni és törölni egy hallgatót. Az elnevezésekre vonatkozóan célszerű valamilyen konvenciót követni, pl. hogy kisbetűvel kezdődjenek, összetett szónál minden szó kezdődjön nagybetűvel.



Az objektumok struktúrája a hozzátartozó osztályok attribútumaival van leírva. Valójában minden attribútum egy adatdefinició, amit az osztály objektumai tárolnak. Pl. a Course osztály attribútumai: név, leírás és kreditpontok (figyeljük meg, hogy itt még mindig nem használunk teljes leírást, a típusok pl. hiányoznak). Az elnevezésre az operációknál leírtakat elkalmazhatjuk, bár mást is szoktak használni, főleg privát adattagok esetén (pl. aláhúzás karakterrel keződik).

FONTOS: Nagyon fontos megjegyezni, hogy annak ellenére, hogy a kapcsolatok implementációja sok esetben az osztály valamilyen adattagjával van megvalósítva (pl. pointer a másik osztályra), az ilyen adattagokat nem kell felvenni attribútumnak! Tehát, csak olyan attribútumnak van értelme, amelyik tényleg valamilyen adatot hordoz, struktúrát határoz meg, a kapcsolatok megvalósításai nem attribútumok.

Operációk létrehozása. A kölcsönhatás diagramokban levő üzenetek tipikusan leképezhetők a fogadó osztály operációira. Ez jó kiindulási pont lehet, bár korántsem fedi le az összes szükséges oparációt. Ez alól kivételt képez az, ha az üzenetet fogadó osztály boundary típusú (határosztály) és ez valamilyen felhasználói felület megvalósítása. Pl. az „új kurzus hozzáadása” szcenárióban az oktató szereplőnek meg kell adnia a jelszót. Ez az üzenet nyilván nem a ProfessorCourseOptions operációja lesz, hanem egy szövegmező az ablakon. Hasonlóan, ha az üzenet egy olyan szereplőtől jön (szereplőhöz megy), aki fizikailag egy személy, akkor nem lesz operáció, hanem pl. a felhasználói kézikönyvbe kerül. Kölcsönhatás diagramoktól függetlenül is létre lehet hozni operácókat, ilyenek pl. a segéd operációk.

Az alábbi példa mutatja „Kurzus meghirdetése” használati esetnek „Új kurzus hozzáadása” szcenáriójához tartozó szekvencia diagramot most már konkrét metódus hívásokkal, mint üzetekekkel:

: Professor : ProfessorCourseOptions : AddACourseOffering : ProfessorCourseManager

: Course : CourseOffering

enter password

verify password

enter semester

add an offering

display

select Math 101

getOfferings(Course)

getOfferings( )

getOffering( )

display offerings

select offering

setProfessor(Professor, Course, CourseOffering)

setProfessor(Professor, CourseOffering)

addProfessor(Professor)



Az operációk dokumentálása is nagyon fontos. Itt arra kell törekedni, hogy azt írjuk le hogy az adott operáció mire való, azaz a funkcionalitását magyarázzuk el (tehát ne azt írjuk le, hogy hogyan valósítja ezt meg). A bemenő- és kimenő paramétereket is meg kell adni, így kapjuk meg az operáció szignatúráját (lenyomat). A teljes szignatúra megadható a tervezés későbbi fázisában is, itt elegendő dokumentálni a paramétereket. Az operáció szignatúrája sok esetben valamilyen további kapcsolatot is reprezentálhat. Pl. a Course osztályon belüli addProfessor operáció bemenő paraméterei a professor és a courseOffering. Ebből következően kapcsolatok léteznek a: Course és ProfessorInformation, valamint a Course és CourseOffering osztályok között. Kezdetben ezeket felvehetjük asszociációnak, de később lehet függőség (dependency) is, ha kiderül hogy ezek a kapcsolatok csak ideiglenes és/vagy gyengébb függőséget jelképeznek.

Attribútumok létrehozása. Sok attribútum megtalálható a probléma leírásban, a követelmény specifikációban és az adatfolyam dokumentációban. Ezekből az attribútumok nagy része különösebb nehézség nélkül meghatározható (ezért is fontos ezeket a korai dokumentumokat alaposan elkészíteni). Pl. a követelmények közt szerepel, hogy a kurzus megnevezése, leírása és a kreditpontok elérhetőek a meghirdetett kurzusokon. Ebből következően a név, leírás és a kreditpontok a Course osztály attribútumai lesznek. A dokumentálásnál itt is arra ügyeljünk, hogy azt írjuk le, hogy az attribútum mire való és nem azt, hogy hogyan épül fel.

Operációk és attribútumok megjelenítése. Az osztálydiagram szolgál az operációk és attribútumok megjelenítésére, sőt, sokszor csak erre hozzuk létre kapcsolatok megjelenítése nélkül, pl.:

CourseOffering

getOffering()addProfessor()

<<entity>>

Course

namedescriptioncreditHours

getOfferings()setProfessor()

<<entity>>ProfessorCourseManager

getOfferings()setProfessor()

<<control>>

Asszociációs osztályok. Eddig megismerkedtünk a kapcsolatok alapvető tulajdonságaival. Viszont, lehetnek esetek, amikor többre van szükség, azaz a kapcsolatnak is lehet viselkedése és struktúrája. Pl. minden hallgató osztályzatot kap. Ez hol legyen tárolva? Nem tartozik a hallgatóhoz, mert ő különböző tárgyakhoz különböző osztályzatokat kap. A kurzushoz sem tartozik, mert különböző hallgatókhoz különböző osztályzatok vannak. A megoldás az asszociációs osztály használata, hiszen az osztályzat a két osztály közötti kapcsolathoz tartozik. UML szerinti ábrázolása a következő:



CourseOffering(from UniversityArti facts)

Student

3..100..4 3..100..4

Grade ReportCard1

1

1

1

0..4 10..4 1

2.5.8 Öröklődések feltárása

Az általánosítás kapcsolat (Generalization) a UML-ben egy nagyon sokrétűen alkalmazható kapcsolat. Osztály diagramok esetében az osztályok közötti öröklődés (Inheritance) ábrázolására használatos, amikor ugyanis az egyik osztály megosztja a struktúráját és/vagy a viselkedését egy vagy több másik osztállyal. Így egy öröklődési hierarchiát kapunk, ahol a származtatott osztály örököl az ősosztály(ok)tól (subclass derives from superclass). A UML értelmezése szerint, a származtatott (gyerek) osztály mindent örököl az őstől, beleértve a relációkat is. A UML általánosítás kapcsolatnak nincs neve, nincsenek használva szerep nevek és multiplicitás sem. Jele:

A

B

Öröklődés feltárása. Ha már van egy csonka osztálymodellünk, amelyben osztályok már szerepelnek, a hozzájuk tartozó attribútumokkal, operációkkal és kapcsolatokkal, az öröklődések feltárása sokkal könnyebb mintha azzal kezdtük volna a tervezést. Két egyszerű elvet kell követnünk és a meglévő osztályokban keresnünk ahhoz, hogy előálljon az öröklődési hierarchia:

• Általánosítás. Általánosításkor több osztály közös rész-struktúráját és -viselkedését egy közös ősosztályba helyezzük. Ez a tevékenység a tervezés kezdeti szakaszaira jellemző (legelőször a valós világot írjuk le majd később vonatkoztatunk el), tehát így célszerű kezdeni az öröklődések feltárását. Általános szabály, hogy az attribútumok, operációk és kapcsolatok a lehető legmagasabb szintre kerüljenek a hierarchiában! Pl. a StudentInformation és ProfessorInformation osztályoknak is vannak név, cím és telefonszám attribútumai, ezért kézenfekvő ezeknek egy közös ősosztályt létrehozni:



Professor

RegistrationUser

Student

• Specializálás. Specializáláskor származtatott osztályokat hozunk létre, amelyek finomítják az ősosztályt (tipikusan új struktúrát és viselkedést adnak hozzá). Pl. a beiratkozási rendszert bővíthetnénk, hogy az idősebb hallgatók (nyugdíjasok!?) ingyen vehessenek fel kurzusokat. Ilyenkor új attribútumok vezethetünk be, pl. hallgató életkor, vagy új operációkat, pl. kurzus ingyen felvétele.

Általánosítás és a kapcsolatok. Míg az attribútumok és operációk helye többé-kevésbé egyértelmű, a kapcsolatok helyére az általánosítás után két alapvető lehetőség van:

• Maradnak a származtatott osztályok szintjén:

RegistrationUser

nameIDNumber

Professor

tenureStatus

Student

major


0..4

1

0..4

+Teacher

1

0..4

3..10

0..4

3..10

• Ősosztály szintjén új kapcsolatot alakítunk ki módosított szerepkkel és multiplicitással. Pl. ami magában foglalja az oktató és a hallgató objektumok összegét (vagyis egy CourseOffering objektum 4–11 UserInformation objektummal álljon relációban). Itt viszont további megszorításokra is szükség lehet, hiszen azzal hogy följebb került a kapcsolat, elvesztek bizonyos információink. Pl. egyik UserInformation biztos ProfessorInformation kell hogy legyen.

A két megoldás közül sokszor nehéz dönteni, ilyenkor mindig a közérthetőségre és egyszerűségre törekedve döntsünk.



Többszörös öröklődés. Többszörös öröklődésről beszélünk akkor, ha egy osztálynak több ősosztály-lánca van, azaz ugyanahhoz az őshöz több mint egy úton juthatunk el a hierarchiában (irányítatlan értelemben kör van benne). Pl. a kétéltű jármű egy motorgépkocsi, ami egy jármű és az egy vízi jármű is ami ugyancsak egy jármű:

Jármû

Motorgépkocsi Vízi jármû

Kétéltû jármû

Ilyen többszörös öröklődéseket tartalmazó hierarchiák kezelésekor számos probléma adódhat, pl. név ütközések, többszörösen örökölt operációk/attribútumok, stb. Éppen ezért, számos programozási nyelv nem is támogatja a többszörös öröklődést (pl. Java). Egyéb nyelveken természetesen megoldható a probléma és kezelhető is, de csak nagy odafigyeléssel (pl. C++-ban virtuális öröklődéssel). Mindenesetre, kevésbé karbantartható kódhoz vezet ezért kerüljük a használatát.

Öröklődés és aggregáció. Mind az öröklődés, mind az aggregáció valamilyen módon az objektumok összetételét segítik. Sok esetben felmerül tehát a kérdés, hogy melyiket célszerű alkalmazni. Hajlamosak vagyunk arra, hogy túl sok öröklődést használjunk, pedig az újrafelhasználhatóságnak és karbantarthatóságnak a sok öröklődés csak árthat. Az öröklődést sokszor rosszul használják, pl. egy hallgató lehet nappali vagy levelező, ezért származtathatnánk két osztályt a StudentInformation-ból. Ebből viszont problémák adódhatnak:

• ha a nappalis hallgató áttér levelező tagozatra, meg kell változtatni az objektum osztályát (ami általában nem célszerű),

• újabb specializálásra van szükség ami többszörös öröklődéshez vezet.

Általános szabály, hogy az öröklődést kell használni a közös elválasztására a specifikustól, míg az aggregáció a tartalmazások ábrázolására szolgál. Ezért mindig ezen alapvető szempontokat vegyük figyelembe, azaz az osztályok elvi szerepét figyeljük, és ne azt, hogy megvalósítás szintjén melyik lenne célszerűbb!

A fenti levelezős hallgató problémáját a következőképpen oldhatjuk meg az öröklődés elkerülésével:



RegistrationUser

nameIDNumber

<<entity>>

Professor

tenureStatus

<<entity>>


<<entity>>0..4

1

0..4

+Teacher

1

Classification<<entity>>Student

major

<<entity>>

0..4

3..10

0..4

3..10

10..n 10..n

Fulltime Parttime

2.5.9 Dinamikus viselkedés

Az utolsó nagyobb logikai modellezési részben a viselkedési modelleket pontosítjuk. Az eddigi dinamikus viselkedési modellezés az objektumok között kölcsönhatásokra korlátozódott a használati esetek és szcenáriók segítségével. Viszont, miután már megvannak az osztályok részletesebb specifikációi (attribútumok, operációk, kapcsolatok), elkezdhetjük az egyes osztályok viselkedésének finomítását. Ehhez az objektumok dinamikus viselkedését elemezzük és modellezzük az állapotátmeneti diagramok segítségével.

Állapotátmeneti diagramok. Az állapotátmenet diagram egy konkrét objektum állapotait ábrázolja, az eseményeket és üzeneteket, amik az állapotváltásokat kiváltják, és az akciókat, amik végrehajtódnak állapotváltáskor. Az állapotátmeneti diagram magába foglalja az összes üzenetet, amit egy objektum küldhet, illetve fogadhat. Csak jelentős dinamikus viselkedéssel bíró osztályokhoz célszerű ezeket létrehozni (amik sok üzenetet fogadnak és/vagy küldenek). Az állapotátmeneti diagramokat legtöbb esetben a kölcsönhatás diagramok (szekvencia, kollaborációs) alapján származtatják azáltal, hogy a küldött és fogadott üzeneteket vizsgálják: pl. a szekvencia diagramban két üzenet közötti intervallum általában egy állapotként reprezentálható. Azonban sok esetben szükség lehet visszahivatkozni a használati esettanulmányhoz is: a szcenáriók pl. egy konkrét utat reprezentálnak az állapotátmenet diagramban. Egy jól kidolgozott állapotátmeneti diagram az osztályhoz elegendő specifikációt ahhoz, hogy közvetlenül implementálható legyen a funkcionalitása.

Állapotok (state). Egy objektum állapotait az osztályának egy vagy több attribútuma határozza meg, pl. egy CourseOffering objektum lehet nyitott vagy zárt. Ezen kívül, egy hivatkozás létezése egy másik objektumra is meghatározhatja az állapotot. Tehát egy objektum állapotait az attribútumainak és hivatkozásainak vizsgálatával határozhatjuk meg. UML jelölése az állapotnak egy lekerekített sarkú téglalap:



Állapotátmenetek. Az állapotátmenet egy objektum állapotának megváltozását jelenti (maradhat ugyanaz is), amit egy akció kísérhet. Az állapotátmenet lehet automatikus, amikor befejeződött az egyik aktivitása, vagy nem automatikus, ha egy névvel ellátott üzenet váltja ki (másik objektumtól vagy külső). Mindkét esetben azonban az állapotátmenet időtartama nullának tekintendő és nem lehet azt megszakítani (az állapot megszakítható). UML jelölése egy nyíl az eredendő állapotból az újba.

Speciális állapotok. Két speciális állapot van:

• Kezdő (pszeudo-) állapot (Start State): minden diagramnak kell lennie pontosan egy kezdő állapotnak.

• Végállapot (End State): több is lehet egy diagramon belül.

Start End

Az alábbi példa mutatja a CourseOffering osztály állapotátmeneti diagramját:

OpenClosed

Canceled

Initialization

cancel

add student

add student cancel

Állapotátmenet részletek. Egy állapotátmenethez hozzá lehet rendelni különböző egyéb jellemzőt, amelyek segítségével még pontosabbá tehetjük az osztály specifikációját (és megkönnyíthetjük a későbbi implementációt). Ezen jellemzők általában az objektum privát operációiként valósulnak meg. A következő részleteket adhatjuk meg az állapotátmenetekhez:

• Akció: a viselkedést írja le, amely állapotváltáskor jellemző.

• Védő feltétel: ez egy logikai kifejezés, amely az állapotátmenetet csak igaz érték esetén engedélyezi.

• Esemény kiváltás: az esemény kiváltás egy üzenet, amit egy másik objektumnak küld az objektum az állapotátmenet létrejöttekor.



Az alábbi ábrán láthatjuk a fenti állapotátmeneti diagram egy bővített változatát az állapotátmenet részletek megjelenítésével:

OpenClosed

Canceled

Initialization

cancel

^CourseRoster.delete

add student / set count = 0 ^CourseRoster.create

add student[ count < 10 ]

cancel

[ count = 10 ]

Állapot részletek. Magukhoz az állapotokhoz is hozzárendelhetünk további részleteket (gyakorlatilag, itt is az objektum egyes segéd-operációiról van szó):

• Belépő akció (entry): minden állapot váltáskor végrehajtódik.

• Kilépő akció (exit): minden állapot elhagyáskor végrehajtódik.

• Aktivitás (do): egyszer végrehajtódik valamikor, amíg az adott állapotban van.

Az alábbi ábra mutatja a teljesen kidolgozott változatát a CourseOffering osztály állapotátmeneti diagramjának:

Open

entry/ Register studentexit/ ^CourseRoster.Add student(Student)

Closed

do/ Finalize course

Canceled

Initialization

do/ Initialize course offering data

cancel

^CourseRoster.delete

add student / set count = 0 ^CourseRoster.create

add student[ count < 10 ]

cancel[ count = 10 ]



2.5.10 Modell vizsgálata

Még ha nem is követtük szigorúan a folyamat előírásait, a tervezés ennek a pontján már szükséges egy nagyobb felülvizsgálata az elkészült modellnek és diagramoknak. A következő lépés már a rendszer fizikai megtervezése lesz, ezért fontos a logikai tervet minél pontosabban elkészíteni.

A modell vizsgálatakor a legfontosabb tevékenység a homogenizálás. A homogenizálás valójában folyamatos tevékenység kell, hogy legyen, de nagyobb mérföldköveknél elengedhetetlen. Amikor homogenizáljuk a modellt, akkor a „összegyúrjuk” a projekt csapattagjainak különböző eredményeit egy egységes egésszé. Pl. az elnevezéseket átvizsgáljuk, a dokumentációt kiegészítjük (át kell vizsgálni, hogy minden modellezési anyag jól, és azonos módon legyen dokumentálva), a meglévő osztályok szerkezeteit és a kapcsolatokat felülvizsgálva átcsoportosítjuk azokat: újakat hozunk létre, a fölöslegeseket töröljük.

Szükség lehet pl. arra, hogy egyes osztályok összekombináljunk, amikor azok hasonló használati esetek megvalósításai. A kombinálással kisebb, áttekinthetőbb modell készíthető és a fölösleges elaprózódás elkerülhető.

Egy másik tipikus tevékenység az, amikor osztályokat szétválasztunk. Amikor egy osztályban megvalósított funkcionalitás túl nagy és szerteágazó, akkor célszerű szétválasztani azt külön osztályokba. Ne felejtsük el az alapelvet, miszerint „egy osztály egy dolgot csináljon, de azt jól tegye”.

Bizonyos osztályokat teljes egészében is megszüntethetünk. Az osztályok eliminálása akkor szükséges, amikor nincs sem lényeges viselkedése sem strukturája, és nem vesz részt egyetlen használati esetben sem. Ez előfordulhat bármely osztállyal a modellezés során, hiszen a modell folyamatosan változik.

A leglényegesebb rész a vizsgálatkor talán az, hogy a modell önmagában konzisztens maradjon. Igaz, hogy modellezéskor minden résztvevő tudatosan erre törekszik, de előfordulhatnak tévedések. A konzisztencia-vizsgálat alapvető szempontja az, hogy minden statikus és dinamikus nézetet össze kell egyeztetni, az azonos elemek különböző helyeken azonosan jelenjenek meg. Egy jó módja a konzisztencia vizsgálatának, az, amikor a szcenáriókat végigpróbáljuk, az eseményeket végigkövetjük (ld. a RUP fő iterációinak 5. lépését!).

2.5.11 Rendszer-architektúra

Miután a rendszerünknek elkészült egy elsődleges modellje és az már különböző diagramokként meg is jelenik, célszerű a rendszer architektúráját megtervezni. Ide tartoznak az eddig elkészült logikai modellen kívül különböző nézetek szerint a fizikai felépítés és a futás közbeni működés magas szintű ábrázolása. A rendszer-architektúra valójában stratégiai döntések sorozata a rendszer szerkezetével, viselkedésével, rendszerelemek együttműködésével és fizikai megvalósulásával kapcsolatban. Ez egy nagyon fontos dolog, fejlesztői csapat kitüntetett feladatai közé kell sorolni, hiszen ez a rendszer nézeteinek a legfelsőbb szintje. Az architektúráról a 2.4.1 részben beszéltünk részletesebben, itt használjuk az ott megismert fogalmakat. Az architektúra 4+1 nézetét vesszük alapul, és ezen belül definiáljuk az egyes nézeteinket, diagramjainkat.

A használati eset nézet. A használati eset nézet (Use Case View) az architektúrának egy áttekintő nézete, amely a rendszer használhatóságának és



működésének megértését segíti elő a funkcionalitás szempontjából. Az egyéb nézeteket áttekinti és validálja. Alapvető elemei a használati eset diagramok, valamint a kölcsönhatás diagramok, amelyek korábban már részletesen is tárgyaltunk.

A logikai nézet. Az architektúra logikai nézete (Logical View) alapjában véve az osztálydiagramok: osztályok, csomagok, kapcsolatok. Ebben a nézetben a rendszer logikai szerkezete van leírva. Az alábbi ábrán láthatjuk a Kurzusfelvétel alkalmazás teljes logikai szerkezetét, azaz a fő osztálydiagramot:

Interfaces

UniversityArtifacts PeopleInfo

GUI Controls

Foundations

global

Database Error Handling

global

A komponens nézet. A komponens nézet (Component View) is a rendszer szerkezetével foglalkozik, csakhogy ez a rendszert annak fizikai szerveződése által ábrázolja. Itt a különböző szoftvermodulok szervezésének ábrázolása a fő cél. Főleg implementációs kérdésekkel foglalkozunk, mint pl. a programozási nyelv, felhasználói interfész, hardver platform, stb. A logikai és a komponens nézetek között nem mindig van 1-1 megfeleltetés, de a kettő konzisztens a modellel.

A komponens nézetnek az elemei a komponens diagramok, amelyeket a logikai nézethez hasonlóan csomagokba csoportosíthatjuk. A komponens diagramok főbb elemei a komponensek, amelyek különböző jellegű implementációs egységeket ábrázolnak, pl. forrásfájlok, modulok, bináris könyvtárak, stb. Az egyes programozási nyelvekben történő implementációkor különböző dolgokra lehet használni a komponenseket, C++ esetében pl. egy komponens = .h + .cpp fájl, Java esetében viszont egy komponens ábrázolhat egy osztályt, vagy egy osztálygyűjteményt .jar formátumban. Az alábbi ábrán a komponens néhány megjelenítési formáját láthatjuk:

Component

Task Specification

Package Specification



Az alábbi ábrán láthatunk egy példát a Kurzusfelvétel alkalmazásból (University csomag komponens diagramja):

Course CourseOffering

RegistrationUser

Professor Student

Az alábbi ábra egy másik példát mutat egy olyan komponens diagramra, amelyben a komponensek nagyobb egységek, bináris program modulok. Ezen kívül az egyes komponensek közötti kommunikáció is fel van tüntetve, az interfészekkel együtt. Az ilyen fajta függőségi viszonyok ábrázolása a folyamat nézetben is hasznos lehet (ld. lejjebb).

ProfessorOptions

<<EXE>>

Courses<<DLL>>

Persistence<<DLL>>

CoursesAPI DatabaseAPI

A folyamat nézet. A folyamat nézet (Process View) a rendszer logikai architektúráját szemlélteti, de annak nem szerkezeti felépítését, hanem futás közbeni implementációs kérdésekkel foglalkozik, pl. teljesítmény, skálázhatóság, megbízhatóság. A folyamat nézetben a rendszer elemei (komponensei) közötti függőségeket vizsgáljuk, ezért az alapvető elemei a komponens diagramok, kiegészítve különböző függőségi kapcsolatokkal. Pl. a hívási függőségeket ábrázolhatjuk, amint a a futtatható főprogram .exe hívogatja a DLL-ben megvalósított egyéb komponenseket (ld. fenti ábra).

A telepítési nézet. A telepítési nézet (Deployment View) a rendszer további fizikai felépítését, szerkezetét ábrázolja, de itt már sokkal nagyobb léptékű elemeket figyelembe véve. Igazából, valódi nagy méretű rendszerek modellezésénél alkalmas a telepítési nézet, amikor a rendszernek több különálló feldolgozási egysége van, amelyek esetleg hálózatba vannak kötve és egy osztott rendszerként működnek. A telepítési nézet az ilyen fizikai elrendezés topológiáját ábrázolja, a célja különböző szempontok könnyebb vizsgálata, pl. teljesítmény, megbízhatóság, skálázhatóság, stb. A telepítési nézet elemei a telepítési diagramok, amelyek csomópontokból (node) állnak. Egy csomópont a rendszer egy-egy futás közbeni feldolgozó eleme, mint pl. szerver, kliens, adatbáziskezelő szofter vagy gép, stb. A csomópontok közötti összeköttetés asszociációs kapcsolatot jelent, amely az egységek között kommunikáció meglétét jelzik.



Az alábbi ábra mutatja a Kurzusfelvétel rendszer egy lehetséges topológiáját. Láthatjuk, hogy az egyes csomópontok egy-egy számítógépen futó önálló alkalmazást jelképeznek, amelyek egy hálózat segítségével vannak összekötve és különböző futtatható programokat jelentenek, amelyeket a különböző felhasználók (oktató, hallgató, …) használhatnak:

Registration

ProfessorOptions.exe

Database Server

Dorm

StudentOptions.exe

Main Building

StudentOptions.exe

Library

StudentOptions.exe

2.5.12 Fejlesztési folyamat iterációi

A fenti tíz lépésben áttekintettük a Kurzusfelvétel példa alkalmazás egy lehetséges modellezési lépés-sorozatát. Az egyszerűség kedvéért nem követtünk azonban pontosan egy jól megtervezett iterációs tervet, ahogy az a RUP folyamat javasolná. Kis rendszerek esetében nyilván nem lenne szükséges ragaszkodni a folyamat használatához, viszont valós méretű projektek esetében annál inkább!

Mint ahogy azt már leírtuk a 2.3.1 részben, a folyamat szerint egy 0. kezdeti iteráció után részletes iterációs tervet kell készíteni a további iterációkról. Ez általában úgy szokott történni, hogy a használati esettanulmányban szereplő egyes szcenáriók megvalósítást helyezzük sorrendbe. Olyan nagyobb egységekre bontjuk így szét a rendszert, amelyek jól különválasztható főbb funkcionalitásokat képeznek. Az egyes szcenáriók sorrendbe helyezésekor az alapvető prioritás a rizikó legyen, tehát lehetőleg a legrizikósabb részeket valósítsuk meg előbb. Ez annyit jelent, hogy pl. kevésbé baj a megrendelő számára, ha egy rész-, vagy kiegészítő funkcionalitás nem készül el időre, ha a fő funkcionalitások már jól működnek. Itt nyilván azt is figyelembe kell venni, hogy az egyes iterációkban megvalósított használati esetek és egyéb elemek mennyire építenek egymásra, tehát előbb a függő elemeket kell megvalósítani.

A Kurzusfelvétel alkalmazás modellezéséhez használhatjuk pl. a következő iterációs tervet:

• 1. iteráció. Oktató adatainak kezeléséhez szükséges használati esetek és modellek, valamint a „Kurzus meghirdetése” használati eset megvalósítása. Ez a legfontosabb iteráció, hiszen itt a fő adatbázis megvalósításának rizikóját kell megszüntetni. Továbbá, e iteráció elemeire épít a másik két iteráció is.

• 2. iteráció. Hallgató adatainak kezeléséhez szükséges használati esetek és modellek, valamint a kurzuskatalógushoz szükséges dolgok megvalósítása.



• 3. iteráció. „Kurzusfelvétel” és a kurzusválasztások listái használati eseteinek megvalósítása.

Miután a fent három iteráció mindegyikét végrehajtottuk, készen vagyunk a rendszer minden funkcionalitásának megvalósításával. Az egyes iterációk önmagukban teljes egészet kell, hogy képezzenek, tehát a tervezési feladatoktól kezdve az implementáción keresztül a tesztelést is magukba kell, hogy foglalják. Konkrétan, az alábbi főbb tevékenységeket kell elvégezni minden iterációban (ahogy azt a fejezet megelőző részében is láttuk a lépéseket):

• Felhasználói felülettervezés.

• Osztályok létrehozása.

• Tervezési minták használata.

• Kapcsolatok tervezése.

• Attribútumok és operációk hozzáadása.

• Öröklődések megtervezése.

• Kódolás, tesztelés, iteráció dokumentálás.

3 Objektumkomponens technológiák 65


3 Objektumkomponens technológiák

3.1 Bevezetés Osztott számítások elvégzése objektumok segítségével egy viszonylag új keletű, de nagyon hatékony módszer számos, mai hálózatos feladat elvégzésére. Régebben, különböző számítógépek közötti programozás bonyolult volt és a hibalehetőségek nagyok voltak. A hálózatos protokoll rétegeit ismerni kellet, és különböző konvertálási feladatokat kellett elvégezni.

Osztott számításkor egy hálózat komponensei egy egységként tudnak együttműködni, objektumok megosztásával egy heterogén és átlátszó hálózaton keresztül. Ilyen jellegű együttműködésre számos technológia lett már kifejlesztve, de mindegyik alapvető tulajdonsága, hogy alkalmazásukkal maga a hálózat is egy gigantikus számítógépként üzemel.

Az osztott objektumkomponens technológiák a hagyományos objektumorientált programozásra és paradigmára épülnek. Az alapvető különbség az, hogy az objektumok nem csak magában a hagyományos értelemben vett alkalmazásban léteznek, hanem megosztva, a hálózat tetszőleges pontján létezhetnek, ahol gyakorlatilag akármilyen operációs rendszer, környezet, stb. üzemel. Mindez viszont úgy néz ki az alkalmazás számára, mintha az objektumok lokálisan léteznének. Az osztott objektumkomponens technológiák alapvető célja tehát az, hogy a megosztott információs technológiákat (pl. hálózatos kliens-szerver alkalmazás együttműködések) hatékonyabbá, flexibilisebbé és kevésbe bonyolulttá tegyék. Néhány alapvető előnye ezen technológiáknak a következő:

• régi, elavult szoftverrendszereket könnyebb újrafelhasználni modern technológiák alkalmazásával,

• egy alkalmazást úgy is ki lehet fejleszteni, hogy egyes komponenseit osztottan valósítsuk meg, mindig a legmegfelelőbb platformot választva nekik,

• a kliens számára minden objektum lokálisnak tűnik, így azzal sem kell törődnie, hogy azok eredetileg milyen platformon léteznek,

• a rendszerek integrációját sokkal sikeresebben lehet elvégezni, stb.

Az ilyen jellegű szoftverfejlesztéssel újabb szempontokat is létrejönnek a fejlesztéskor használható eszközök terén. Egyre több szoftver cég a termékeit komponensek formájában kínálják, amelyek valamilyen objektumkomponens technológiának felelnek meg, így a fejlesztő munkája sokkal hatékonyabb és megbízhatóbbá válik.

A következőkben a legismertebb technológiákat ismertetjük röviden.

COM. A Microsoft Windows Distributed Internet Applications (Windows DNA) architektúrájának komponens technológiája (Component Object Model). Hálózat alapú alkalmazásoknál a kliens/szerver elvet követve, egységes architektúrát és nyelv-független, átlátszó megoldást nyújt. A COM+ ennek továbbfejlesztése, a DCOM (Distributed COM) már az ORPC (Object Remote Procedure Call) protokollon alapuló osztott technológia. A DCOM objektumainak egy interfésznek

66 3.2 CORBA


kell megfelelniük, az alacsony szintű memóriaelrendezést már a protokoll kezeli. Alapvetően bináris szinten vannak ábrázolva az objektumok, így tetszőleges nyelven lehet megvalósítani a klienst és a szervert. Alapvetően Windows platformos megoldás, de létezik UNIX, Linux és Solaris megvalósítás is.

JavaBeans, Enterprise JavaBeans. Ez egy platform-független komponens architektúra Java környezetben. Nagyon nagy mennyiségű újrafelhasználható program elemet tartalmaz, amellyel hatékony alkalmazások készíthetők. Minden bean-nek néhány alapvető követelményeknek eleget kell tennie, és innentől kezdve tetszőleges funkcionalitás megvalósítására alkalmas. Erről bővebben a 4. fejezetben lesz szó.

Java RMI. A JRPM (Java Remote Method Protocol) segítségével megvalósított távoli metódus hívás (Remote Method Invocation). Objektumok szerializálásával valósul meg a Java objektumok átvitele a hálózaton keresztül. Megfelelő interfész használatával Java programok között távoli kommunikáció könnyen megvalósítható. Erről is később bővebben lesz szó.

CORBA. A CORBA (Common Object Request Broker Architecture) az egyik legismertebb, leghatékonyabb és legáltalánosabban használható technológia, ezért ezzel részletesebben foglalkozunk. A CORBA segítségével programozási nyelvtől és platformtól függetlenül újrafelhasználhatók az objektumok, a Java pl. közvetlenül támogatja.

3.1.1 Hivatkozások

CORBA Basics.

• Object Management Group, 2002

The Common Object Request Broker: Architecture and Specification, Version 2,6

• Object Management Group, 2001

Gopalan Suresh Raj: A Detailed Comparison of CORBA, DCOM and Java/RMI

• http://gsraj.tripod.com/misc/compare.html

Bruce Eckel: Thinking in Java

• Prentice Hall, 2000

• http://www.mindview.net/Books/TIJ

Web címek:

• http://www.omg.com/

• http://www.corba.org/

3.2 CORBA

3.2.1 Bevezetés

A CORBA (Common Object Request Broker Architecture) az OMG szervezet (Object Management Group) által 1990-ben létrehozott és karbantartott architektúra és infrastruktúra. A CORBA lehetővé teszi, hogy különböző nyelvekben megírt és különböző platformokon futó alkalmazások



együttműködjenek betartva az objektumorientáltság elvét, azaz objektumok segítségével. Ezen alkalmazások futhatnak ugyanazon a gépen is, de alapvetően tetszőleges helyen is elhelyezkedhetnek tetszőleges hálózatokon belül.

Egyik alapvető alkalmazása a CORBA technológiának a hálózatos szerverek megvalósításánál van, amelyeknek nagy mennyiségű klienst kell kiszolgálniuk megbízhatóan és hatékonyan. A világ legnagyobb web kiszolgálói között számos olyan van, amely CORBA alapú (a CORBA internetes honlapján néhány sikertörténet is olvasható).

A CORBA sikeresen ötvözi az objektumorientált és az osztott kliens-szerver paradigmák elveit.

3.2.2 A CORBA alapvető működési mechanizmusa

A CORBA-t támogató alkalmazások objektumok segítségével kommunikálnak. Az objektumok a CORBA nyelvezet szerint egy identitással, interfészszel és implementációval rendelkező entitás. Ezen objektumoknak egységes interfésznek kell, hogy megfeleljenek, amelyet a szerver és a kliens is ismer. Az, hogy az interfésznek megfelelő objektumnak milyen konkrét implementációja van, a CORBA protokolljai elrejtik. A kommunikáció tehát kliens/szerver alapú, ahol a kliens a szervertől kér egy objektumot. A kért objektum beazonosításáért, annak továbbításáért az ún. Object Request Broker (ORB) kommunikációs infrastruktúra felelős, amelynek a kliensnél és a szerveren is egyaránt futnia kell. A lényeg, hogy az ORB-k elrejtik a kliens implementációja elől, hogy a szerveren az adott objektum valójában hogyan is van megvalósítva, milyen nyelven, platformon, stb. Maga az alacsony szintű kommunikáció egy saját protokoll szerint történik, az IP-re alapozva, melynek neve Internet Inter-ORB Protocol (IIOP).

Az ORB feladatai közé tartozik, hogy létrehozzák a megfelelő kapcsolatot a kliens és a szerver között, valamint az, hogy a kért objektumhoz tartozó métódushívásokat megfelelő argumentumokkal együtt bináris folyamban átküldjék. Ehhez nyilván sok részletet kell megvalósítania az ORB-nek, mint pl. a szerver beazonosítása, szerveren futó alkalmazás elérése és az objektum elérése. Egy objektumot a kliens egy hivatkozással tud elérni (reference), amely hivatkozás az ORB számára egy egyedi azonosítót jelent, de a felhasználó névvel is elláthatja ezeket az objektumokat. A nevek kezeléséért egy különálló CORBA szolgáltatás felelős, a naming service.

Az ORB egy magasabb szintű architektúrának része, amely az egész technológiát specifikálja. Ez az ún. Object Management Architecture (OMA). Az OMA a következő főbb elemeket tartalmazza:

• A CORBA rendszerrel kapcsolatos elemek: az ORB-k és a szolgáltatások (Object Services).

• Alkalmazás orientált elemek: Common Facilities (magas szintű szolgáltatások, pl. nyomtatás), Application Objects.

68 3.2 CORBA


OBJECT REQUEST BROKER

OBJECT SERVICES

COMMON FACILITIES

APPLICATION OBJECTS

Ezek közül az Object Services olyan fontos szolgáltatásokat nyújt, mint például a Naming Service, amely a kliens számára az objektumok beazonosítását segítik azok tulajdonságaik, nevük alapján. Az Application Objects maguk az alkalmazások, amelyek a többi komponenst használják.

Távoli hívás ORB-vel. Az ORB architektúrának egyik alapelve az, hogy az objektum interfészét egyértelműen szét kell választani az implementációtól (hiszen az nem is látszik a kliens számára). Az interfész egy, arra szolgáló programozási nyelven, az IDL (Interface Description Language) segítségével leírja, hogy az objektumnak milyen operációit lehet meghívni. Az objektum implementációját servant-nek (szolga) hívják, amely az implementáció programozási nyelvén (pl. Java, C++ vagy egyéb) megvalósítja az interfész operációit. Amikor megadjuk egy objektum interfészét az IDL segítségével, abból keletkezik két kódrészlet, az ún. stub és a skeleton, amelyek az ORB-nek egyfajta kommunikációs elérési pontját jelentik az adott objektumnak. A stub a kliens részén van, a skeleton meg a servant-nak a része. Egy távoli hívás kezdeményezésének elején a kliensnek először is a kért objektumra egy referenciát kell kérnie (ez többféleképpen is történhet, a Naming Service az egyik). Az ORB ezen hivatkozás szerint a hívást a távoli objektum felé továbbítja a stub-ok és a skeleton-ok segítségével (ezt a kliens nem érzékeli). Alul láthatjuk a CORBA ezt a rendkívül leegyszerűsített működését:

ORB1 ORB2

CLIENT OBJECT (servant)

IDL

stub

IDL

skel

obj ref operation()

in args

out args + ret

IIOP

IDL. A nyelvi függetlenséget az IDL használata teszi lehetővé: a kliensnek mindössze a metódusok neveit és szignatúráit kell ismernie, amelyeket a szerver szolgáltat. A szerver ezután a metódushívást meg tudja valósítani az implementációs nyelvben. Az IDL nyelv segítségével definiáljuk az objektumunk interfészét, majd ezután ezt az interfészt egy IDL fordító segítségével le kell fordítani és így kapjuk meg a stub és a skeleton kódokat. Az adott CORBA implementációnak a lehetőségeit felhasználva ezután a megfelelő szolgáltatások elérésével megvalósíthatjuk a kommunikációt. Maga az IDL nyelv szintaxisa egyébként nagyon hasonlít a C++ és Java szintaxisához: vannak csomagok



(modulok), interfészek, metódusok, típusok, stb. A 4.15.3 részben bemutatjuk az IDL használatát egy példán keresztül és egy alapvető CORBA kapcsolat létrehozását Java-ban.

4 Objektumorientált nyelvek 71


4 Objektumorientált nyelvek

4.1 Bevezetés A programozás alapvetően a komplexitás kezeléséről szól. Különböző nyelvek különbözőképpen kezelik a komplexitást. Mitől növekszik a komplexitás? A követelmények bővülésével a nyelvek is bonyolultabbak lesznek. Ezen kívül felléphetnek kompatibilitási problémák is. Pl.: C++ kompatíbilis C-vel, Perl Sed-del, Visual Basic BASIC-el, stb.

A Java nyelv készítőinek alap célkitűzése volt a komplexitást csökkenteni a programozó szempontjából. A Java egy relatíve új nyelv, de sok jó tulajdonságot átvett régebbi nyelvekből, pl. a C, C++, Smalltalk, stb.-ből.

A komplexitás kezeléséből adódik, hogy:

• könnyebb robusztus kódot írni (pl. ekvivalens programot C++ -ban kétszer annyi ideig tart megírni), de

• lassabban fut.

Hátrányai viszont megtérülnek, mert gyorsabban lehet jó Java programozóvá válni, és könnyebb megbízható programot írni. Ezen kívül Web alkalmazásoknál kiváló kommunikációs eszköz.

A Java egy magas szintű programozási nyelv, ahol nem a kódoláson van a hangsúly, hanem a tervezésen.

Jelentős szerepe volt/van a Web elterjedésében, mert kifinomult osztálykönyvtárakat nyújt az internetes programozás elősegítésére, és beépített biztonsági rendszere van. Ezen kívül fontos még, hogy platform-független. Ezáltal megszűnnek a portolási problémák a különböző hardver platformokhoz.

A Java nem „csak” egy nyelv. Számos egyéb alkalmazhatósága van (applet, j2me, beágyazott rendszerek…), jó osztálykönyvtárakat és programozási interfészeket nyújt (többek között tervezési mintákat is használ).

4.1.1 Előismeretek

A jegyzet épít bizonyos alapismeretekre. Mindenképpen szükségesek az algoritmikus programozás alapjai és az objektumorientált programozás alapjai. Bizonyos helyeken hasznos lehet a C, de még inkább C++ nyelvek ismerete.

4.1.2 Hivatkozások

Bruce Eckel: Thinking in Java:

• http://www.mindview.net/Books/TIJ

A Sun honlapja:

• http://www.sun.com

72 4.2 Absztrakció


4.2 Absztrakció Minél bonyolultabb a programozás problémája, annál absztraktabb megoldások kellenek. Ha visszatekintünk a múltba, akkor láthatjuk, hogy megalkották az assembly-t, ami absztrakció a gép felett. Majd következett a Fortran és C, amik absztrakciók az assembly felett.

De ezek még mindig gép-orientált elvonatkoztatások. Ennek felismerése után következtek a probléma-orientált absztrakciók, mint pl. a LISP és APL. Ezeknek azonban korlátozott volt az alkalmazhatóságuk.

A mai legmodernebb megoldás az OOP, vagyis az Objektumorientált programozás. Absztrakció OOP-ben:

• Alkalmazhatóság-független absztrakciója a probléma elemeinek.

• Ezeket hívjuk objektumoknak.

4.3 OOP jellemzői Egy OO programban minden objektum. Ezek után egy OO Program valójában nem más, mint egymással kommunikáló objektumok összessége. Minden objektumot kisebb objektumokból állítunk össze (akár alaptípusúakból).

Minden objektumnak van típusa, ami egy osztály (Java-ban a class kulcsszóval definiáljuk). Ugyanolyan típusú objektumok általában ugyanolyan üzeneteket fogadhatnak (a gyakorlatban ez relaxálható: ld. polimorfizmus).

4.3.1 Objektum interfésze

A sok egyedi objektum között vannak olyanok, melyeknek közös tulajdonságaik és viselkedéseik vannak, vagyis egyazon családba – osztályba tartoznak. A Simula-67 volt az első ilyen nyelv. Az osztály valójában nem más, mint egy absztrakt adattípus (egységbezárás – encapsulation). Ugyanúgy viselkedik, mint minden egyéb primitív típus (pl. változó hozható létre).

Az osztályoknak van tulajdonságuk (állapot) és viselkedésük. Egy osztály tulajdonságát az attribútumai (adattagok, mezők) írják le, míg a viselkedést az operációk (metódusok, tagfüggvények). Ezek a viselkedések üzeneteken keresztül aktiválhatók. Minden operációnak (és osztálynak) kell, hogy legyen interfésze, ami leírja, hogy mi az, amit üzenhetünk (deklarálás), és implementációja, ami teljesíti a kérést (definíció).

Az osztály egy példányát nevezzük objektumnak (mi a konkrét állapot).

Pl.



brightness = 100;brightness = 100;

Light lt = new Light();lt.on();

on()off()brighten()dim()

Light

brightness

UML osztálydiagram

Java kód

lt : Light

brightness=100

Probléma eleme a valóságban

ObjektumInterfész

Típus név

4.3.2 Implementáció elrejtése és újrafelhasználása

Programozás közben két feladatot szoktunk megoldani: Osztályt gyártunk (magunknak vagy másoknak) illetve osztályt használunk (mienket vagy másét).

Fontos, hogy ha osztályt gyártunk, akkor elrejtsük az implementációját. A használója nem kell, hogy ismerje, nem tudhat róla, így nem is teheti tönkre. Ezáltal kevesebb lesz a programhiba. Az implementáció elrejtését az elérés vezérlésével (láthatóság) valósíthatjuk meg. Ezáltal lehetőség nyílik az implementáció biztonságos módosítására akár későbbi fázisokban is, amikor már sok helyen használva van az osztály.

A Java-ban használható elérés vezérlők (access specifiers) a következők:

• public (publikus), private (privát), protected (védett) és az alapértelmezett: „friendly” (barátságos – csomagon belül publikus, egyébként privát)

Az újrafelhasználhatóság az OOP egyik legfontosabb előnye.

Az objektumokat általában más objektumokból rakjuk össze. Ezt nevezzük kompozíciónak és aggregációnak. A tartalmazott osztály általában privát elérésű.

: Car

: Engine

Kompozíció UML objektumdiagrammal bemutatva

Car Engine

Kompozíció UML osztálydiagrammal bemutatva

4.3.3 Öröklődés

Egy osztály interfészét újra fel lehet használni, hogy a „hasonló” osztályokat ne kelljen mindig újra létrehozni. Inkább „klónozni”, majd bővíteni, esetleg módosítani.

Ezt öröklődésnek nevezzük. Amelyik osztály interfészét újrahasznosítjuk az ős (szülő, alap), amelyik osztály felhasználja az interfészt a gyerek (leszármaztatott). Ha az ős változik, a származtatott is módosul. Az elérhetőség fontos: a privát

74 4.3 OOP jellemzői


attribútumok és operációk nem elérhetők (de továbbra is benne van), a védettek igen.

A hasonlóság kifejezését az ős felé általánosításnak nevezzük, a különbséget a gyerek felé pedig specializálásnak. A származtatott új típus lesz, ami az ős interfészét duplikálja – azonos típusú az őssel! (A kör az egy alakzat.)

Shapedraw()getColor()

Circledraw()

Squaredraw()

Triangledraw()

Származtatás UML osztálydiagrammal bemutatva

Származtatással ún. osztályhierarchiák hozhatók létre.

A származtatott osztály bővíthetjük úgy, hogy új attribútumokat veszünk fel, illetve új operációkkal. Ezt két féleképpen tehetjük meg:

• teljesen új operációkat veszünk fel, illetve

• módosítjuk az ős viselkedését (interfész marad): felüldefiniálás (overriding)

4.3.4 Objektumok felcserélhetősége: Polimorfizmus

Megtehetjük, hogy egy objektumot az őstípusa alapján kezeljük (pl. Shape). Ez előnyös lehet, mert a kód, ahol használjuk az objektumot, nem függ a specifikus típusoktól; és utólag is lehet definiálni származtatottakat. Ilyenkor az ős osztály operációit hívjuk. A fordító ebben az esetben nem tudja, hogy melyik konkrét implementáció hívódik, mert a programozó nem is kívánja megmondani. Futás közben fog kiderülni a konkrét típus alapján.

Nem OOP nyelvekre a korai kötés a jellemző, amikor a hívott eljárás abszolút címe fordítási időben meg van adva.

OOP-re a kései kötés a jellemző, amikor fordítási időben csak a kandidátusok adottak. Ez lassabb, de sokkal flexibilisebb kódot eredményez. Java-ban minden operációhívás ilyen virtuális típusú (C++-ban külön meg kell mondani).

A polimorfizmus segítségével könnyen bővíthető a program, mert nincs típus specifikusság. Pl. Shape helyett Circle van átadva (megtehető, mert a kör az egy alakzat is) Ezt nevezzük upcasting-nak („beleolvasztás”).

void doStuff(Shape s) {// ...s.draw();

}

Circle c = new Circle();Triangle t = new Triangle();doStuff(c);doStuff(t);



A doStuff operációban az s.draw() hívás nincs megkülönböztetve a típusok szerint. Melyik draw() fog hívódni? Fordítási időben nincs megkötve. Egy speciális mechanizmus működik, amely futás közben rendeli hozzá a megfelelő implementációt (kései kötés).

4.3.5 Absztrakt- és interfész osztályok

Egy (ős)osztály absztrakt, ha csak interfészként van használva (nem jön belőle létre objektum). Java-ban az abstract kulcsszóval adhatjuk meg. Absztrakt osztályokban lehetnek absztrakt operációk is, ezeknek nincs törzsük (definíciójuk).

Egy absztrakt osztályból származtatott gyerek osztály is absztrakt lesz, ha nem implementálja az operációt.

Létezik egy speciális típusú absztrakt osztály, az interfész osztály, amikor operáció definícióból egy sem lehet (csak az interfész van deklarálva). Nagyon hasznos, mert különválasztja az interfészt az implementációtól. Java-ban az interface kulcsszóval adhatjuk meg. Egy osztály több interfész osztályból is öröklődhet (több egyszerű osztályból nem).

4.4 Java bevezetés

4.4.1 Egyszeres gyökerű hierarchia

A legtöbb OOP nyelvben mindig van egy beépített ős: Java-ban: Object, ami minden osztálynak az őse (még a sajátjainknak is). Előnyös lehet, mert nem kell mindig hierarchiát építeni az alaptól, és bizonyos alap-funkcionalitások eleve elérhetőek lesznek. Pl. az argumentum-átadás könnyebb (upcasting), és a szemétgyűjtő (lásd később) működése is egyszerűbb. Azonban ez egy kis megkötést is jelenthet (pl. C++-ban nincs beépített ős).

4.4.2 Objektumok élete

Az eddigiek szerint az OOP = egységbezárás + öröklődés + polimorfizmus. Vannak azonban egyéb fontos tényezők is, mint pl. az objektumok tárolási helye:

• stack: automatikus és gyors, de nem mindig megfelelő.

• static: statikus, nem flexibilis de gyors.

• heap: dinamikus, futás-közbeni, lassúbb.

A másik fontos tényező az objektumok felszabadítása:

• stack: automatikus

• heap: kézzel kell, ami hibalehetőségeket rejt magában

Java-ban az objektumok mindig a heap-en keletkeznek (kivéve a primitív típusokat). Létre kell őket hozni a new kulcsszóval. A felszabadítás pedig automatikus ún. szemétgyűjtő (garbage collector) segítségével. Ezáltal biztonságos, könnyebb a kezelés, de sokkal lassúbb (mindig heap, mindig polimorfizmus…), mert több helyről is hivatkozhatnak egy objektumra (pl. konténer tárolja, de máshol is használjuk). Ez gond lehet real-time programoknál.

76 4.4 Java bevezetés


C++-ban a szemétgyűjtő hiánya miatt ez súlyos probléma-forrás lehet, de megmaradt a C hatékonysága.

4.4.3 Kollekciók

Nem lehet mindig előre tudni, hogy hány objektum kell, mert változó élettartamúak lehetnek. Ilyen célokra fejlesztették ki a kollekciókat (konténerek), amik valójában tároló objektumok, hivatkozásokat tárolnak a tárolandó objektumokra.

Egyszerűbb feladatokra például alkalmas lehet egy egyszerű tömb is, de ennél sokkal jobbak és rugalmasabbak a beépített kollekciók, mert automatikusan karban tartják magukat (átméretezés, stb.).

C++-ban az STL szabványos osztálykönyvtár szolgálja ezt a célt, Object Pascal-ban a VCL, míg Java-ban a standard könyvtár része

Különböző célokra különböző konténerek ajánlottak, mert különböző műveletigényűek bizonyos műveleteknél. Pl. a vektor gyors elérést, de lassú beszúrást valósít meg, addig ez a láncolt listánál fordítva van. Középút lehet a halmaz vagy hash tábla, amiknek viszont a tárigényük nagyobb.

Egy konténer által tárolt elemek elérése iterátorral van megvalósítva. Ugyanúgy használható minden típusú konténerrel (ArrayList, LinkedList, Stack, Set…). Ez előnyös, mert bármikor megváltoztatható az alkalmazott konténer, anélkül hogy a programunk módosulna!

Konténerre és iterátorra sokszor szükség van. Nem kell mindig újra megírni, része a könyvtárnak, nem kell vele foglalkozni, a valós problémára lehet koncentrálni

Java-ban minden konténer Object-eket tárol. Beszúráskor ez nem jelent gondot, mert upcasting történik (ez OK). Eléréskor viszont downcasting kell, ami nem mindig biztonságos (nem tudhatja, hogy milyen objektum is igazából). Ilyenkor meg kell jegyezni a típust valahogy, pl. egy attribútumban (van futás közbeni típus-azonosítás is, de ez lassú). Ha nem jó a downcast, akkor futási hiba történik! A megoldás a paraméterezett típusok használata (generikus programozás), ami C++-ban a template-tel van megvalósítva. Java-ban ez egyelőre csak javaslat.

4.4.4 Kivételkezelés (Exception handling)

Mindig is nagy gond volt a hibák helyes lekezelése. Sok nyelv nem is foglalkozik a témával, hanem inkább a library-ra bízza, hogy az megbízható legyen. Ilyenkor bizonyos játékszabályok betartása az egyetlen mód.

A kivételkezelés viszont a nyelv (és esetleg az operációs rendszer) része! A kivétel (exception) a Java-ban egy objektum, amit a hiba helyén „dobnak” (throw) és aki képes kezelni az „elkapja” (catch). Gyakorlatilag egy párhuzamos végrehajtási ág rendkívüli esetekre, ezáltal tisztább marad a rendes kód, és nem lehet ignorálni (míg a hibakóddal visszatérő függvényt igen).

Segítségével megbízhatóan helyreállítható a program futása. A Java-ban kezdettől fogva erősen be van drótozva a kivételkezelés.



4.4.5 Többszálú futtatás (Multithreading)

Régi követelmény, hogy egynél több feladatot egyidejűleg el lehessen végezni (multitasking). Alacsony szinten is megvalósítható megszakításokkal, ez nehéz és nem hordozható.

Időzítéseknél is fontos, de még fontosabb lehet egy nagy rendszer egyes részeit külön futtatni, több szálon (thread). Interaktívabb lehet például a felhasználói felület: egy gomb megnyomható, miközben valamilyen feldolgozás a háttérben fut.

Ez általában csak logikai felosztást jelent, a processzor-időn továbbra is osztozniuk kell. Ha azonban több processzor van, akkor kihasználhatjuk a valódi párhuzamosságot úgy, hogy a programon nem is kell módosítani.

Probléma lehet ilyenkor a megosztott erőforrások (pl. nyomtató, memória…) közös használata. A Java nyelvbe be van építve a többszálúság támogatása. Java-ban minden szál egy objektum, ami képes zárolni az erőforrást (lock) a synchronized kulcsszóval (csak a memóriát tudja lock-olni). Ilyenkor más szál nem férhet hozzá, amíg az egyik zárva tartja. Egyéb erőforrásokat kézzel kell lock-olni: speciális objektumokkal.

4.5 Java és az Internet A Java több egy újabb nyelvnél, mert a World Wide Web programozására (is) ad megoldást. A Web elemei programozási szempontból (szerver/kliens elv):

• Szerver (server): ahol az adat (és program) van

• Kliens (client): aki eléri, feldolgozza (vagy csak megjeleníti)

A Java globálisan oldja meg a probléma minden részét egységesen!

4.5.1 Kliens/szerver programozás

Kezdetben minden interaktivitás a szerver oldalán volt: pl. statikus HTML, CGI – Common Gateway Interface (bonyolult, lassú).

A kliens programozása a megoldás: Amit csak lehet, ő hajtson végre. Ez hasonló a hagyományos programozáshoz, csak egy másik platformra: A Web böngészőt egy korlátozott operációs rendszernek lehet tekinteni.

Megoldások:

• Plug-in használata (böngésző bővítése)

• Szkript nyelvek: HTML-ben van benne a forráskód (nem lehet titkos!). Speciális problémákra speciális nyelveket fejlesztettek ki. Ilyen például a JavaScript (semmi köze a Java-hoz), VBScript, Tcl/Tk, stb. A legtöbb böngésző támogatja a JavaScript-et alapban, de némelyikhez plug-in kell.

A szkript nyelvek a problémák 80%-t megoldják, de mi van a maradék 20%-kal? Napjainkban a legnépszerűbb a Java. A kliens programozáshoz használható a Java applet, ami csak böngészőn belül fut:

• Minden böngészőn működik, ahol van Java interpreter (értelmező)

78 4.6 Java alkalmazások


• Nem a forráskód van értelmezve, hanem a lefordított kód kerül futtatásra (általában egy JAR csomag – tömörített formátum)

Egyéb, nem Java alapú megoldás az ActiveX.

• Speciális komponensként tölthető le és futtatható

• Nyelv-független (tetszőleges forráskódból fordítható)

• Régi kód is újrafelhasználható

A megfelelő technológia kiválasztásánál fontosak még a biztonsági kérdések, mert a program-letöltés vírusveszéllyel jár! Ezért korlátozzák az eléréseket (pl. Szkript, applet nem írhat lemezre). Ilyen szempontból nézve az ActiveX veszélyesebb.

Megoldás lehet a digitális aláírás használata, publikus kulcsú kódolással aláírt applet (signed applet).

Intranet programozás (lokális, cégen belüli hálózat) esetében nagyobb biztonság érhető el, mert a hibák könnyebben felderíthetők. Ilyenkor lehet speciálisabb a program is (pl. csak Windows alatt kell, hogy fusson).

Szerver oldalon mások a feladatok: Lehet egyszerű fájl kérés teljesítése, de lehet bonyolult adatbázis lekérés + HTML formázás is. Hagyományosan Perl-lel, CGI-vel valósítják meg, míg Java-ban servlet-tel, JSP-vel.

4.6 Java alkalmazások A Java nem csak Internet programozásra (pl. applet) alkalmas, hanem önálló nyelvként is kiváló (tetszőleges problémára).

Előnyei:

• Portabilitás

• Önálló alkalmazás írható (nem kell hozzá böngésző)

• Gyorsan írhatók megbízható, robusztus programok

Hátrányai:

• Generikus típusok nincsenek

• Hatékonyság hiányzik (több oka is van)

4.6.1 Miért ennyire sikeres?

A Java készítőinek fő célkitűzése a produktivitás volt. Alapoktól indulva lett megtervezve, az eddigi programozási nyelvek tapasztalatait felhasználva. Objektum orientált, kiegészítve jó osztálykönyvtárakkal. Nyelvi szintű hibakezelést (kivételek) építettek bele. Mindezek miatt nagy rendszerek írására is alkalmas.

Egy programozó szemszögéből nézve pedig azért népszerű, mert könnyű elsajátítani egy olyan szinten, amivel már megbízható program írható. A C++ sokkal nehezebb és ezért kevesebb a jó C++ programozó.



4.6.2 Java vagy C++?

Régebben azt állították, hogy a Java leváltja majd a C++-t. Már nem így van. A két nyelv más-más területeken előnyös, megfelelő célra megfelelő nyelvet kell választani.

Ha Web programozás, akkor Java. Ha új nyelvet kell megtanulni, akkor Java könnyebb, de hajlamos a programozókat „lustaságra” késztetni.

Az első Java-ban írt program 20-50-szer lassabb volt, mint a C++-ban megírt implementáció! Mára már sokkal jobb a helyzet, de drámai áttörés nem történt.

Technikák a Java programok gyorsítására:

• JIT – Just in time (futtatás előtti röpfordítás natív gépi kódra)

• Sun hotspot

• Natív fordítók

4.7 Minden objektum… A Java nyelv feltételezi, hogy objektum orientáltan fognak programozni benne. Valójában nem is lehet másképpen, a programozónak objektum orientáltan kell gondolkodnia. Ebben a fejezetben egy Java program alapvető alkotó elemeit tekintjük át, és látni fogjuk, hogy minden objektum, még maga a Java program is!

Az adatok (objektumok) manipulálása két féleképpen történhet: direkt (pl. C-ben egy változó) vagy indirekt (pl. C/C++-ban pointer; C++ és Java-ban referencia). Java-ban ezt leegyszerűsítették: minden objektum, és mindig referenciával hivatkozunk rájuk (kivéve a primitív típusokat).

4.7.1 Primitív típusok

A primitív típusok (hasonlóan a C/C++-hoz) a stack-en keletkeznek és direkt elérésűek (nem referencia által).

Primitív típusok (fix bitszélesség): Prim. Típ. Méret Min Max Wrapper boolean – – – Boolean char 16 bit Unicode 0 Unicode 216-1 Character byte 8 bit -128 +127 Byte short 16 bit -215 +215-1 Short int 32 bit -231 +231-1 Integer long 64 bit -263 +263-1 Long float 32 bit IEEE754 IEEE754 Float double 64 bit IEEE754 IEEE754 Double void – – – Void

A boolean értéke: true vagy false.

Wrapper: objektumba csomagolja a primitív típust és a heap-en tárolja. Pl.

char c = 'x';Character C = new Character('x');

További beépített típusok:

80 4.7 Minden objektum…


• BigInteger: Akármekkora egész szám

• BigDecimal: Akármekkora fix pontos szám

Tömbök:

• Referenciákat tárol ill. primitív típusnál értékeket

• Automatikusan inicializálódnak (null vagy 0)

• Indexhatár ellenőrzés van futáskor (biztonságos, de lassabb)

4.7.2 Java osztályok: Új típusok létrehozása

Új típus létrehozása: egy osztályba tartozó objektumokhoz típus hozzárendelése: class kulcsszóval, pl.

class ANewType { /* az osztály törzse */ }// ...ANewType a = new ANewType();

Önmagában nem sok mindenre jó, csak létre lehet hozni, de nem tud fogadni semmilyen üzenetet, nem tárol még semmi hasznosat, ezért személyre kell szabni…

Mezők

Az osztály állapotát jelzi, adatokat tárol. Részei: név, típus, kezdeti érték (nem kötelező). Egy osztály mezője (adattagja) lehet:

• Primitív típusú (értéket tárol, inicializálódik)

• Másik osztály típusú (referenciát tárol), létre kell hozni new-val (inicializálás). Pl.

class DataOnly {int i;float f;boolean b;

}

DataOnly d = new DataOnly();// ...d.i = 47;d.f = 1.1f;d.b = false;

Az adatok elérése: “.” (pont) operátorral.

Az így kiegészített osztály önmagában még csak adattárolásra használható…

Metódusok

Funkcionalitást biztosít az objektumoknak, meghatározza, hogy milyen üzeneteket fogadhat. Részei: név, paraméterek, visszatérési típus, törzs. Pl.

returnType methodName( /* paraméter lista */ ) {/* metódus törzs */

}

Csak osztályoknak lehetnek metódusai!

A metódus hívás valójában üzenet küldése az objektumnak. Pl.

class MethodDemo {int f(boolean b) {/*…*/}

}

MethodDemo m = new MethodDemo()// ...int i = m.f(true);

Osztályok használata



Egy fájlon belül: Egyszerűen használni kell, az sem baj, ha csak később lesz definiálva!

Külső osztályok (pl. Java osztálykönyvtárak) esetében az import kulcsszóval be kell hoznunk egy vagy több csomagot (package-t).

Pl. használni szeretnék tömböt:

import java.util.ArrayList;

Pl. használni szeretnék mindent a util-ból:

import java.util.*;

4.7.3 Az első Java program

Az első Java programunk legyen egy egyszerű kis program, ami kiírja a képernyőre, hogy „Hello” és az aktuális időt és dátumot:

import java.util.*;

public class HelloDate {public static void main(String[] args) {

System.out.println("Hello, it’s: ");System.out.println(new Date());

}}

A java.util–ban levő csomagok kellenek a Date osztály használatához. A java.lang csomag impliciten be van impoertálva minden Java programba. A java.lang.System.out egy statikus PrintStream objektum.

Ha önálló programot írunk Java-ban, akkor

• az adott fájlban kell lennie egy osztálynak, aminek ugyanaz a neve, mint a fájlnak és

• ez az osztály kell, hogy tartalmazzon egy statikus main metódust a fenti alakban

Fordítás és futtatás

Először is, kell egy Java fejlesztő környezet (Java programming environment). Feltételezzük az ingyenes Sun JDK (java.sun.com) használatát.

Fordítás: forrás (.java) → bytecode (.class)

Miután begépeltük a fenti programot egy szövegszerkesztőbe és elmentettük HelloDate.java név alatt, adjuk ki a következő parancssort:

javac HelloDate.java

Ennek eredményeképpen a Java fordító létrehoz egy HelloDate.class nevű fájlt. Ennek futtatásához, mivel a Java programok egy ún. virtuális gépen futnak, szükség van a Java futtató környezetre (Java runtime environment). Ez része a Java fejlesztő környezetnek, de letölthető és használható önállóan is. A program futtatása a következő parancssor kiadásával kezdeményezhető:

java HelloDate

Ha több java forrásfájllal dolgozunk, akkor makefile-okat szokás használni.

82 4.7 Minden objektum…


4.7.4 Megjegyzések és dokumentáció

Mint általában minden programozási nyelvben, a Java-ban is használhatunk megjegyzéseket (kommenteket). Kétféle változata van:

• Több sorod (C-szerű): pl.

/* Ez egyTöbb sorosmegjegyzés */

• Egy soros (C++ szerű): pl.

// Ez egy megjegyzés a sor végéig

Egy Java forráshoz hozzátartozik annak dokumentációja is speciális megjegyzések formájában:

/** …*/

A javadoc: program, ami összegyűjti ezeket a megjegyzéseket, segítségével készíthetünk HTML dokumentációt a programunkról.

Pl.

/*** Megjegyzés a soron következő osztály/metódus/mező-höz*/class A...

Ebbe a speciális formátumú kommentbe HTML forrásszöveget is be lehet ágyazni, ezeket a javadoc beágyazza a dokumentációba. Ezen kívül ún. tag-eket is használhatunk, amiket a javadoc értelmez, és speciálisan kezel:

• @see: más osztályokra hivatkozás – linket szúr be

• @version: verzió

• @author: szerző

• @param: metódus paraméter szerepe

• @return: metódus visszatérési értékének leírása

• @throws: metódus milyen kivételeket dobhat

Kódolási stílus

Nem hivatalos Java standard kódolási stílus ajánlott:

Osztály nevek:

• Nagy kezdőbetűvel kezdődnek

• Ha összetett szó, akkor nincs elválasztó karakter, hanem minden szó nagybetűvel kezdődjön

• Pl. AGoodClassName

Metódus-, mező nevek:

• Ua., mint az osztály nevek, csak kisbetűvel kezdődnek



• Pl. aGoodMemberName

{} zárójelezés:

• mint a példákban.

4.8 Programfutás vezérlés

4.8.1 Operátorok

Értékadás = Primitív típusoknál értékmásolást, míg objektum referenciáknál csak referenciamásolást jelent. („igazi” objektummásolás a clone() metódussal lehetséges)

Matematikai + - * / %

Összevont += -= *= /= %=

Egyoperandusú + - ++ --

Relációk == != < > <= >=

Primitív típusoknál érték összehasonlítás, míg objektum referenciáknál csak referencia összehasonlítás! („igazi” objektum összehasonlítás: equals() metódussal)

Logikai && || ! C/C++-szal ellentétben csak boolean értékekre használható. Összetett kifejezés csak addig értékelődik ki, amíg ki nem derül egyértelműen az értéke

Bitműveletek & | ^ (xor) ~ (not)

Értékadással összevont

&= |= ^=

Biteltolás << >> >>> (unsigned)

Az eredmény int vagy long típusú

Értékadással összevont

<<= >>= >>>=

Háromoperandusú if-else

boolean-exp ? val0 : val1

Vessző , Csak for ciklusban használható

Típuskonverzió (type)value Primitív típusok között használható korlátok nélkül (kivéve a boolean-t). Osztályok között csak egy öröklődési fán belül engedélyezett.

84 4.8 Programfutás vezérlés


Nincs sizeof() operátor!

Precedencia szabályok Operátor típusa Operátorok Unáris (egyoperandusú) + - ++ -- Aritmetikai (és eltolás) * / % + - << >> >>> Relációs < > <= >= == != Logikai (és bitműveletek) && || & | ^ ~ Feltételes (háromoperandusú) A > B ? X : Y Értékadás = (és összetettek, pl. +=)�

4.8.2 Vezérlési szerkezetek

A Java támogat minden C vezérlési szerkezetet, kivéve a goto-t.

Szelekciós vezérlés:

if (boolean-expression)statement

elsestatement

Visszatérés:

return value;

Kezdőfeltételes ismétléses vezérlés:

while (boolean-expression)statement

Végfeltételes ismétléses vezérlés:

dostatement

while (boolean-expression);

Számlálásos ismétléses vezérlés:

for (initialization; boolean-expression; step)statement

break [label]: megszakítja az aktuális (vagy a label-lel címkézett) ismétlést és a szerkezetet követő utasítással folytatja

continue [label]: megszakítja az aktuális (vagy a label-el címkézett) ismétlést és a következővel folytatja

Esetkiválasztásos szelekciós vezérlés:

switch (integral-selector) {case integral-value1: statement; break;case integral-value2: statement; break;case integral-value3: statement; break;// ...default: statement;

}



4.8.3 Inicializálás és takarítás

Régebbi nyelvekben a nem biztonságos programozás legfőbb okai az inicializálás hiánya és az eltakarítás hiánya volt. A C++ bevezette a konstruktor fogalmát, ami garantált inicializálást jelent objektum létrejöttekor, mert egy olyan speciális metódusa az objektumnak, ami automatikusan meghívódik. Helyette lehetne például egy initialize() metódus, de ezt mindig kézzel kellene meghívni, ami hibalehetőséget jelent. A konstruktor neve mindig megegyezik az osztály nevével. A takarítás megkönnyítésére C++-ban létezik ún. destruktor, ami automatikusan meghívódik az objektum megszűntetésekor. Java-ban ezt leegyszerűsítették, mert objektumot nem is lehet kézzel megszűntetni (automatikusan megszűnik, ha már senki sem használja). Ezért nincs destruktor sem!

Példa konstruktorra:

class Rock {Rock() {System.out.println("Creating Rock");

}}

Mint minden más függvénynek, a konstruktornak is lehetnek paraméterei. Ezek megadják, hogyan inicializáljunk. Pl. csak úgy lehet létrehozni, hogy megadjuk a magasságot is:

Tree t = new Tree(12);

Konstruktornak nincs visszatérési értéke, hanem objektumra való referenciát kapunk.

Nem csak a korrekt inicializálás fontos, hanem az erőforrások helyes kezelése is.

Java-ban ez a szemétgyűjtő (garbage collector) feladata (csak memóriával foglalkozik). Nem minden takarítást tud elvégezni. Például new nélküli memóriafoglalást (pl. natív metódus által) nem tud kitakarítani. Egyéb esetben nincs rá szükség, mert minden Object leszármazott el lesz takarítva. Segítség lehet a finalize() metódus, ami a végső takarítás előtt hívódik. Ezt debuggolásra is lehet használni.

Fontos, hogy a szemétgyűjtés végrehajtása nem szavatolt! Például ha még sok szabad memória van, elkerülhető a fölösleges lassítása a programnak. Kiszámíthatatlan, hogy mikor fog hívódni, tehát ez nem azonos a destruktor szerepével. Fontos, hogy kötelezően végrehajtandó feladatot ne rakjunk a finalize-ba (pl. fájl lezárás).

Kézzel is lehet indítványozni a futtatását:

System.gc();System.runFinalization();

Működés: több algoritmus szerint, de ez mind rejtve marad. Pl. referenciaszámlálás.

4.8.4 Operáció-kiterjesztés (Overloading)

Magasabb szintű nyelvekben neveket használunk. Természetes nyelvben is lehet több értelme a szavaknak, ilyenkor a szövegkörnyezetből derül ki az értelme.

86 4.8 Programfutás vezérlés


Programozásban ezt nevezzük overloading-nak vagy kiterjesztés-nek (túlterhelés ☺) (nem keverendő az overriding fogalmával, ami felüldefiniálást jelent, ld. később).

Régebbi nyelvekben, például C-ben, minden név egyedi volt (nincs printf int-re meg float-ra külön-külön). C++, Java-ban szükségessé vált. Például, mert a konstruktornak csak egy neve lehet, mégis különböző konstruálásokat szeretnénk.

A megoldás a metódusok kiterjesztése (nem csak konstruktor):

• Ugyanaz a neve de más a paraméter-lista (akár üres is lehet)

• Ugyanaz a feladat, miért lenne több különböző nevű függvényünk?

Pl.

class Tree {int height;Tree() { height = 0; }Tree(int i) { height = i; }

}

Az argumentum nélkül hívható konstruktort nevezzük default constructor-nak. Alapértelmezett beállításokkal rendelkező objektum létrehozására használjuk. Ha az osztályunkban nem definiálunk egy konstruktort sem, akkor a fordító automatikusan készít egy default-ot (Ha már van valamilyen – akár default akár nem – akkor nem készít).

Hogyan különböztetjük meg, hogy melyik kiterjesztett metódus hívódjon? A paraméterlistáknak egyedieknek kell lenniük. A hívás helyén az aktuális argumentumok típusai határozzák meg (ld. korai kötés).

Konvertálható primitív típusoknál bonyolultabb lehet a helyzet: Ha nincs pontos egyezés, akkor az adat konvertálódik (de csak nagyobb értéktartományú típusokra).

A metódus visszatérési értéke nem használható a megkülönböztetésre (lehetetlen is lenne): Pl., ha egy hívásnál a visszatérési érték nincs is használva.

4.8.5 „this”

Egy függvény kódja mindig csak egy példányban van a memóriában.

Pl.

Class Banana { void f(int i) {/*…*/} }Banana a = new Banana(), b = new Banana();a.f(1);b.f(2);

Honnan tudja az f(), hogy melyik objektumhoz lett hívva? Egy „titkos” implicit első paramétert generál a fordító.

Explicite is felhasználható, pl.:

• Ha a metódus formális paraméterneve megegyezik valamelyik mező nevével:

this.x = x; // az első az attribútum

• Visszaadni egy metódussal:



class Leaf {int i = 0;Leaf increment() { i++; return this; }

}/* ... */ x.increment().increment();

4.8.6 Mezők inicializálása

Lokális változókat kötelező explicite inicializálni.

Adattagok inicializálására a következő módok vannak:

• Nincs explicite inicializálva – a primitívek „0” alapértelmezett (default) értéket kapnak, a nem primitívek pedig null értéket (nincs memória foglalva)

• Definíció helyén

• Instance initialization clause (lásd a példában)

• Konstruktorral (az előző kettő után hívódik)

Példa:

class A {char c; // defaultint i = 1; // definíció helyénfloat f = init(); // függvénnyelB a = new B(); // nem primitívC c1;C c2;// instance initialization clause:{

c1 = new C(1);c2 = new C(2);

}A() { i = 2; } // default konstruktorral

// előbb 1, utána 2A(int i) { this.i = i; }

}

4.8.7 Tömbök

A tömb egy névvel ellátott (egyetlen azonosítóval kezelt) azonos típusú elemek (primitív vagy nem) sorozata. Java-ban a tömb is egy objektum.

Deklarálás:

int[] a1; vagy

int a1[];

A méretét nem lehet megadni, mert csak akkor foglalódik le, amikor inicializáljuk. Deklaráláskor csak egy referenciánk van a tömbre. Inicializálás (helyfoglalás):

• Tár foglalása ekvivalens a new használatával

• Inicializáló kifejezéssel:

int[] a1 = { 1, 3, 4 };

• Tömbmásolással:

int[] a2 = a1;

88 4.9 Implementáció elrejtése


• Lefoglalt terület elemei 0-ra lesznek inicializálva

Tömb objektumok mérete:

a1.length;

Csak olvasható, pl.

for (int i = 0; i < a1.length; i++)System.out.println(a1[i]);

Biztonságos, mert túlindexelésnél nincs elszállás, hanem kivétel lesz dobva. Ezek az extra funkcionalitások lassíthatják a programot.

Inicializálás futás közben (méret nem ismert előre):

int i;i = /* ??? */;int[] a1 = new int[i];

Nem primitív típusok tömbjei esetében csak referenciák tárolódnak. Ezért az elemeket new-val kell lefoglalni. Lehet bonyolult is az inicializálás:

Integer[] a1 = new Integer[3];a1[0] = new Integer(500);Integer[] a2 = new Integer[] {

new Integer(1),new Integer(2),

}; // new Integer[] elhagyható

A többdimenziós tömbök hasonlóak az egydimenzióshoz

int[][] a2d = { {1,2,3}, {4,5,6} };

Egyéb kombinációk:

int[][][] a3d = new int[2][3][5];

4.9 Implementáció elrejtése OO Tervezés alapkövetelménye különválasztani a változó dolgokat a nem változóktól. Osztálykönyvtárak esetén ez különösen fontos:

• kliens kódja változatlan maradhat, ha a könyvtár változik is,

• kívülről elérhető részek ne változzanak, de

• szabadon változhat a rejtett rész

Az ilyen fajta elrejtést szolgálják az elérést vezérlők (access specifiers, láthatóság).

Elérések (növekvő szigorúság szerint):

• public, protected, friendly (nincs rá kulcsszó), private

Könyvtár (library) egységeinek elérését is szabályozhatjuk. A Java osztályok általában ún. csomagokba (package) vannak rendezve. Az elérés vezérlésének teljes értelme csak a csomagok használatával jön elő. Egy csomagot az import kulcsszóval érünk el.



4.9.1 Csomagok

Csomagokban levő osztályokra ún. minősített névvel tudunk hivatkozni. Például a java.util.ArrayList név a java csomagon belüli util csomagban levő ArrayList osztályt jelenti.

import java.util.*;

Csomag importálás használata után már egyszerűen név szerint hivatkozhatunk a bennük levő osztályokra. Például elégendő ArrayList-et írni.

Lehet csak egy osztályra is kiadni:

import java.util.ArrayList;

Miért van erre szükség? Például nevek ütközésének elkerülésére. Ha nincs megadva (mint az eddigi példákban), akkor minden új osztály egy alapértelmezett csomagba default package) kerül. Ha nagy rendszert írunk, mindenképpen célszerű csomagokat használni.

4.9.2 Java forráskódok

Egy-egy Java program írásakor fordítási egységeket készítünk (compilation-, translation unit), ezekből készülnek el a class fájlok. Minden fordítási egységben lehet egy publikus osztály (public class...) amelynek a neve meg kell, hogy egyezzen a fájl nevével (.java nélkül). Lehetnek a fájlban egyéb (rejtett) osztályok is.

A java fájl fordításával class fájlok jönnek létre (egy-egy minden egyes osztályhoz). Java-ban nincs linker (a class fájlok önállóak), de lehet őket tömöríteni jar fájlba, ami lényegében megegyezik a szabványos zip tömörítéssel. A class fájlokat a Java virtuális gép értelmezi és hajtja őket végre egyenként.

4.9.3 Csomagok

A csomag (package) nem más, mint class fájlok halmaza. Melyik csomagba tartoznak? Forrásfájl első nem-komment sorába be kell írni:

package mypackage;

Ez azt jelenti, hogy a benne levő publikus osztály a megadott csomaghoz fog tartozni. Használata: mint már láttuk:

mypackage.MyClass m; vagy

import mypackage.*;MyClass m;

Az egy csomagba tartozó osztályok egy lokális könyvtárba kerülnek a lemezen.

Mitől egyediek a csomagnevek?

• A teljes elérési útvonal bele van kódolva

• Konvenció szerint az internet domain név is benne van fordított sorrendben (pl. com.sun.java.*)

• Nem kötelező a használata, de javasolt.

90 4.9 Implementáció elrejtése


Hogy a Java interpreter megtalálja, be kell állítani a CLASSPATH környezeti változót, aminek tartalmaznia kell minden olyan elérési útvonalat, ahol Java csomagok elhelyezkednek el a lokális rendszeren. Jar fájlok esetében az is hozzá van adva (nem csak a könyvtára).

Előfordulhatnak névütközések, ha két import valami.* van, és mindkettőben van azonos nevű osztály, amit használni szeretnénk (amíg nem használunk ilyent addig nincs baj). Ilyenkor expliciten ki kell írni a csomag nevét az osztály elé.

4.9.4 Elérés vezérlése

Egy osztály tagjai elé oda kell írni az elérés vezérlés kulcsszavát (csak arra az egy tagra lesz érvényes). Ez lehet public (publikus), protected (védett), private (privát), vagy ha nincs kiírva, akkor alapértelmezett a “friendly” („barátságos”). A friendly (vagy “package access”) jelentése: Csomagon belül minden osztály eléri (public), csomagon kívül pedig nem elérhető (private). Szorosan kapcsolódó osztályokat lehet így csoportosítani (egymást használják).

Ha nem friendly-t használunk, akkor minden osztálynak saját magának kell megadnia, hogy mi az, ami elérhető benne és kinek. Ami nem kell másnak az mindig legyen privát, az interfész rész legyen publikus, a leszármazottaknak fenntartottak pedig legyenek védettek.

Megjegyzés: konstruktornak is megadhatjuk az elérését. Az objektum direkt létrehozását lehet így korlátozni.

Az elérés vezérlési kulcsszavak jelentése:

public: Mindenki elérheti (része az osztály interfészének). Default csomagon belül (nincs semmi package megadva) mindenki használhat mindent (akár különböző fájlokban szereplők is)

private: Senki nem érheti el, kivéve az adott osztály saját metódusait. Főleg rejtett implementációra és adattagokra alkalmazzák.

protected: Az adott osztály és annak származtatott osztályai elérik, a többieknek nem elérhető.

Pl.

class Cookie {protected void bite() {}

}

class Chocolate extends Cookie {public void eat() { bite(); /* ... */}

}

/* ... */Chocolate x = new Chocolate();x.bite(); // nem elérhetőx.eat(); // ok

Osztály elérés vezérlése

Csomagon belül az egyes osztályok elérését is lehet szabályozni. Publikus osztály esetében a kliens elérheti az osztályt. Pl.



public class Widget { ...

Java fájlonként csak egy publikus osztály lehet (de nem kötelező): az, amelyik a fájl nevét viseli (kis-nagy betű is számít).

Publikuson kívül lehet még friendly, ha nincs semmi kiírva (private, protected csak ún. belső osztály – inner class lehet). Ezekből csomagon kívül nem hozható létre objektum.

4.10 Osztályok újrafelhasználása Az OOP programozás (és a Java nyelv) egyik legvonzóbb tulajdonsága a kód hatékony újrafelhasználásának lehetősége. De az újrafelhasználás nem egyszerű kódmásolást jelent. Régebbi nyelvekben próbálkozás volt erre a procedurális programozás. Ennél sokkal jobb az osztály újrafelhasználása: Ne kelljen minden osztályt újból megírni, hanem építőkockaként felhasználni a meglévőket. A lényeg mindezt úgy tenni, hogy a meglévő kódot (osztályokat) ne módosítsuk.

Kompozíció: Új osztályban meglévő osztályokból készítünk objektumot.

Öröklődés: Új osztály létrehozása egy meglévő „altípusaként”, új funkcionalitás hozzáadásával.

Ezek a módszerek az alap-építőelemi az OOP-nek.

4.10.1 Kompozíció

Kompozíció: összetétel, aggregáció, rész-egész kapcsolat

Egy osztály egy mezője (adattagja) másik osztály (vagy primitív) típusú (összetett osztály). Pl.

class A {private String s;int i;

}

4.10.2 Öröklődés

Minden OOP nyelvnek szerves része.

Java-ban minden új osztály implicite örököltetve van az Object-ből (direkt, vagy indirekt módon). Új osztály származtatása meglévőből: Bővíti azt (extends kulcsszó), a származtatott az ős minden adatát és metódusát megkapja – örökli az őstől.

Az öröklődés a származtatott (al-, gyermek-osztály) szempontjából specializálás, az ős (alap-, szülő-osztály) szempontjából pedig általánosítás. Pl.

class Cleanser {public void scrub() {}public void apply() {}

}

public class Detergent extends Cleanser {// metódus módosítása (felüldefiniálás):public void scrub() { super.scrub(); /* ... */ }// új metódus hozzáadása:public void foam() {}

}

/* ... */Detergent d;

d.apply();d.scrub();d.foam();

92 4.10 Osztályok újrafelhasználása


Az ősnek van néhány interfész metódusa. A származtatott ezeket mind tartalmazza, tehát az interfész újra fel van használva. A scrub() felüldefiniálja (overriding) az ősét (specializálja a viselkedését). Az őst is hívhatja a super kulcsszó segítségével (egyébként rekurzív lenne). A foam() új metódus, bővítése az ősnek.

Ős osztály inicializálása

Az öröklődés nem csak az osztály interfészét másolja, hanem a származtatottból létrejövő objektum rész-objektuma lesz az ősnek. Ős objektum ugyanolyan marad, de körül van véve a származtatott új elemeivel:

származtatott

ős

származtatott

ős

Az őst is inicializálni kell. A származtatott konstruktorában hívni kell az ős konstruktorát (hiszen ő tudja, hogyan kell). Java-ban a default ős-konstruktor automatikusan meghívódik (mindig a legősibb előbb és így lefele). Ha nem default az ős konstruktor, hanem vannak argumentumai, akkor kézzel kell meghívni a super segítségével:

class Game {Game(int i) { /* ... */ }

}

class BoardGame extends Game {BoardGame(int i) { super(i); /* ... */ }

}

public class Chess extends BoardGame {Chess() { super(64); /* ... */ }

}

4.10.3 Kompozíció és öröklődés

Sűrűn használatos a kettő együtt. Ős osztály inicializálására a fordító kényszerít, de az adattag-objektumokra nekünk kell figyelni! Kombinált használat esetén „rendes” takarítás szükséges. Java-ban nincs destruktor, ehelyett van a garbage collector (de ez kiszámíthatatlan).

Kompozíció vagy öröklődés?

Mindkettőnél az új osztály rész-objektumokat tárol. Mi a különbség és mikor melyiket használjuk?

Kompozíció: egy meglévő osztály funkcionalitását felhasználjuk, de az interfészét nem (a kliens csak az új osztály interfészét látja). Ezért a beágyazott objektum általában privát típusú, de lehet publikus is (biztonságos, mert úgyis csak az interfésze elérhető) ha a kliensnek fontos tudnia hogy miből állt össze az objektum.

Öröklődés: egy meglévő osztály speciális változatát készítjük el (specializálunk).

Pl. melyik mi: Autó + Kerekek vagy Jármű + Autó

Sokszor hajlamosak vagyunk arra, hogy mindenhol az öröklődést használjuk, mert az OOP tulajdonság! Nem mindig ez a jó. Kezdetben induljunk ki mindig a kompozícióból, majd ha kiderül hogy az új osztály mégis egy speciális típusa a



másiknak, akkor származtassunk. Származtatásnak elsődlegesen akkor van létjogosultsága, ha ősre való konvertálás is szükséges lesz (lásd később). Túl sok származtatás és mély osztályhierarchiák nehezen karbantartható kódot eredményezhetnek!

Ősre konvertálás (Upcasting)

Mivel a származtatott az ős osztály egy új típusa, logikus hogy, mindenhol ahol az ős használható, ott a származtatott is használható. Ez azt jelenti, hogy ahol ős típusú objektumot vár a program, ott a származtatott egy implicit konverzión megy át az ősbe. Ezt már korábban is láttuk. Példa:

class Instrument {public void play () {}

}class Tuner {

static void tune(Instrument i) { /* ... */ i.play(); }}class Piano extends Instrument {

public void play() {}}

/* ... */Piano p = new Piano();Tuner.tune(p); // upcast

4.10.4 A final kulcsszó

Több jelentése van, de a lényeg: az a mi el van látva vele, az nem változhat (végső). Miért akarjuk korlátozni? Tervezési megfontolásból ill. hatékonyság miatt.

Három helyen használható: adatnál, metódusnál és osztálynál.

Végső adatok

Konstansadat létrehozása hasznos lehet:

• Ha már fordításkor eldönthető, akkor hatékonyabb kód fordítható (konstans propagálás)

• Futás közben inicializálva, de onnantól kezdve konstans.

Konstans primitív adat létrehozására egyszerűen ki kell írni a definíció elé (lehet static is, ebben az esetben a címe is fix). Nem primitív típusra használva nem az objektum lesz konstans, hanem a referencia: Inicializálás után másra már nem mutathat, de maga az objektum megváltozhat. Java-ban az objektumok nem tehetők konstanssá, csak a viselkedésükkel lehet azt szimulálni.

Üres végsők (blank final) olyanok, amik nem kapnak azonnal értéket, de a konstruktorban inicializálni kell.

Metódus paramétere is lehet final (csak olvasható).

Pl.

94 4.11 Polimorfizmus


class FinalData {final int i = 9;static final int VAL = 99; // csak egy van belőlefinal Value v2 = new Value();final int j = (int)(Math.random()*20); // futás közben!final int k; // blankFinalData(int i) { k = i; }void f(final int i) { i++; } // hiba: i nem változhat

}

Végső metódusok

Két dologra használjuk: Meggátoljuk a származtatott osztályokat abban, hogy felüldefiniálják és megváltoztassák a viselkedését, és hatékonyság végett, a fordító számára megmondjuk, hogy a metódus hívását ún. inline hívásokká alakíthatja, a hívás helyett a hívott függvény kódja be lesz másolva.

Minden private metódus implicite final lesz: Nem lehet felüldefiniálni, mert privát. Ha mégis megpróbáljuk, akkor új metódust kapunk.

Végső osztályok

Osztályra is mondhatjuk, hogy legyen végső: final class…

Azt jelenti, hogy belőle nem lehet új osztályokat származtatni. Biztonsági vagy hatékonysági megfontolásból tehetjük. Minden metódus is implicite végső lesz (nem lehet származtatni, ezért felüldefiniálni sem). Ugyanazok a hatékonysági megfontolások érvényesek lesznek, mintha ki lenne írva.

4.11 Polimorfizmus A harmadik lényeges OOP tulajdonság az adatabsztrakció és öröklődés után a polimorfizmus.

Pl.

class Note {private int value;private Note(int val) { value = val; }public static final NoteMIDDLE_C = new Note(0), C_SHARP = new Note(1),B_FLAT = new Note(2);

}class Instrument {public void play(Note n) {System.out.println("Instrument.play()");

}}class Wind extends Instrument {public void play(Note n) {System.out.println("Wind.play()");

}} public class Music {public static void tune(Instrument i) {i.play(Note.MIDDLE_C);

}public static void main(String[] args) {Wind flute = new Wind();tune(flute); // Upcasting

}}



Az előző példában a tune(flute) hívás során „elveszik” a típus, mert a metódus Instrument-et vár de Wind van átadva. Egyszerűbb lenne, ha a tune metódus Wind-et várna? Nem, mert akkor minden egyes hangszerre kellene külön tune metódus! Sőt, ha újabb hangszert szeretnénk hozzáadni, akkor mindig új metódus is kell (karbantarthatóság)!

Kései kötés

Honnan tudja a fordító, hogy melyik objektum play metódusát hívja? Nem tudja! Csak futás közben derül ki az objektum típusa alapján.

public class Music {public static void tune(Instrument i) {i.play(Note.MIDDLE_C);

}public static void main(String[] args) {Wind flute = new Wind();tune(flute); // Upcasting

}}

Bővíthetőség

A polimorfizmusnak köszönhetően tetszőleges számú új hangszert felvehetünk a tune metódus megváltoztatása nélkül. Egy jól megtervezett OO programban ezt a modellt követik, vagyis az objektumok az interfészek segítségével kommunikálnak egymással.

4.11.1 Absztrakt osztályok és metódusok

Az előző példában az Instrument ősosztályban szereplő metódusok valójában „álmetódusok”. Ha ezek véletlenül meghívódnak, akkor valami hiba van a programban, mert ezeknek a szerepe az, hogy interfész legyen. Lehetne programfutás közben kiíratni, hogy hiba van, de ennek az ellenőrzéséhez sok tesztelés szükséges. Magából az ősosztályból valójában nem kellene, hogy létrejöjjön objektum.

Ezért bevezették az absztrakt osztályokat és metódusokat (fordítási időbeni ellenőrzés)

Kulcsszó: abstract

Pl.

abstract class Instrument {/*...*/}

Ez az osztály nem példányosítható (fordítási hiba keletkezne) és közös interfészt biztosít a leszármazottaknak

Absztrakt metódus is létezik, csak deklarációja van (nincs definíciója – törzse):

abstract void f();

Ha egy osztálynak van legalább egy absztrakt metódusa, akkor neki is absztraktnak kell lennie, de egy osztály lehet absztrakt akkor is, ha nincs absztrakt metódusa.

96 4.12 Interfészek és belső osztályok


4.11.2 Futás közbeni típusazonosítás (RTTI – Run-time type identification)

Upcast (ősre konvertálás) esetén elveszítjük a konkrét típust, de a konverzió biztonságos.

Downcast (leszármazottra konvertálás) esetében jó lenne visszanyerni a konkrét típust. A konverzió egyéb nyelvekben nem biztonságos, de Java-ban ellenőrizve van (RTTI): Ha nem megfelelő típusra próbálunk downcast-olni, akkor egy ClassCastException típusú kivétel dobódik.

4.12 Interfészek és belső osztályok

4.12.1 Interfészek

Az interfész osztályok a teljesen absztrakt osztályok.

Kulcsszó: interface

Minden metódusnak csak deklarációja lehet (törzs nélküli) és impliciten publikus. A mezők impliciten static-ok és final-ok. Ez lehetővé teszi a „többszörös öröklődés”-t. Csak egy formát ad meg implementáció nélkül, egy „protokoll”-t valósít meg osztályok között.

Az implements kulcsszóval lehet származtatni belőle (implementálni).

Pl.

interface Instrument {int i = 5; // static & finalvoid play(); // Automatically publicString what();void adjust();

}

class Wind implements Instrument {public void play() {System.out.println("Wind.play()");

}public String what() { return "Wind"; }public void adjust() {}

}

Interfészt vagy absztrakt osztályt használjunk? Ha ősosztályt készítünk, akkor mindig kezdjük azzal, hogy interfész lesz. Ha mégis szükség lesz az ősosztály szintjén metódusokat implementálni, vagy mezőket hozzáadni, akkor módosítsuk absztrakt osztályra (esetleg konkrét osztályra).

4.12.2 „Többszörös öröklődés”

Mivel az interfészek nem foglalnak tárterületet, lehetővé válik a biztonságos többszörös öröklődés. Nem „igazi” többszörös öröklődésről van szó (mint pl. a C++-ban). Maximum egy db. „igazi” osztály lehet az ősök között, a többi interfész kell, hogy legyen. Interfész osztályok is származhatnak egymásból, ezzel új interfészt kapunk.

Pl.



interface CanFight {void fight();

}

interface CanSwim {void swim();

}

interface CanFly {void fly();

}

class ActionCharacter {public void fight() {}

}

class Hero extends ActionCharacter implements CanFight, CanSwim, CanFly {

public void swim() {}public void fly() {}

}

4.12.3 Konstansok csoportosítása

Mivel az interfészek mezői automatikusan static-ok és final-ok, jó eszköz arra, hogy konstansokat csoportosítsunk (hasonlít a C++-os Enum-ra).

Pl.

public interface Months {intJANUARY = 1, FEBRUARY = 2, MARCH = 3, APRIL = 4, MAY = 5, JUNE = 6, JULY = 7, AUGUST = 8, SEPTEMBER = 9, OCTOBER = 10,NOVEMBER = 11, DECEMBER = 12;

} public final class Test {public static void main(String[] args) {System.out.println(Months.MAY);

}}

4.12.4 Belső osztályok (Inner classes)

A belső osztályok az osztályon- vagy metóduson belüli osztályok. Hasznos lehet, ha logikailag összetartozó osztályokat csoportosítunk, vagy máshól nem használt algoritmust szeretnénk elrejteni a külvilágtól.

A belső osztályból elérhetőek a „körülvevő” osztály elemei (hacsak nem static a belső osztály).

Fontos kihangsúlyozni, hogy ez nem kompozíció!

.class fájlnév: OuterClass$InnerClass.class

Pl.

98 4.13 Objektumok tárolása: Kollekciók (konténerek)


public class Parcel {class Contents {private int i = 11;public int value() { return i; }

}class Destination {private String label;Destination(String whereTo) {label = whereTo;

}String readLabel() { return label; }

}public void ship(String dest) {Contents c = new Contents();Destination d = new Destination(dest);System.out.println(d.readLabel());

} public static void main(String[] args) {Parcel1 p = new Parcel1();p.ship("Tanzania");

}}

4.13 Objektumok tárolása: Kollekciók (konténerek) Csak nagyon egyszerű program esetében van előre meghatározott számú objektum ismert élettartammal. Általában ez csak futási időben derül ki. Kell, hogy legyen lehetőség objektumokat létrehozni bármikor, bárhol. Ezeknek nem lehet mindig nevet adni.

A megoldás: Kollekciók (konténerek) használata. Ilyenek:

• Beépített típus: tömb (array)

• Konténer osztályok a java.util könyvtárból

4.13.1 Tömbök

Miért jobb a tömb a többi konténernél?

• Hatékonyság: Konstans idejű az elérés, de fix a méret (flexibilis tömb: ArrayList konténer).

• Típus: Nem veszíti el a típust – adott típusú elemeket tárol, nem Object-eket.

Először mindig próbáljunk meg tömböt használni, és csak akkor válasszunk másik konténert, ha korlátba ütközünk

Az Arrays osztály

Tömbműveletekhez ad segítséget az Arrays osztály, ami a java.util könyvtár része. Statikus metódusokat tartalmaz:

• equals() – tömbök egyenlősége

• fill() – tömb feltöltése adott értékkel

• sort() – tömb rendezése

• binarySearch() – tömbben keresés

• asList() – List típusú listát készít belőle (később)



Mindegyik meg van valósítva (overload) minden primitív típusra és az Object-re.

Tömbök egyenlősége, feltöltése

Az Arrays osztály részei

equals() – Az egész tömböt összehasonlítja, elemenként

fill() – Tömb feltöltése adott értékkel

Példa:

public class ComparingArrays {public static void main(String[] args) {int[] a1 = new int[10];int[] a2 = new int[10];Arrays.fill(a1, 47);Arrays.fill(a2, 47);System.out.println(Arrays.equals(a1,a2));

}}

Tömbök rendezése

Az általános rendezőalgoritmusoknak az elemek típusaitól függetleneknek kell lenniük, vagyis össze kell, hogy tudjon hasonlítani két elemet típustól függetlenül.

Ez ún. Callback technikával oldható meg: Az elem saját maga hasonlítja magát össze egy ugyanolyan típusú másik elemmel. Két módszer van rá: Comparable és Comparator.

A „természetes módszer” a Comparable. Ilyenkor a java.lang.Comparable interfészt kell implementálni. Ennek egyetlen metódusa van: compareTo(). Ez egy objektumot vár paraméterül, a visszatérési értéke pedig: <0, ha az aktuális objektum kisebb, mint az argumentum; =0 ha egyenlő és >0 ha nagyobb, mint az argumentum.

Pl.

public class CompType implements Comparable {int i;public CompType(int n) { i = n;

}public int compareTo(Object rv) {int rvi = ((CompType)rv).i;return (i < rvi ? -1 : (i == rvi ? 0 : 1));

}public static void main(String[] args) {CompType[] a = new CompType[10];/* fill the array */Arrays.sort(a);

}}

A másik módszer a Comparator. Akkor használatos, ha nem implementálta az osztály a Comparable interfészt. Ilyenkor egy külön osztályt kell létrehozni, ami a java.lang.Comparator interfészt implementálja. Ennek két metódusa van: compare() és equals(). Általában csak a compare()-t kell implementálni, mert az Object ősosztály implementálja a másikat. Két objektumot vár paraméterül. A visszatérési érték: <0, ha az első argumentum kisebb; =0 ha egyenlő és >0 ha nagyobb mint a második objektum.



Pl.

class CompTypeComparator implements Comparator {public int compare(Object o1, Object o2) {int i1 = ((CompType)o1).i;int i2 = ((CompType)o2).i;return (i1 < i2 ? -1 : (i1 == i2 ? 0 : 1));

}}

public class ComparatorTest {public static void main(String[] args) {CompType[] a = new CompType[10];/* fill the array */Arrays.sort(a, new CompTypeComparator());

}}

Tömbben keresés

Csak rendezett tömbben lehet keresni!

Arrays.binarySearch() – bináris keresés. Visszatérési érték: ≥0 ha megtalálta (a keresett elem tömbindexe); <0 ha nem (melyik elem előtt kellene, hogy legyen).

Ha több elem is megfelel a keresésnek, akkor bizonytalan, hogy melyiket találja meg (ilyenkor használjunk inkább TreeSet-et, lásd később). Ha Comparator-ral lett rendezve, akkor meg kell adni ugyanazt a Comparator objektumot a keresésnek is.

Pl.

public class ArraySearching {public static void main(String[] args) {int[] a = new int[100];/* fill the array */Arrays.sort(a);/*...*/int location = Arrays.binarySearch(a,19);if(location >= 0) {/* element found */

}}

}

Tömbök másolása

System.arraycopy() statikus metódus.

Meg van valósítva minden primitív típusra és az Object-re (csak a referenciák másolódnak!)

public class CopyingArrays {public static void main(String[] args) {int[] i = new int[25];int[] j = new int[25];/*...*/System.arraycopy(i, 0, j, 0, i.length);/*...*/

}}

4.13.2 Kollekciók (konténerek)

A konténer osztálykönyvtár egyike a leghatékonyabb programozási eszközöknek



Java 2-ben teljesen újratervezték (a Java 1.x verziókban nagyon gyengére sikeredett)

Két koncepció:

• Kollekció (Collection): Egyéni elemek csoportja, általában valamilyen szabályossággal (listában sorrendiség, halmazban egyediség, stb.)

• Leképezés (Map): Kulcs-adat kettősök csoportja, a kulcsra gyors keresést biztosít

Pl.

public class PrintingContainers {static Collection fill(Collection c) {c.add("dog");c.add("dog");c.add("cat");return c;

}static Map fill(Map m) {m.put("dog", "Bosco");m.put("dog", "Spot");m.put("cat", "Rags");return m;

}public static void main(String[] args) {System.out.println(fill(new ArrayList()));System.out.println(fill(new HashSet()));System.out.println(fill(new HashMap()));

}}

Output:

[dog, dog, cat][cat, dog]{cat=Rags, dog=Spot}

A konténerek hátránya

Elveszítik a típust

• Mindig Object-eket tárolnak

• Általános célú konténerek: Nem tárolhatnak specifikus típusú objektumokat

Bármi belerakható – nincs típusellenőrzés

• Pl. egy macskákat tároló konténerbe nyugodtan bele lehet tenni kutyákat (csak az Object referenciát teszi bele)

Downcast-olni kell az elemet használat előtt!

4.13.3 Iterátorok

Minden konténernek támogatnia kell az elemek hozzáadását, illetve elérését.

Pl. ArrayList esetében ez könnyű: add(); get()

Ennél általánosabb, absztraktabb megoldás kell. Generikus kódot szeretnénk írni, ami nem függ a használt konténertől (ne kelljen újraírni). A megoldás az iterátorok használata.

Egy iterátor egy objektum, ami végighalad egy objektumsorozaton anélkül, hogy a felhasználó programozó tudna róla, hogy milyen konkrét belső struktúrája van a konténernek. A Java iterátor tudása:

• Kérni lehet egy Iterator objektumot a konténertől az iterator() metódushívással



• Kérni lehet a következő elemet a next() metódussal (a legelsőt is next()-tel kérjük!)

• Meg lehet kérdezni, hogy maradt-e még elem a sorozatban a hasNext() metódussal

• Törölni lehet az iterátorral lekért elemet remove()-val

Pl.

import java.util.*;

class Hamster {private int hamsterNumber;Hamster(int i) { hamsterNumber = i; }public String toString() {return "This is Hamster #" + hamsterNumber;

}}class Printer {static void printAll(Iterator e) {while(e.hasNext())System.out.println(e.next());

}}public class HamsterMaze {public static void main(String[] args) {ArrayList v = new ArrayList();for(int i = 0; i < 3; i++)v.add(new Hamster(i));

Printer.printAll(v.iterator());}

}

Output:

This is Hamster #0This is Hamster #1This is Hamster #2

4.13.4 Konténer osztályhierarchia

Iterator Collection Map

ListIterator

List SetProduces

HashMap TreeMap

HashSet TreeSet

WeakHashMap

ArrayList LinkedList

ProducesProduces

Collections

Arrays

Utilities

Comparable Comparator

Iterator Collection Map

ListIterator

List SetProduces

HashMap TreeMap

HashSet TreeSet

WeakHashMap

ArrayList LinkedList

ProducesProduces

Collections

Arrays

Utilities

Comparable Comparator

4.13.5 Collection (List, Set) funkcionalitása

boolean add(Object) – elem hozzáadása

boolean addAll(Collection) – elemek hozzáadása

void clear() – töröl minden elemet

boolean contains(Object) – true, ha tartalmazza az elemet



boolean containsAll(Collection)– true, ha tartalmazza az elemeket

boolean isEmpty() – true, ha üres

Iterator iterator() – visszaad egy iterátort

boolean remove(Object) – elem törlése

boolean removeAll(Collection) – minden elem törlése

boolean retainAll(Collection) – csak akkor tartja meg az elemet, ha az

szerepel a paraméterben (metszet)

int size() – elemek száma

Object[] toArray() – felépít egy tömböt, ami tartalmazza a konténer elemeit

Object[] toArray(Object[] a) – mint az előző, csak szűri típus szerint: csak az a paraméterben kapott típusú elemeknek megfelelő típusú elemekből építi fel a tömböt

4.13.6 Lista

List (absztrakt) – Elemeket tárol adott sorrendben. Oda-vissza be lehet járni a listát, és be lehet szúrni elemeket a listába elemek közé is a ListIterator segítségével. Két féle megvalósítása van:

• ArrayList – Tömbbel megvalósított lista: Gyors elemelérés de lassú beszúrás/törlés, és

• LinkedList – „Igazi” láncolt lista: Gyors beszúrás/törlés de lassú elemelérés. Plusz metódusokat tartalmaz, hogy használható legyen stack-, queue- és deque-ként (addFirst(), addLast(), getFirst(), getLast(), removeFirst(), removeLast()).

4.13.7 Halmaz

Set (absztrakt) – Egyedi elemeket tárol sorrendiség nélkül. A tárolt elemeknek definiálniuk kell az equals() metódust. Két változata van:

• HashSet – Gyors keresést biztosító halmaz (a tárolt elemeknek definiálniuk kell a hashCode() metódust)

• TreeSet – Rendezett halmaz (first() – a legkisebb elem; last() – a legnagyobb elem; subSet(from,to), headSet(to), tailSet(from) – visszaadja a fának egy részét)

4.13.8 Map funkcionalitása

void clear() – töröl minden elemet

boolean containsKey(Object) – true, ha tartalmazza a kapott kulcsú elemet

boolean containsValue(Object) – true, ha tartalmazza a kapott tartalmú elemet

104 4.14 Hibakezelés kivételekkel


Set entrySet() – visszaadja halmazként a tárolt adatokat

Object get(Object key) – a kapott kulcsú elemet adja vissza

boolean isEmpty() – true, ha üres

Set keySet() – visszaadja halmazként a tárolt kulcsokat

Object put(Object key, – beszúr egy új elemet (párost)

Object value)

void putAll(Map) – beszúrja a kapott Map elemeit (másolás)

Object remove (Object key) – törli a kapott kulcsú elemet

int size() – elemek száma

Collection values() – visszaadja kollekcióként a tárolt elemeket

4.13.9 Leképezés

Map (leképezés) – Kulcs-adat objektum-párok csoportja, a kulcsra gyors keresést biztosít. Két változata van:

• HashMap – Hash-táblával implementált, keresésre/beszúrásra optimalizálva.

• TreeMap – Piros-fekete fával implementált, rendezetten tárolja az elemeket (firstKey() – a legkisebb kulcs; lastKey() – a legnagyobb kulcs; subMap(from,to), headMap(from), tailMap(to) – visszaadja a fának egy részét).

4.14 Hibakezelés kivételekkel Java alapfilozófia: Rosszul formált kód nem fog futni. Ideális lenne, ha minden hibát fordítási időben ki lehetne deríteni, de a valóságban nem így van. Korábbi nyelvekben (pl. C-ben) a hibakezelés inkább csak konvenció volt: Tipikusan, a függvény visszaad egy hibakódot, vagy beállít egy jelzőt, amit a hívó fél kell(ene), hogy ellenőrizzen, de ez általában elmarad: pl. ki ellenőrzi le, hogy a printf() mit ad vissza?

A megoldás: Nyelvi szinten beépíteni és megkövetelni a hibakezelést.

Ez nem a Java találmánya, már az 1960-as években ismerték operációs rendszer szinten. A Java kivételkezelése a C++-on alapul (esetleg az Object Pascal-on), a C++ kivételkezelése pedig az Ada-n.

A kivételekkel történő hibakezelés még egy jelentős előnyhöz juttat: „Megtisztul” a kód, mert különválik az „igazi” kód a hibakezeléstől.

4.14.1 Kivételek

Kivételes feltétel: egy probléma, ami meggátolja a programfutást egy adott metódusban (blokkban). Egyszerű példa a null referencia: Érdemes leellenőrizni és kivételt „dobni” ahelyett, hogy folytatnánk:

if (p == 0)throw new NullPointerException();



Kivétel dobáskor (throw) egy kivétel objektum jön létre a heap-en. Az aktuális programvégrehajtás megáll és a kivétel objektum referenciája „kidobódik”. A kivételkezelő mechanizmus veszi át az irányítást és keres egy megfelelő kivételkezelőt, ami lekezeli a hibát és folytatja a program végrehajtását.

4.14.2 Kivételek argumentumai

Minden beépített kivételnek két konstruktora van: a default, és ami egy string-et vár (ezt később fel lehet használni)

if (p == 0)throw new NullPointerException(”p is not initialized!”);

A kivételkezelés valójában egy alternatív „return” mechanizmus: A kivétel objektum van „visszaadva” (a metódus visszatérési típusa más!). Nem biztos, hogy csak egy szinttel tér vissza, hanem addig, amíg valaki nem kezeli le a kivételt.

4.14.3 Kivétel elkapása

Ha valahol el lett dobva egy kivétel, akkor az feltételezi, hogy azt valahol máshol „elkapják”.

Védett régió: A kód olyan része, ami kivételeket hozhat létre, és amit a hibakezelő kód követ.

Pl.

try {// „normál kód”, amiben kivétel keletkezhet// (védett régió)

} catch(ExceptionType1 e1) {// hibakezelő kód az e1 kivételre

} catch(ExceptionType2 e2) {// hibakezelő kód az e2 kivételrethrow e2; // tovább is lehet dobni

} catch(Exception e) {// hibakezelő kód az összes (megmaradt) kivételre

}

4.14.4 Saját kivételek

Saját kivételeket is lehet írni, származtatni kell valamelyik létező kivétel osztályból (pl. Exception (ős)osztályból).

Pl.

106 4.15 Egyéb Java technológiák


class SimpleException extends Exception {}

public class SimpleExceptionDemo {public void f() throws SimpleException {System.out.println("Throwing SimpleException from f()");

throw new SimpleException();}public static void main(String[] args) {SimpleExceptionDemo sed = new SimpleExceptionDemo();

try {sed.f();

} catch(SimpleException e) {System.err.println("Caught it!");

}}

}

Kivétel specifikáció

Java-ban meg kell adni, hogy egy metódus milyen kivételeket dobhat a throws kulcsszóval (ez része a metódus-deklarációnak).

Pl.

void f() throws SimpleException, NullPointerException {// ...

}

4.14.6 Java standard kivételek

Ősosztály: Throwable, két leszármazottja van:

• Error: általában nem kell vele foglalkozni (fordítási időbeni- és rendszer hibákat képvisel), és

• Exception: a Java programozó számára ez az „ősosztály”.

A kivételek részletes leírása megtalálható a Java honlapján: http://java.sun.com/j2se/1.3/docs/api/java/lang/Exception.html

4.14.7 RuntimeException

Java standard kivétel, amit nem kell külön megadni a kivétel specifikációban. Azon kivételek őse, amiket a virtuális gép dobhat normális működés közben, pl.: NullPointerException, ClassCastException, IndexOutOfBoundsException, stb.

4.15 Egyéb Java technológiák

4.15.1 Futás közbeni típusazonosítás (RTTI) és a reflection mechanizmus

A futás közbeni típusazonosítás (RTTI) lehetővé teszi, hogy megállapítsuk egy objektum valódi típusát akkor, amikor csak az ősére mutató referenciánk van.

A Class osztály

Osztályokról hordoz információt (ún. meta-osztály). Ez az osztály van használva az összes többi osztály létrehozására.



A program minden osztályához tartozik egy Class objektum, ami fordításkor jön létre és a megfelelő class fájlba el van tárolva. Futási időben a virtuális gép ellenőrzi, hogy a szükséges Class objektum be van-e már töltve, és ha nem, akkor betölti azt. Egy Java program futtatásakor nem töltődik be teljes egészében a memóriába, hanem mindig csak a szükséges részek (osztályok). Ha a megfelelő típushoz tartozó Class objektum be lett töltve, akkor abból jön létre az összes ilyen típusú objektum (hasonló a klónozáshoz). Minden objektum tartalmaz egy referenciát az ő Class objektumára, ami tartalmazza többek között a típus konkrét nevét.

Class.forName

Statikus metódus, segítségével lekérhető osztálynév alapján a Class objektum referenciája. Pl. Class c = Class.forName(”MyClass”);

Class literal

Egy konkrét objektum Class objektum referenciája elérhető direkt is (statikus attribútum): Pl. Class c = MyClass.class;

instanceof kulcsszó

Leellenőrizhető, hogy egy objektum adott típusú-e: Pl.

if (myObj instanceof MyClass) ...

Ugyanez elérhető a Class objektum isInstance metódusával is:

if (MyClass.class.isInstance(myObj)) ...

Reflection

A futás közbeni típusazonosítás csak akkor működik, ha ismert a típus már fordítási időben. Java-ban viszont használhatunk olyan (ismeretlen) osztályokat is, amelyek nem is részei a mi programunknak (pl. utólag letöltődik a hálózatról).

java.lang.reflect csomag

A következő osztályokat tartalmazza:

Field, Method és Constructor (mind a Member interfészt implementálja).

A virtuális gép hozza létre a megfelelő objektumokat belőlük, amik az ismeretlen osztály megfelelő tagjait képviselik. Ezek után használhatjuk a Constructor-t, hogy új objektumokat hozzunk létre az ismeretlen osztályból, használhatjuk a get() és set() metódusokat, hogy írjuk/olvassuk a Field objektumok által képviselt attribútumok értékét, és az invoke() metódust, hogy meghívjuk a Method objektumok által képviselt metódusokat.

Pl. A MyClass osztály metódusainak és konstruktorainak kiíratása: Class c = Class.forName(”MyClass”); Method[] m = c.getMethods(); Constructor[] ctor = c.getConstructors(); for (int i = 0; i < m.length; i++) System.out.println(m[i]); for (int i = 0; i < ctor.length; i++) System.out.println(ctor[i]);



4.15.2 Távoli metódushívás (RMI)

Lehetővé teszi programkód futtatását több gépen megosztva a hálózatban. A távoli gépen élhetnek objektumok, amiknek üzenni lehet és visszaadják az eredményt.

Erősen kötődik interfészek használatához. A távoli objektumot csak interfész referenciával használhatjuk és csak ezen keresztül kommunikálhatunk vele.

A következő négy szabályt be kell tartani.

• A távoli interfésznek publikusnak kell lennie.

• A távoli interfésznek bővítenie kell a java.rmi.Remote interfészt.

• A távoli interfész minden metódusának tudnia kell dobni a java.rmi.RemoteException típust.

• A távoli objektumra csak a távoli interfészszel hivatkozhatunk (pl. ha átadjuk argumentumként vagy visszatérési értékként).

Pl. időszerver: // PerfectTime távoli interfész import java.rmi.*; public interface PerfectTimeI extends Remote { long getPerfectTime() throws RemoteException; }

A távoli interfész implementációja

A szervernek tartalmaznia kell egy osztályt, ami bővíti az UnicastRemoteObject-et, és implementálja a távoli interfészt.

Pl. // PerfectTime távoli objektum implementációja import java.rmi.*; import java.rmi.server.*; import java.rmi.registry.*; import java.net.*; public class PerfectTime extends UnicastRemoteObject implements PerfectTimeI { public long getPerfectTime() throws RemoteException { return System.currentTimeMillis(); } // Implementálni kell a konstructort a throw miatt public PerfectTime() throws RemoteException { // super(); // automatikus } // RMI regisztráció (szerver beüzemelése) public static void main(String[] args) throws Exception { System.setSecurityManager(new RMISecurityManager()); PerfectTime pt = new PerfectTime(); Naming.bind("//mymachine:2005/PerfectTime", pt); System.out.println("Ready to do time"); } }

• Be kell üzemelni a biztonságkezelőt (security manager): RMISecurityManager

• Létre kell hozni a távoli objektumo(ka)t.

• Regisztrálni kell a távoli objektumo(ka)t.



A Naming.bind híváshoz futnia kell a gépen egy külön processzben a registry-nek.

• Windows-ban: start rmiregistry

• Unix-ban: rmiregistry &

Ha nem felel meg az alapértelmezett port (1099), akkor meg kell adni a fenti parancssorban (pl. a példában 2005).

Ezek után le kell futtatni az rmic programot a lefordított kódra: rmic PerfectTime

Ennek eredményeképpen két új fájl keletkezik: PerfectTime_Stub.class PerfectTime_Skel.class

Példaprogram, ami használja a fenti távoli objektumokat: import java.rmi.*; import java.rmi.registry.*; public class DisplayPerfectTime { public static void main(String[] args) throws Exception { System.setSecurityManager(new RMISecurityManager()); PerfectTimeI t = (PerfectTimeI)Naming.lookup("// mymachine:2005/PerfectTime"); for (int i = 0; i < 10; i++) System.out.println("Perfect time = " + t.getPerfectTime()); } } ///:~

4.15.3 Common Object Request Broker Architecture (CORBA)

A Java rendkívül alkalmas a CORBA implementációjára, ezért a CORBA alapvető működését e nyelv segítségével mutatjuk be. (A Java applet-ek is kitűnően jól működhetnek mint CORBA kliensek.) A CORBA technológia részletes leírása a 3.2 részben van megadva.

A példában egy valamely gépen futó szervert valósítunk meg, amelyet a pontos idő lekérésére használhatunk. Azt is bemutatjuk, hogy hogyan lehet egy ilyen lekérdező klienst megvalósítani. Mindkettő Javaban lesz megvalósítva, de természetesen tetszőleges másik nyelvet is lehet választani.

IDL forrás elkészítése.

Az első lépés megírni a szolgáltatásunkhoz az IDL forrású interfészt, amelyet azután tetszőleges nyelvre le lehet fordítani és implementálni. Ezt a forrást a kliens és a szerver oldalon is elérhetővé kell tenni, hiszen ez lesz a két végpont között a kapcsolat. Az ExactTime szerver IDL forrása a következő:

module remotetime { interface ExactTime { string getTime(); }; };

Amint látható, maga az IDL leírás rendkívül egyszerű, az ExactTime nevű interface a remotetime névtéren belül helyezkedik el, és egy metódusa van, amely egy sztringet ad vissza.

Fordítás.



A második lépés a fenti IDL forrást lefordítani (Java esetében erre használható az idltojava program). Fordítás után létrejönnek a Java nyelvű források, amelyek a stub-ot és a skeleton-t tartalmazzák. Itt néhány forrásfájl keletkezik: a szerver és a kliens által használható _ExactTimeImplBase nevű skeleton és _ExactTimeStub nevű stub osztályok, maga az interfész Java nyelven, valamint egyéb kiegészítő osztályok.

A szerver és a kliens megvalósítása.

A fenti alaposztályokat felhasználva mint ősosztályt, megvalósíthatjuk a szervert és a klienst. Alább láthatjuk a szervert megvalósító ExactTimeServer osztály, valamint a RemoteTimeServer alkalmazást:

import remotetime.*; import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; import java.util.*; import java.text.*; class ExactTimeServer extends _ExactTimeImplBase { public String getTime(){ return DateFormat. getTimeInstance(DateFormat.FULL). format(new Date(System.currentTimeMillis())); } } public class RemoteTimeServer { public static void main(String[] args) throws Exception { ORB orb = ORB.init(args, null); ExactTimeServer timeServerObjRef = new ExactTimeServer(); orb.connect(timeServerObjRef); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("ExactTime", ""); NameComponent[] path = { nc }; ncRef.rebind(path, timeServerObjRef); java.lang.Object sync = new java.lang.Object(); synchronized(sync){ sync.wait(); } } }

Látható, hogy a szerver servant osztály megvalósítása rendkívül egyszerű, míg az ORB és egyéb CORBA szolgáltatások használata a szervert működtető alkalmazásban kicsit bonyolultabb. Csak vázlatosan említve, itt a következőket kell elvégezni:

• ORB létrehozása,

• a konkrét szerver objektum létrehozása és bejegyzése, ezt fogja a kliens elérni,

• Naming Service használata és összekötése az objektum hivatkozással,



• és végül a szerver készenléti állapotba helyezése, amikor a kliens kéréseire várakozik.

A kliens megvalósítását pl. a következőképpen tehetjük: import remotetime.*; import org.omg.CosNaming.*; import org.omg.CORBA.*; public class RemoteTimeClient { public static void main(String[] args) throws Exception { ORB orb = ORB.init(args, null); org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("ExactTime", ""); NameComponent[] path = { nc }; ExactTime timeObjRef = ExactTimeHelper.narrow(ncRef.resolve(path)); String exactTime = timeObjRef.getTime(); System.out.println(exactTime); } }

A kliens alkalmazásban is először néhány adminisztratív dolgot kell elvégezni, majd a Naming Service segítségével elkérjük a kívánt szerver-objektumra a referenciát. Ezt felhasználva már meg is hívhatjuk az interfésznek megfelelő metódust, megkapva a pontos időt a szervertől.

Aktiválás. Miután a fenti programok elkészültek, már csak annyi a dolgunk, hogy elindítsuk először a szerver alkalmazást, majd azután a kliens program végrehajtásával megkapjuk a pontos időt. Mielőtt azonban a rendszer működhetne, szükség van a használt CORBA szolgáltatásokra, nevezetesen a Naming Service-nek működnie kell. A mi esetünkben ez a Java virtuális gépben fut és a hálózatot folyamatosan figyeli. A kliens működése nagyon egyszerűnek tűnik, hiszen a timeObjRef.getTime(); utasítás úgy néz ki, mint egy lokális metódushívás, pedig ez alatt egy bonyolult mechanizmus működik!

Csak megjegyzésképpen, a fenti példa a Java RMI segítségével is megvalósítható (ld. az előző, 4.15.2 részt), de a lényeges különbség hogy az IDL forrásban megírt interfészt felhasználva tetszőleges nyelven lehetne az implementációkat megírni, nem csak Java-ban mint az RMI esetében. Igaz, Java-ban ez is megoldható lenne úgy, hogy valamilyen Java nyelvű wrapper-t írunk a nem Java nyelvű implementáció köré és használjuk az RMI-t, csakhogy pontosan ez az a dolog, ami a CORBA-nak az alapvető feladata!

4.15.4 Enterprise Java Beans (EJB)

Az EJB specifikáció szerver oldali komponens modellt ír le. Különböző szerepeket definiál egy nagyméretű üzleti alkalmazás létrehozatalához:

• EJB ellátó (EJB provider) –Általános, újrafelhasználható EJB komponenseket létrehozó szoftvergyártó. Ezek a komponensek speciális jar fájlba vannak csomagolva (ejb-jar fájl).

• Alkalmazás összeállító (Application assembler) – Alkalmazásokat állít elő ejb-jar fájlok segítségével.



• Telepítő (Deployer) – Futtató környezetbe (EJB tároló – EJB container) illeszti a fenti ejb-jar fájlokat és alkalmazásokat.

• EJB tároló/szerver ellátó (EJB container/server provider) – Futtató környezetet biztosít.

• Rendszergazda (System administrator) – Kezeli, irányítja a különböző komponenseket és szolgáltatásokat.

EJB komponensek

Az EJB komponensek az üzleti logikák újrafelhasználható részei, amiknek szigorú szabályoknak és tervezési mintáknak kell megfelelniük. Részei:

• Enterprise Bean – Egy Java osztály, ami egy ·Enterprise Bean interfészt implementál és bizonyos üzleti műveleteket valósít meg.

• Helyi interfész (Home interface) – Minden Enterprise Bean-hez kell egy hozzárendelt interfész, amivel a kliensek megtalálhatják, illetve létrehozhatják.

• Távoli interfész (Remote interface) – Java interfész, ami a Java Bean publikus metódusait tükrözi. Hasonló szerepe van, mint a CORBA IDL interfésznek.

• Telepítési leírás (Deployment descriptor) – XML fájl, ami információt hordoz az adott EJB-ről.

• EJB-Jar fájl – Egyszerű jar fájl, ami tartalmazza magát az EJB-t, a helyi- és távoli interfészt és a telepítési leírást.

EJB működése

Az EJB tároló implementálja a helyi- és távoli interfészt. Ő felel az EJB életciklusáért. Az EJB-hez érkező minden kérés a tárolón keresztül mehet csak át.

EJB kategóriák

Viselkedésük alapján két féle EJB-t különböztetünk meg:

• Esemény Bean – Adatokon való műveletek valósítanak meg

• Egyed Bean – Az adatokat képviselik

Példa EJB

Az előzőekben (RMI) ismertetett időszerver példát implementáljuk EJB komponensként.

Távoli interfész: A következő szabályokat be kell tartani.

• A távoli interfésznek publikusnak kell lennie.

• A távoli interfésznek bővítenie kell a javax.ejb.EJBObject interfészt.

• A távoli interfész minden metódusának tudnia kell dobni a java.rmi.RemoteException típust.

• Minden objektum, amit pl. argumentumként át lehet adni, érvényes RMI-IIOP adattípusnak kell lennie.



// PerfectTimeBean távoli interfész import java.rmi.*; import javax.ejb.*; public interface PerfectTime extends EJBObject { public long getPerfectTime() throws RemoteException; }

Helyi interfész: A következő szabályokat be kell tartani.

• A helyi interfésznek publikusnak kell lennie.

• A helyi interfésznek bővítenie kell a javax.ejb.EJBHome interfészt.

• A távoli interfész minden create metódusának tudnia kell dobni a java.rmi.RemoteException és javax.ejb.CreateException típusokat.

• A create metódus visszatérési értéke távoli interfész kell, hogy legyen.

• A finder metódus visszatérési értéke távoli interfész, java.util.Enumeration vagy java.util.Enumeration kell, hogy legyen entitás Bean-ek esetében.

• Minden objektum, amit pl. argumentumként át lehet adni, érvényes RMI-IIOP adattípusnak kell lennie.

// PerfectTimeBean helyi interfész import java.rmi.*; import javax.ejb.*; public interface PerfectTimeHome extends EJBHome { public PerfectTime create() throws CreateException, RemoteException; }

EJB implementáció (üzleti logika): A következő szabályokat be kell tartani.

• Az osztálynak publikusnak kell lennie.

• Az osztálynak implementálnia kell egy EJB interfészt (javax.ejb.SessionBean vagy javax.ejb.EntityBean).

• Definiálnia kell a távoli interfészben levő metódusoknak megfelelő metódusokat.

• Egy vagy több ejbCreate() metódust kell definiálnia az EJB inicializálásához.

• Minden objektum, amit pl. argumentumként át lehet adni, érvényes RMI-IIOP adattípusnak kell lennie. import java.rmi.*; import javax.ejb.*; public class PerfectTimeBean implements SessionBean { private SessionContext sessionContext; public long getPerfectTime() { return System.currentTimeMillis(); } // EJB metódusok public void ejbCreate() throws CreateException {} public void ejbRemove() {} public void ejbActivate() {}



public void ejbPassivate() {} public void setSessionContext(SessionContext ctx) { sessionContext = ctx; } }

Ezek után létre kell hozni a telepítési leírást (deployment descriptor): <?xml version="1.0" encoding="Cp1252"?> <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN' 'http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd'> <ejb-jar> <description>Example for Chapter 15</description> <display-name></display-name> <small-icon></small-icon> <large-icon></large-icon> <enterprise-beans> <session> <ejb-name>PerfectTime</ejb-name> <home>PerfectTimeHome</home> <remote>PerfectTime</remote> <ejb-class>PerfectTimeBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> <ejb-client-jar></ejb-client-jar> </ejb-jar>

Példa kliensre: // Kliens program a PerfectTimeBean használatára public class PerfectTimeClient { public static void main(String[] args) throws Exception { javax.naming.Context context = new javax.naming.InitialContext(); Object ref = context.lookup("perfectTime"); PerfectTimeHome home = (PerfectTimeHome)javax.rmi.PortableRemoteObject.narrow( ref, PerfectTimeHome.class); PerfectTime pt = home.create(); System.out.println("Perfect Time EJB invoked, time is: " + pt.getPerfectTime()); } } ///:~

4.15.5 JNI – Java Native Interface

Habár a Java egy teljes nyelv, szükség lehet rá, hogy egyéb nyelveken íródott programkódot is használjunk (pl. sebesség-kritikus alkalmazásoknál, vagy már meg van írva és nem szeretnénk újraírni Java-ban). Jelenleg csak a C és C++ nyelvek vannak támogatva.

Kulcsszó: native

Pl. Natív metódus hívása. A ShowMessage egy natív metódus, ami meg fogja hívni a printf() C könyvtári függvényt:

ShowMessage.java:

public class ShowMessage {



private native void ShowMessage(String msg); static { System.loadLibrary("MsgImpl"); } public static void main(String[] args) { ShowMessage app = new ShowMessage(); app.ShowMessage("Generated with JNI"); }

A System.loadLibrary("MsgImpl") hívás betölt egy DLL-t (lásd később).

Ezek után a lefordított class fájlból C header-t kell generalni a javah programmal:

javah ShowMessage

Ennek az eredménye (kommentek törölve):

ShowMessage.h: #include <jni.h> #ifndef _Included_ShowMessage #define _Included_ShowMessage #ifdef __cplusplus extern "C" { #endif JNIEXPORT void JNICALL Java_ShowMessage_ShowMessage (JNIEnv *, jobject, jstring); #ifdef __cplusplus } #endif #endif

Ezek után meg kell írni a programkódot, ami megvalósítja a Java_ShowMessage_ShowMessage natív metódust, majd le kell fordítani a fenti DLL-be (a példában MsgImpl.dll).

ShowMessage.cpp: #include <jni.h> #include <stdio.h> #include "ShowMessage.h" extern "C" JNIEXPORT void JNICALL Java_ShowMessage_ShowMessage(JNIEnv* env, jobject, jstring jMsg) { const char* msg=env->GetStringUTFChars(jMsg,0); printf("Thinking in Java, JNI: %s\n", msg); env->ReleaseStringUTFChars(jMsg, msg); }

A natív metódus argumentumai képezik a kaput vissza a Java-ba (virtuális gépbe).

JNIEnv* – segítségével visszahivatkozhatunk a virtuális gépbe

jobject – lényegében a hívó Java-beli objektum this referenciája

A többi paraméter az eredeti Java natív metódus paraméterei (jstring).

4.15.6 Java Mail

A Java Mail API a Sun egyik legújabb fejlesztése, amivel könnyen lehet platform- és protokoll független levelezési rendszereket készíteni kliens és szerver oldalon egyaránt.

Java Mail API alaposztályok:



javax.mail.Session

Az API belépési pontja. Innen érhetők el az ún. service provider implementációk a különböző protokollokhoz (POP3, SMTP, IMAP4).

javax.mail.Store

Konkrét protokollhoz valósít meg írás/olvasást, keresést és figyelést.

javax.mail.Transport

Konkrét protokollon keresztül történő üzenetküldést valósít meg.

javax.mail.Folder

Hierarchikus elrendezést biztosít a leveleknek, és elérhetővé teszi a leveleket javax.mail.Message típusú objektumok formájában.

javax.mail.Message

Egy konkrét e-mail-t tesz elérhetővé. Hozzáférést biztosít minden részlethez, pl. feladó címe, tárgy, stb.

el adás vázlat szerz k: beszédes Árpád és ferenc …tar.inter-studium.hu/csharp/oo.pdf•...

Documents