A SZOFTVERTECHNOLÓGIA ALAPJAI Objektumorientált tervezés 8.előadás PPKE-ITK
Tartalom 8.1 Objektumok és objektumosztályok 8.2 Objektumorientált tervezési folyamat 8.2.1 Rendszerkörnyezet, használati esetek 8.2.2 Architekturális tervezés 8.2.3 Objektumok azonosítása 8.2.4 Tervezési modellek 8.2.5 Az objektumok interfész specifikációja 8.3 A terv evolúciója Kiegészítés: CORBA PPKE-ITK Szoftvertechnológia-2011 8 / 2
Az objektumorientált fejlesztés Az objektumorientált fejlesztés az alábbi összefüggő, de különálló - fázisokból áll: Objektumorientált elemzés (OOA): Az alkalmazás objektumorientált modelljének kidolgozása. Objektumorientált tervezés (OOD): A követelményeknek megfelelő szoftverrendszer objektumorientált modelljének kidolgozása. Objektumorientált programozás (OOP): A szoftverterv objektumorientált programnyelven történő megvalósítása. Az egyes fázisok között nincs explicit határvonal, egy következő lépés az előző finomításával jár. PPKE-ITK Szoftvertechnológia-2011 8 / 3
Az objektumorientált tervezés lényege Az objektumok a valódi világ vagy egy rendszer elemeinek absztrakciói, amelyek karbantartják saját állapotukat. Az objektumok függetlenek, de együttműködnek egymással, elrejhetik állapotukat és jellemzőiket. A rendszer funkcionalitása az objektumok szolgáltatásaiban fejezhető ki. Nem használnak megosztott adatterületeket, üzenetek útján kommunikálnak egymással. Az objektumok szétoszthatók, szekvenciálisan, vagy párhuzamosan végrehajthatók. PPKE-ITK Szoftvertechnológia-2011 8 / 4
Az objektumorientált tervezés előnyei Könnyebb a szoftvert karbantartani: Az objektumok önálló egységekként értelmezhetők. Az egyes rendszerekben egyértelmű leképezés van a való világ elemei és a rendszer objektumai között. Az objektumok megfelelő újrafelhasználható komponensek. A gyakran használt elemekre léteznek objektum-könyvtárak, A tervezési minták a gyakran előforduló struktúrákra általános, és nyelvfüggetlen mintákat adnak. PPKE-ITK Szoftvertechnológia-2011 8 / 5
8.1 Objektumok és objektumosztályok Az objektumok egy szoftver rendszer vagy a valódi világ elemeinek reprezentációi. Az osztály a hasonló tulajdonságú objektumok egy halmaza. Az osztályok közötti kapcsolatokat relációknak nevezzük. PPKE-ITK Szoftvertechnológia-2011 8 / 6
Objektumok (Def. 1) Egy objektum egy olyan entitás, amely jól körülhatárolható, állapota van és meghatározott műveletek tartoznak hozzá. Az állapotait az attribútumainak értékkészlete határozza meg. A műveletekkel szolgáltatásokat nyújt más objektumoknak. Az objektum az objektumosztály egy példánya. Az objektumosztály definíciója az objektumok templétjének tekinthető. Tartalmazza az attribútumok és szolgáltatások deklarációit, amelyek az osztályhoz tartozó objektumokhoz köthetők. PPKE-ITK Szoftvertechnológia-2011 8 / 7
Objektumok (Def. 2) Az objektumok jellemzői: Azonosítható: Az objektumok egymástól megkülönböztethetők, függetlenül az állapotuktól. Tulajdonságok, attribútumok tartoznak hozzá: Ezek lehetnek kötött, formális paraméterek is. Állapot tartozik hozzá: Az attribútumok konkrét értékei az objektum mindenkori állapotát határozzák meg. Műveletek tartoznak hozzá: Ezek lehetnek leképezések, tevékenységek, események. Korlátozott láthatósággal rendelkezik: Van látható része (export és import műveletek), Van láthatatlan része (az ábrázolás és a szolgáltatások megvalósításának részletei). PPKE-ITK Szoftvertechnológia-2011 8 / 8
Az UML modellezési nyelv Az objektumorientált tervezés során, az utóbbi 20 év során kidolgozott jelölések egységesítésével létrejött modellezési nyelv. Jelölésrendszerével az objektumorientált analízis és tervezés során készíthető modellek ábrázolását támogatja. Az objektumorientált tervezésben de-facto szabvánnyá vált. PPKE-ITK Szoftvertechnológia-2011 8 / 9
Objektumosztály Jellemzői: Hasonló tulajdonságú objektumok halmaza: Szerkezeti és viselkedésbeli jellemzők hasonlósága. Az osztálynak van neve: A nevet az osztályba tartozó összes objektum örökli. Lehetnek attribútumai, paraméterei Tartoznak hozzá szolgáltatások, műveletek: Az osztály minden objektumára, vagy az osztály egészére vonatkozó műveletek. Hozzáférési módok: public, private, protected. Tartozhat hozzá import felület: Az általa igényelt szolgáltatások definíciói. Rendelkezhet megvalósítási résszel: A megvalósítás leírása. Van látható és láthatatlan része Lehet absztrakt vagy konkrét osztály Lehet paraméteres (sablon) osztály PPKE-ITK Szoftvertechnológia-2011 8 / 10
Az Alkalmazott objektumosztály PPKE-ITK Szoftvertechnológia-2011 8 / 11
Az objektumok kommunikációja Elméletileg az objektumok üzeneteken keresztül kommunikálnak egymással. Az üzenet tartalma: A kért szolgáltatás neve, A szolgáltatás végrehajtásához szükséges információ és a szolgáltatás eredményét kérő neve. Ez a gyakran eljáráshívással és paraméterek átadásával valósul meg, amikor a szolgáltatást kérő az alábbiakat adja meg: Név = eljárás név Információ = paraméterlista PPKE-ITK Szoftvertechnológia-2011 8 / 12
A kommunikáció típusai Szinkron végrehajtás: A hívó objektum megvárja a szolgáltatás befejeződését. Az előző dián ismertetett eljáráshívás szinkron végrehajtást jelent. Párhuzamos végrehajtás: Ha az objektumok konkurens szálakként vannak implementálva, a hívó tovább folytatja működését. Ilyen esetekben és az osztott rendszerekben az objektumok kommunikációja (sokszor szöveges, pl. XML) üzenetek formájában valósul meg. PPKE-ITK Szoftvertechnológia-2011 8 / 13
Objektumosztályok közötti kapcsolatok Relációk: Asszociáció: Kétirányú társítás két osztály között. (Konkrét esetben: összekapcsolás, absztrakt esetben társítás) Aggregáció: Az osztály objektumainak egymáshoz rendelése. Kompozíció: madár veréb Egy osztály objektumai a másik osztály objektumait fizikailag tartalmazzák. Öröklődés: vállalkozás cég madár Egy általános osztályból származtatással létrehozott speciális(abb) osztály jön létre. törzstőke alkalmazott veréb PPKE-ITK Szoftvertechnológia-2011 8 / 14
Generalizáció és öröklődés Az objektumok osztályokba tartoznak, amelyek meghatározzák attribútumaikat és műveleteiket. Az osztályok hierarchiába szervezhetők, ahol egy osztálytól (szülőosztály) egy- vagy több osztály (leszármazott osztály) örökli a szülőosztály attribútumait és műveleteit. A hierarchiában alacsonyabb szinten lévő osztályok öröklik a szülőosztály attribútumait és műveleteit és újakkal egészíthetik ki azokat, sőt meg is változtathatják szülőosztályaik némelyik attribútumát, vagy műveletét. PPKE-ITK Szoftvertechnológia-2011 8 / 15
Generalizációs hierarchia PPKE-ITK Szoftvertechnológia-2011 8 / 16
Az öröklődés előnyei Az öröklődés (generalizáció) olyan absztrakciós mechanizmus, amely az entitások osztályozására használható. Lehetővé teszi az újrafelhasználhatóságot a tervezés és a programozás szintjén egyaránt. Az öröklődési diagramban ábrázolhatók a szakterülettel és a rendszerrel kapcsolatos szervezeti ismeretek. PPKE-ITK Szoftvertechnológia-2011 8 / 17
Az öröklődéssel kapcsolatos problémák Az objektumosztályok nem önállóak. Nem érthetők és értelmezhetők a szülőosztályok ismerete nélkül. A tervezők a tervezés során újra felhasználhatják az elemzés során készült öröklődési diagramokat, amivel munkát takarítanak meg, azonban nagy mértékben csökkenhet a modell hatásfoka. Az elemzés, tervezés és az implementáció során készített öröklődési diagramoknak más a feladata, ezért külön kell elkészíteni és karbantartani azokat. PPKE-ITK Szoftvertechnológia-2011 8 / 18
Öröklődés és az objektum orientált tervezés Mivel az öröklődés az OOD (objektumorientált tervezés) alapvető eszköze, ezzel kapcsolatban többféle megközelítés alakult ki: 1. Az öröklődési hierarchia azonosítása az OOD alapvető feladata. Az implementáció pedig nyilvánvalóan egy objektumorientált programozási nyelv feladata. 2. Az öröklődés az implementáció hasznos eszköze, amely segíti az attribútumok és a műveletek újrafelhasználását. Az öröklődési hierarchiát azonban nem célszerű a tervezési fázisban meghatározni, mert ezzel túl sok megkötést viszünk be az implementációba. Az öröklődés olyan fokú bonyolultságot eredményezhet, amelyet kritikus rendszerekben célszerű elkerülni. PPKE-ITK Szoftvertechnológia-2011 8 / 19
Asszociáció az UML jelöléseivel Az objektumok és objektumosztályok kapcsolatban vannak más objektumokkal és objektumosztályokkal. Az UML-ben az asszociációkat az objektumosztályok közötti vonallal és a kapcsolatot leíró megjegyzésekkel modellezik. Az asszociációk általánosak, de jelezhetik, hogy: egy objektum egy attribútuma egy vele kapcsolatban álló objektumtól, vagy egy objektum egy műveletének implementációja egy vele kapcsolatban lévő objektumtól függ. PPKE-ITK Szoftvertechnológia-2011 8 / 20
Egy asszociációs modell PPKE-ITK Szoftvertechnológia-2011 8 / 21
Konkurens objektumok Az objektumok, mint önálló entitások meghatározhatják, hogy egy kért szolgáltatás: Sorosan (A szolgáltatást kérő megvárja a szolgáltatás eredményét), vagy Párhuzamosan hajtódjon végre. Az objektumok közötti kommunikáció üzenettovábbítási modellje akár azonos-, akár különböző processzorokon futó objektumok között alkalmazható. PPKE-ITK Szoftvertechnológia-2011 8 / 22
Szerverek és aktív objektumok A konkurens objektumok kétféle módon implementálhatók: Szerverek Az objektum egy párhuzamos folyamatként van implementálva, műveletei egy külső üzenet hatására indulnak el és más műveletekkel párhuzamosan futnak. Amikor befejeződtek, várakozó állapotba kerülnek. Aktív objektumok Az objektum állapotát az objektum belső műveletei határozzák és változtatják meg, és nem külső hívások. Az objektum ezeket a műveleteket folyamatosan végrehajtja, így soha nem függesztődik fel. PPKE-ITK Szoftvertechnológia-2011 8 / 23
8.2 Objektumorientált tervezési folyamat Lépései: Definiáljuk a rendszer összefüggéseit és használatának módjait. Tervezzük meg a rendszerarchitektúrát. Azonosítsuk a rendszer legfontosabb objektumait Dolgozzuk ki a tervezési modelleket Határozzuk meg az objektumok interfészeit PPKE-ITK Szoftvertechnológia-2011 8 / 24
Egy automatikus meteorológiai állomás Az időjárási adatgyűjtő rendszerek az időjárási térkép elkészítéséhez automatikus (és egyéb) meteorológiai állomásoktól gyűjtenek adatokat. Ezek az állomások adataikat lekérdezésre küldik el. A körzeti számítógép ellenőrzi a begyűjtött adatokat, integrálja a különböző forrásokból érkező adatokat. Archiválja az integrált adatokat, majd egy digitális térkép adatbázis alapján elkészíti a helyi meteorológiai térképeket. Az elkészült térképek kinyomtathatók, illetve különböző formákban megjeleníthetők. PPKE-ITK Szoftvertechnológia-2011 8 / 25
Rétegezett architektúra Adatmegjelenítő réteg. Az objektumok az adatokat értelmezhető, olvasható formába konvertálják. Adat-archiváló, kezelő réteg. Az objektumok az adatok tárolását végzik. Adatfeldolgozó réteg. Az objektumok az összegyűjtött adatok ellenőrzésével, integrálásával és feldolgozásával foglalkoznak. Adatgyűjtő réteg. Az objektumok a távoli forrásokból származó adatok összegyűjtésével foglalkoznak. PPKE-ITK Szoftvertechnológia-2011 8 / 26
8.2.1 Rendszerkörnyezet, használati esetek Ki kell dolgozni a tervezendő szoftver és környezete közti kapcsolatokat. Rendszerkörnyezet: Statikus modell, amely alrendszerként írja le a rendszerrel kapcsolatba lépő többi rendszert. A rendszerhasználat modelljei: Dinamikus modell, amely a rendszer és környezetének interakcióit írja le,rendszerint használati eset diagrammal. PPKE-ITK Szoftvertechnológia-2011 8 / 27
A meteorológiai térképrendszer alrendszerei PPKE-ITK Szoftvertechnológia-2011 8 / 28
A weatherstation használati esete PPKE-ITK Szoftvertechnológia-2011 8 / 29
A használati eset leírása Rendszer Use case Aktorok Adatok Inger Válasz Megjegyzés Weather station Report Meteorológiai adatgyűjtő rendszer, meteorológiai állomás A meteorológiai állomás a műszerek adatait összegezi és küldi el az adatgyűjtő rendszernek. Az elküldött adatok: Maximális, minimális és átlagos talaj- és levegőhőmérséklet, max., min., és átlagos szélsebesség, teljes esőmennyiség, szélirány öt percenként vett minták. Az adatgyűjtő rendszer modemes kapcsolatot létesít a meteorológiai állomással és kezdeményezi az adatok átküldését. Az összegezett adatok átkerülnek az adatgyűjtő rendszerbe. A meteorológiai állmástól általában óránként kérnek adatokat, de a gyakoriság változhat állomásonként és időszakonként. PPKE-ITK Szoftvertechnológia-2011 8 / 30
8.2.2 Architekturális tervezés A rendszer és környezete közti együttműködés modellje adja az alapot a rendszer architektúrájának tervezéséhez. A meteorológiai állomás modellezéséhez a rétegezett architektúrát választjuk: Interfész réteg a kommunikáció kezelését végzi. Adatgyűjtő réteg a műszerektől begyűjtött adatok kezelésével, összegzésével, az adatoknak a térkép rendszerhez történő továbbításával foglalkozik. A műszerek rétege az alapadatoknak a műszerektől való összegyűjtését végzi. Az architektúra tervben lehetőleg ne legyen hétnél több réteg. PPKE-ITK Szoftvertechnológia-2011 8 / 31
A meteorológiai állomás architektúrája PPKE-ITK Szoftvertechnológia-2011 8 / 32
8.2.3 Objektumok azonosítása Az objektumorientált tervezés legnehezebb része. Nincs rá egyszerű recept. Ez a folyamat az objektumosztályok azonosítását jelenti. Az objektumok azonosítása iteratív folyamat. A finomítás során többször vissza kell térni, és módosítani kell az objektumosztályok kezdeti azonosítását. PPKE-ITK Szoftvertechnológia-2011 8 / 33
Módszerek az objektumok azonosítására Megközelítési módok: Nyelvtani megközelítés, a természetes nyelvi leírásból a főnevek az objektumok és attribútumok, az igék a műveletek és szolgáltatások. A szakterület konkrét tárgyainak, szerepköreinek, eseményeinek, interakcióinak, szervezeti egységeinek felhasználása, amit támogathat a tárolási szerkezetek (absztrakt adatszerkezetek) meghatározása. A viselkedés megértése, és az objektumok azonosítása azon az alapon, hogy melyiket ki kezdeményezte és ki vett részt benne. Forgatókönyv alapú elemzés, a rendszerhasználat különböző forgatókönyveinek elemzése alapján határozza meg az objektumokat, attribútumokat és műveleteket. PPKE-ITK Szoftvertechnológia-2011 8 / 34
A meteorológiai állomás objektumai Weather station A meteorológiai állomás és környezete közti alapinterfész. Műveletei a használati eset modellben azonosított interakciókat végzik. Weather data A műszerektől kapott összesített adatokat kezeli. Műveletei az adatokat gyűjtik össze és összegzik. Ground thermometer, Anemometer, Barometer A meteorológiai állomás műszerei, hardverek, a műveletek ezen hardverek vezérlését végzik. PPKE-ITK Szoftvertechnológia-2011 8 / 35
A meteorológiai állomás objektumai PPKE-ITK Szoftvertechnológia-2011 8 / 36
Objektumok finomítása, további objektumok A szakterületi információk alapján további objektumok azonosíthatók: A meteorológiai állomásoknak egyedi azonosítóval kell rendelkezniük. Az állomások távol vannak, ezért a műszerek meghibásodásáról automatikusan kell jelentést küldeniük. Az állomásnak szüksége van egy öntesztelő műveletre és a hozzátartozó attribútumokra is. Aktív és passzív objektumok Esetünkben az objektumok passzívak, vagyis külső kérésre gyűjtenek adatokat, nem automatikusan. Ez a vezérlést rugalmasabbá teszi. PPKE-ITK Szoftvertechnológia-2011 8 / 37
8.2.4 Tervezési modellek A tervezési modellek az objektumokat, objektumosztályokat és a különböző kapcsolatokat ábrázolják. A statikus modellek a rendszer statikus szerkezetét írják le az objektumosztályokkal és relációikkal A dinamikus modellek az objektumok közötti dinamikus interakciókat írják le. PPKE-ITK Szoftvertechnológia-2011 8 / 38
Példák a tervezési modellekre Alrendszer modellek: Az objektumok logikai csoportosítását mutatják az összefüggő alrendszerekben. Szekvencia modellek: Az objektumok interakcióinak sorrendjét ábrázolják. Állapotmodellek: Bemutatják, hogy egy objektum hogyan változtatja állapotát, válaszul az eseményekre. Egyéb modellek: Használati eset modellek, öröklődési modellek, osztálydiagramok, stb. PPKE-ITK Szoftvertechnológia-2011 8 / 39
Alrendszer modellek Bemutatják, hogyan szerveztük a tervezés során az objektumokat logikai csoportokba. Az UML-ben ezt csomagok alkalmazásával ábrázolják. Ezek logikai modellek, a rendszer aktuális megvalósításában az objektumok szervezése ettől eltérhet. PPKE-ITK Szoftvertechnológia-2011 8 / 40
Weather station csomagok PPKE-ITK Szoftvertechnológia-2011 8 / 41
Szekvencia modellek A szekvencia modellek az objektumok interakcióit sorrendben mutatják: Az objektumok az ábra tetején, egy vonalban vannak, Az időt függőlegesen, fentről lefelé ábrázolják, Az interakciókat címkézett nyilak jelzik. A nyilak stílusa utal az interakció típusára. Pl.: Normál interakció, választ vár Nem vár választ Az objektum alatti vékony téglalap arra utal, hogy a rendszer vezérlése az illető objektumnál van. PPKE-ITK Szoftvertechnológia-2011 8 / 42
Az adatgyűjtés szekvenciája CommsController WeatherStation WeatherData Request (report) Acknowledge() Report() Summarise() Reply (report) Send(report) Acknowledge() PPKE-ITK Szoftvertechnológia-2011 8 / 43
Állapotdiagramok Az állapotdiagramok bemutatják, hogyan válaszolnak az objektumok a különböző szolgáltatási kérelmekre és hogyan változtatják meg állapotukat azok hatására: Ha az objektum állapota Shutdown, a válasz a Startup () üzenet. Várakozó állapotban a rendszer újabb üzenetre vár. A reportweather() üzenetre a rendszer a Summarising állapotba lép át. A calibrate() üzenet a Calibrating állapotba viszi. Collecting állapotba kerül, ha órajelet kap. PPKE-ITK Szoftvertechnológia-2011 8 / 44
A meteorológiai rendszer állapotdiagramja PPKE-ITK Szoftvertechnológia-2011 8 / 45
8.2.5 Az objektumok interfész specifikációja Az objektumok közti interfészt úgy kell specifikálni, hogy az objektum és más komponensek tervezése párhuzamosan folyhasson. Az interfészek reprezentációjának rejtettnek kell lennie, hogy változtatható legyen. Műveleteket kell biztosítania az adatokhoz való hozzáférésre és módosításra. Egy objektumnak többféle interfésze is lehet, amelyek az objektum szolgáltatásainak különféle nézőpontból való megközelítését teszik lehetővé. Az UML osztálydiagramokat használ az interfészek specifikációjára, de Java szintén használható. PPKE-ITK Szoftvertechnológia-2011 8 / 46
8.3 A terv evolúciója Az objektumorientált tervezés könnyebben változtathatóvá teszi a rendszert azáltal, hogy az információkat az objektumokon belül tartja, így egy objektum módosítása nem érinti a többieket. Tételezzük fel, hogy a meteorológiai állomást ki kell egészíteni a légszennyezés mérésével. Ez mintát vesz a levegőből és kiszámítja a különböző szennyező anyagok mennyiségét. A szennyezés adatait az időjárás adatokkal együtt továbbítja. PPKE-ITK Szoftvertechnológia-2011 8 / 47
A szükséges változtatások Egy Air quality objektumosztályt és egy új műveletet reportairquality kell hozzáadni a WeatherStation modelljéhez A vezérlőszoftvert úgy kell módosítani, hogy a légszennyezési adatokat is begyűjtse. Egy új objektumra van szükség, amely a szennyezés mérését végzi. PPKE-ITK Szoftvertechnológia-2011 8 / 48
A légszennyezés mérése PPKE-ITK Szoftvertechnológia-2011 8 / 49
CRC tervezés CRC Class Responsibility Collaborator (Beck&Cunningham, 1989) Célja: segíteni (formalizálni) az osztályok meghatározását és rendszerezését Három fő lépés: 1. Class: Az osztályok és objektumok meghatározása (Az osztály alapvető tulajdonságai) 2. Responsibilities: Az osztályok és objektumok szerepének, feladatainak (felelősségének) és viselkedésének meghatározása. (Az osztály által nyújtott szolgáltatások magas szintű leírása.) 3. Collaborators: Az együttműködő osztályok meghatározása. (Típusok: része-, ismeri-, függ tőle) PPKE-ITK Szoftvertechnológia-2011 8 / 50
A CRC űrlap A CRC űrlap, vagy kártya Az osztály neve: Az osztály típusa: (eszköz, tulajdonság, szerep, esemény) Az osztály tulajdonságai: (konkrét, elemi, konkurens, stb.) Szülőosztály: Származtatott osztály: Feladatok: Együttműködők: PPKE-ITK Szoftvertechnológia-2011 8 / 51
Összefoglalás Az objektumorientált tervezés a szoftvertervezés olyan módszere, ahol a terv komponensei saját állapottal és műveletekkel rendelkeznek. Az objektumoknak rendelkezniük kell konstruktor és inspektor műveletekkel, az állapotuk megfigyelésére és megváltoztatására. Az objektumok implementálhatók szekvenciálisan vagy párhuzamosan is. Az UML sokféle jelölési lehetőséggel rendelkezik a különböző modellek ábrázolására. PPKE-ITK Szoftvertechnológia-2011 8 / 52
Kiegészítés: CORBA Common Object Request Broker Architecture A CORBA az Object Broker típusú integrációt szabályozza. Meghatározza az: Elosztott objektumok modelljét és a végrehajtás szemantikáját. A Distributed Object Bus architektúráját (Object Request Broker - ORB) Az interfészeket a különböző architektúrális komponensek között. Az ORB együttműködésének (interoperability) interfészeit (IIOP) Egy interfész definíciós nyelvet az objektum interéfszek specifikálására (metódusok és attribútumok) (Interface Definition Language IDL) Programozási nyelvek kapcsolatát (C, C++, Java, stb.) PPKE-ITK Szoftvertechnológia-2011 8 / 53
CORBA architektúra Felhasználó által definiált Objektumok Vertikális interészek Pénzügy Egészségügy... Horizontális interfészek Osztott dokumentumok Renszer management Információ management Task management CORBA facilities Object Request Broker (ORB) naming transactions events lifecycle properties relationships time licensing trader concurrency CORBA services query security collection startup persistence PPKE-ITK Szoftvertechnológia-2011 8 / 54
A CORBA működése IDL of service provider application object (cliens) IDL compiler (cliens) application object (cliens) stub IDL compiler (szerver) application object (service provider) skeleton Dynmic Invocation Interface Object Request Broker (ORB) Interface repository IDL Interfacde Definition Language PPKE-ITK Szoftvertechnológia-2011 8 / 55
Az absztrakt CORBA modell A kliens, amelyik szolgáltatást kér egy távoli objektumtól, az objektum azonosítójára hivatkozik, amelyet egy másik CORBA szolgáltatástól kaphat meg. PPKE-ITK Szoftvertechnológia-2011 8 / 56
ORB-k közti protokoll Több Object Request Broker közti kapcsolat Többféle kommunikációs protokollra megvalósították Legjelentősebb az Internet Inter-Orb Protocol (IIOP) PPKE-ITK Szoftvertechnológia-2011 8 / 57
A CORBA jellemzői Dinamikus szolgáltatás választás (dinamikusan felismeri az új objektumokat) Interface repository tárolja az IDL definíciókat) Dynamic invocation interface Névszolgáltatás: Név szerver Kliens Név feloldása 2 ORB Név hozzárendelése az objektumhoz 1 Szerver ORB 3 ORB Szolgáltatás kérése PPKE-ITK Szoftvertechnológia-2011 8 / 58
A CORBA előnyei Software bus az alkalmazások közti interfészre Platformok és nyelvek közti együttműködés, (De hiányzik a kód hordozhatósága) Magas szintű absztrakció Távoli objektumok metódusainak hívása (Remote Methode Invocation) Rugalmasság a futtatáskor Minden tulajdonság önleíró Dinamikus adatstruktúrák és hozzáférések Hasznos szolgáltatások Névkezelés Biztonság Stb. PPKE-ITK Szoftvertechnológia-2011 8 / 59