A SZOFTVERTECHNOLÓGIA ALAPJAI

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.


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.


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.


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).


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.


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


8 / 10

Az Alkalmazott objektumosztály


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.


8 / 13

Objektumosztályok közötti kapcsolatok Relációk: • Asszociáció:

vállalkozás

törzstőke

– 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ó:

cég

alkalmazott

– 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:

madár

veréb

– Egy általános osztályból származtatással létrehozott speciális(abb) osztály jön létre.


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.


8 / 15

Generalizációs hierarchia


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.


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.


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.


8 / 20

Egy asszociációs modell


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ó.


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.


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


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.


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.


8 / 27

A meteorológiai térképrendszer alrendszerei


8 / 28

A weatherstation használati esete


8 / 29

A használati eset leírása Rendszer Use case

Weather station Report

Aktorok

Meteorológiai adatgyűjtő rendszer, meteorológiai állomás

Adatok

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.

Inger

Az adatgyűjtő rendszer modemes kapcsolatot létesít a meteorológiai állomással és kezdeményezi az adatok átküldését.

Válasz

Az összegezett adatok átkerülnek az adatgyűjtő rendszerbe.

Megjegyzés

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.


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.


8 / 31

A meteorológiai állomás architektúrája


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.


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.


8 / 35

A meteorológiai állomás objektumai


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.


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.


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.


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.


8 / 40

Weather station csomagok


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.


8 / 42

Az adatgyűjtés szekvenciája CommsController

WeatherStation

WeatherData

Request (report) Acknowledge()

Report() Summarise()

Send(report) Reply (report) Acknowledge()


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.


8 / 44

A meteorológiai rendszer állapotdiagramja


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ó.


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.


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.


8 / 48

A légszennyezés mérése


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)


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:

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.


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 Vertikális interészek

Pénzügy

Felhasználó által definiált Objektumok

Egészségügy

...

Horizontális interfészek Osztott dokuRenszer mentumok management Információ Task management management

CORBA facilities

Object Request Broker (ORB) naming

transactions

events

lifecycle

properties

relationships

time

licensing

trader

concurrency

query

security

collection

startup

persistence


CORBA services

8 / 54

A CORBA működése IDL of service provider application object (cliens)

IDL compiler (cliens)

IDL compiler (szerver)

application object (cliens) stub

application object (service provider)

skeleton

Dynmic Invocation Interface

Object Request Broker (ORB) Interface repository •

IDL – Interfacde Definition Language


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.


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)


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

ORB Kliens

Név hozzárendelése az objektumhoz

Név feloldása

1

2 ORB

Szerver

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.


8 / 59

A SZOFTVERTECHNOLÓGIA ALAPJAI

Recommend Documents