Adatstruktúrák, algoritmusok, objektumok

Adatstruktúrák, algoritmusok, objektumok 2. Az objektumorientált programozási paradigma

Miklós Árpád, BMF NIK, 2006 [email protected]

1

A szoftverkrízis Kihívások a szoftverfejlesztés módszereivel szemben 1. A szoftveres megoldások szerepe folyamatosan erısödik – A szoftverek felhasználási aránya (még mindig) igen gyorsan nı Internet Komponensalapú rendszerek RAD programozás Online terjesztés

Asztali rendszerek Szakértıi rendszerek Párhuzamos programozás Neurális hálózatok

Többfelhasználós rendszerek Kötegelt rendszerek Valós idejő megoldások Adatbáziskezelés Egyedi szoftver Szoftvertermékek Nincs terjesztés

1950 V1.1

2006. október 10.

1960

Elosztott rendszerek Beágyazott rendszerek Olcsóbb hardver Hagyományos terjesztés

1970

1980


1990

2000 2

2

A szoftverkrízis Kihívások a szoftverfejlesztés módszereivel szemben 2. A szoftverekkel szembeni elvárások egyre magasabbak – Az élet mind több területén alkalmazunk szoftveres megoldásokat • Tudomány, oktatás, ipar, ügyvitel, bankszektor, államigazgatás, otthonok...

– Az olcsóbbodó hardver egyre szélesebb rétegek számára elérhetı • Az „átlagos felhasználó” számítástechnikai ismereteinek szintje rohamosan csökken

– A hardver teljesítménye rendkívül gyorsan növekszik • A fentiekbıl következıen az ár/teljesítmény arány még gyorsabban javul

– Ezzel párhuzamosan a szoftver funkciógazdagságával, sebességével, kényelmével, használhatóságával kapcsolatos követelmények folyamatosan emelkednek • A szoftver fejlıdési üteme egyre jobban „lemarad” a hardver fejlıdési üteme mögött

V1.1

2006. október 10.


3

3

A szoftverkrízis Kihívások a szoftverfejlesztés módszereivel szemben 3. A szoftver rendkívül jól formálható „nyersanyag” – Szinte nincsenek fizikai korlátok • • • •

A A A A

szoftver nem fizikai (anyagi) jellegő szoftver elıállítása alapvetıen nem jár közvetlen fizikai nyersanyagigénnyel szoftver, mint erıforrás mennyisége nem korlátos (végtelenül többszörözhetı) szoftvernek alapvetıen nem kell alkalmazkodnia külsı körülményekhez

– Viszonylag kevés a jogi korlát • Ezen a téren igen gyors (és sokszor önkényes) a változás

– Bármilyen algoritmus és bármilyen adatstruktúra elképzelhetı, felépíthetı, módosítható

V1.1

2006. október 10.


4

4

A szoftverkrízis Kihívások a szoftverfejlesztés módszereivel szemben 4. A programok minıségi bonyolultsága folyamatosan növekszik – A szoftver eredendıen összetett szellemi alkotás – Nincsenek, illetve nehezen önthetık formába jelentısebb ismétlıdı elemek • Tervezési minták • „Tudásinverzió”

– A mőködési állapotok száma rendkívül magas • Összetettebb programok elvi helyességének bizonyítása egyelıre nem lehetséges • A teljes körő tesztelés ezért szinte lehetetlen

– Rendszeresek és gyakoriak a változtatási igények • A fejlesztık részérıl (hibajavítás, platformváltás, fejlesztırendszer-váltás...) • A felhasználók részérıl (hibajavítás, új funkciók, funkcionális módosítások...)

V1.1

2006. október 10.


5

5

A szoftverkrízis Kihívások a szoftverfejlesztés módszereivel szemben 5. Az ember áttekintıképessége korlátos – Teljesen automatizált szoftverelıállításra egyelıre nincs mód – A bonyolultság újra és újra kezelhetetlenül magas szintet ér el • A szoftverhibák következményei egyre súlyosabbak lehetnek

Folyamatosan új megoldásokra van szükség az egyre növekvı absztrakciós szint és bonyolultság eredményes, hatékony és biztonságos kezeléséhez V1.1

2006. október 10.


6

6

Procedurális/strukturált program Definíció és jellemzık • A problémát az algoritmus (a kód) oldaláról közelíti meg – – – –

A szükséges funkciók meghatározása (funkcionális dekompozíció) A programvégrehajtás (vezérlés) pontos menetének leírása A funkciók számára szükséges adatstruktúrák meghatározása A probléma megoldását a funkciók egymás után, a megfelelı sorrendben történı végrehajtása adja meg

• Jellemzık: – A függvények definíciója határozza meg a program szerkezetét – Globális adatstruktúrák – Egy ún. „fıprogram” fogja össze, amely „függvényeket” „hív meg” • A fıprogram komoly szerepet játszik és gyakran igen bonyolult

– A végrehajtás menetét szigorúan megszabja a megírt programkód

V1.1

2006. október 10.


7

7

Procedurális/strukturált program Tipikus felépítés Fıprogram

Almodul

Almodul

Almodul Almodul

Almodul Almodul

Almodul

V1.1

2006. október 10.


8

8

Objektumorientált program Definíció és jellemzık • A problémát az adatok oldaláról közelíti meg – A szükséges absztrakt rendszerelemek meghatározása – A fenti rendszerelemek adatainak és (az adatokkal végezhetı) absztrakt mőveleteinek meghatározása, majd ezek összerendelése • Ezzel csoportokba („típusokba”) soroljuk az egyes elemeket

