Adatstruktúrák, algoritmusok, objektumok 2. Az objektumorientált programozási paradigma 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 Kötegelt rendszerek Egyedi szoftver Nincs terjesztés Többfelhasználós rendszerek Valós idejő megoldások Adatbáziskezelés Szoftvertermékek Elosztott rendszerek Beágyazott rendszerek Olcsóbb hardver Hagyományos terjesztés 1950 1960 1970 1980 1990 2000 2006. október 10. 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 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 szoftver nem fizikai (anyagi) jellegő A szoftver elıállítása alapvetıen nem jár közvetlen fizikai nyersanyagigénnyel A szoftver, mint erıforrás mennyisége nem korlátos (végtelenül többszörözhetı) A 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ó 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...) 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 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 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 2006. október 10. 8 8
ektumorientá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 2006. október 10. 9 9
ektumorientált program Tipikus felépítés 2006. október 10. 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. 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 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 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 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 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 2006. október 10. 16 16