– A probléma megoldását az egyes objektumok közötti kommunikáció, az egyes mőveletek állapotváltozásoktól függı végrehajtása adja meg • Az objektumok kapcsolódási felülettel rendelkeznek, melynek segítségével üzeneteket váltanak egymással

• Jellemzık: – Az egyes objektumok magukban foglalják az algoritmusokat • Minden objektum a probléma egy részét írja le és magában foglalja a részfeladat megoldásához tartozó algoritmikus elemeket

– A fıprogram jelentısége igen csekély • Gyakorlatilag csak indítási pontként szolgál, lényegi funkciót általában nem lát el V1.1

2006. október 10.


9

9

Objektumorientált program Tipikus felépítés Obj Obj

Obj

Obj

Obj

Obj Obj Obj

Obj

Obj

V1.1

2006. október 10.

Obj

Obj

Obj

Obj


10

10

Az OO paradigma alapelvei 1. alapelv: Absztrakció • Meghatározzuk a szoftverrendszer absztrakt elemeit • Meghatározzuk az elemek állapotterét – Adatelemek

• Meghatározzuk az elemek viselkedésmódját – Funkciók végrehajtása – Állapotváltoztatások

• Meghatározzuk az elemek közötti kapcsolattartás felületeit és protokollját – Üzenetváltások típusa – Pontosan definiált, megbízható kapcsolódási felületek

...mindezt a megvalósítás konkrét részleteinek ismerete nélkül. V1.1

2006. október 10.


11

11

Az OO paradigma alapelvei 2. alapelv: Egységbezárás • Az objektumok adatait és a rajtuk végezhetı mőveleteket szoros egységbe zárjuk – Az adatok csak a definiált mőveletek segítségével érhetık el – Más mőveletek nem végezhetık az objektumokon

• Az egységbezárás védi az adatokat a téves módosításoktól

V1.1

2006. október 10.


12

12

Az OO paradigma alapelvei 3. alapelv: Adatrejtés • Az absztrakciók megvalósításának részleteit elrejtjük a „külvilág” elıl • Az objektumokon belül elkülönítjük a belsı (privát) és a külsı (nyilvános) adatokat és mőveleteket – A privát adatok és mőveletek a konkrét megvalósításhoz szükségesek – A nyilvános adatok és mőveletek a szoftverrendszer többi objektuma számára (is) elérhetık • Tájékozódás az objektum állapotáról • Az objektum állapotának módosítása • Üzenetváltás

V1.1

2006. október 10.


13

13

Az OO paradigma alapelvei 4. alapelv: Öröklés • A már meglévı objektumtípusok alapján készíthetünk új típusokat, melyek rendelkeznek az „ıstípus” tulajdonságaival – Ez egy specializációs mővelet („származtatás”) • A „leszármazottak” „öröklik” az ıstípus tulajdonságait

– A leszármazottak bıvíthetik, esetenként akár szőkíthetik az ıstípus állapotterét, illetve mőveleteit – Teljes leszármazási hierarchiákat is létrehozhatunk – Kiváló lehetıség a közös tulajdonságok, mőveletek összevonására és újrahasznosítására

• Az alapelv következetes alkalmazásával elérhetı, hogy a már megvalósított funkcionalitás késıbb a megvalósítás részleteinek ismerete nélkül is felhasználható legyen – Jól átgondolt elızetes tervezést igényel V1.1

2006. október 10.


14

14

Az OO paradigma alapelvei 5. alapelv: Többalakúság • A különbözı, egymásból származó objektumtípusok hasonló mőveletei a konkrét objektumtól függıen más-más konkrét megvalósítással rendelkezhetnek – Ugyanaz a mővelet némileg eltérı lehet az ıstípus és a leszármazott típus esetében – Az alapelv lehetıséget teremt rá, hogy azonos névvel hivatkozzunk az azonos célú, de a leszármazási hierarchia különbözı szintjein más-más megvalósítást kívánó mőveletekre

• Az egyes ıstípusok leszármazottai mindenre alkalmasak, amire az adott ıstípus alkalmas volt – Minden olyan helyzetben és funkcióban, ahol az ıstípus szerepelhet, annak bármely leszármazottja is szerepelhet

V1.1

2006. október 10.


15

15

Az OO paradigma alapelvei 6. alapelv: Kódújrafelhasználás • A már megvalósított objektumtípusokat kész (bináris) formában más programokban is felhasználhatjuk – Jó tervezés és dokumentálás esetén az objektumok nyilvános adatai és mőveletei elegendıek a késıbbi felhasználáshoz • Szintaktikai bıvítésekkel (pl. „tulajdonságok”, „események”) kényelmesebbé tehetı a külsı felhasználás

– Az egyes objektumtípusokat egymásba ágyazva összetettebb típusokat hozhatunk létre – A kész, újrafelhasználható objektumtípusokat csoportokba fogva akár nagyobb „szoftver-építıelemeket” (komponenseket és komponensgyőjteményeket) is létrehozhatunk

• A korábban említett alapelvekre építve a kódújrafelhasználás lehetısége jelenti az igazi áttörést a szoftvertechnológiában V1.1

2006. október 10.


16

16

Adatstruktúrák, algoritmusok, objektumok

Recommend Documents