1 Objektum orientált programozás Az objektumok és az osztályok – bevezetés Nagy Szilvia.

Az előadások a következő témára: "1 Objektum orientált programozás Az objektumok és az osztályok – bevezetés Nagy Szilvia."— Előadás másolata:

1 1 Objektum orientált programozás Az objektumok és az osztályok – bevezetés Nagy Szilvia

2 2 A modellezés folyamata A szoftver előállítás mikéntje többféle szemszögből is érdekes: programozási technikák módszertanok technológiák Technológia : a társadalom által felvetett gyakorlati problémák megoldására szolgáló dolgok gazdaságos, a tudomány eredményeit felhasználó előállításának mikéntje (a módszerek, eszközök, technikák együttese.

3 3 A modellezés folyamata A szoftverfejlesztés lépései: problématérimplementációs tér fogalmi modell implementációs modell a követelmények- nek megfelelő rendszerek a felhasználható eszközökből építhető rendszerek megvalósított rendszer a fogalmi modellnek megfelelő implementációs modellek tervezés modellezés modellezés imple- mentá- ció

4 4 A modellezés folyamata A szoftverfejlesztés lépései: modellezés A modell a valóságról bennünk kialakult kép; nem tükröz minden részletet, azokra a tulajdonságokra koncentrál, amelyek a feladat megoldása szempontjából fontosak. Egy modell több dolgot leírhat, és egy dolog modellezésére több korrekt modell is létezhet tervezés implementáció

5 5 A modellezés folyamata A szoftverfejlesztés lépései: modellezés tervezés Több jó fogalmi modell is van, s egy fogalmi modellnek több implementációs modell is megfeleltethető, ezek közül a lehető legjobb kiválasztása a tervezés – mind a fogalmi, mind pedig az implementációs térben optimumra törekedünk. implementáció

6 6 A modellezés folyamata A szoftverfejlesztés lépései: modellezés tervezés implementáció Az optimalizált rendszerterv átültetése a valóságba.

7 7 A modellezés folyamata Absztrakció : olyan gondolkodási művelet, amely segítségével a dolgok számunkra fontos tulajdonságait elválasztjuk a nem fontosaktól – az általános tulajdonságokat elkülönítjük az egyediektől. Különböző absztrakciós szintek a dolgok különböző pontosságú modelljeihez vezetnek. Finomítás: az absztrakciós szint csökkentése

8 8 A modellezés folyamata Dekompozíció : egy rendszer egyszerűbb, működő részrendszerekre való bontása úgy, hogy a részrendszerek együttesen a teljes eredeti rendszer működését és tulajdonságait bírják. A részrendszerek egymástól függetlenül írhatók le, modellezhetők, kezelhetők, azonban együttműködésük módját is le kell írni.

9 9 A modellezés folyamata A modell egy-egy finomítás a után szükséges lehet a kapott részleteknek megfelelő dekompozíció. Az absztrakció s szint növelésekor viszont bizonyos dekompozíciók fölöslegessé válhatnak. A modellezés során különböző absztrakciós, illetve dekompozíciós szintű modelleket használhatunk. Akkor jól használható és karbantartható a szoftverünk, ha minden absztrakciós szinten egymásnak megfelelő a fogalmi és az implementációs modellünk.

10 10 A modellezés folyamata Dokumentáció ahhoz, hogy a tervezés során kapott modellt fel tudjuk idézni, illetve másokkal megtudjuk osztani, dokumentációt kell róla készíteni. Egy leírás akkor formális, ha csak pontosan definiált fogalmakat, szerkezeteket és modelleket használ, és a definíciók formáját is rögzíti. Célszerű a dokumentációt – legalább valamilyen szinten – formálisan elkészíteni.

11 11 A modellezés folyamata problématérimplementációs tér lehetséges rendszerek megvalósított rendszer leképezés modellezés implementáció fogalmi modell implemen- tációs modell absztrakciós szint analízistervezés

12 12 A modellezés folyamata problématérimplementációs tér leképezés absztrakciós szint 13 2 Top-down haladás lépésenkénti finomítás: minden lépésben egy domináns fogalom ( struktúrálandó objektum ) egyszerűbb fogalmakból való felépítéséről hozunk döntést.

13 13 A modellezés folyamata problématérimplementációs tér leképezés absztrakciós szint 13 2 Bottom-up haladás szintézis, majd absztrakció úgy, hogy a fogalmi és az implementációs modell struktúrája hasonló legyen

14 14 A modellezés folyamata problématérimplementációs tér leképezés absztrakciós szint Az objektumorientált szoftverfejlesztés ezt az utat követi

15 15 A modellezés folyamata formalizáltság absztrakciós szint Specifikáció : formalizálás növelése Tervezés : az absztrakciós szintet csökkentve egy magasabb absztrakciós szintű elemnek alacsonyabb absztrakciós szintűekből való előállítása

16 16 Életciklus A szoftverek életciklusában rendkívül fontos a fejlesztés analízis architekturális tervezés részletes tervezés kódolás integrálás tesztelés

17 17 Objektum-orientáltság fogalma A tervezés során sorozatos döntésekkel konkretizáljuk a tervezendő programot. Egy- egy döntést egy strukturálandó objektumról avagy domináns fogalomról (annak továbbontásáról) hozunk. Ez a domináns fogalom vált idővel az objektum- orientáltság alapjává. Kezdetben strukturálatlan adatmanipulációk sorozata volt egy-egy program, s a saját készítőjükön kívül kevés ember tudott rajta eligazodni.

18 18 Objektum-orientáltság fogalma Strukturált programozás (E.W. Dijkstra): a program legyen egy absztrakt gép („oldd meg a feladatot” utasítással) ha nincs ilyen gép, készítsük el annak egy egyszerűbb absztrakt gépet, melynek programja az előző absztrakt gépet szimulálja egészen addig egyszerűsítjük az absztrakt gépeket, amíg e kapunk olyant, amely utasításkészletét egy valóságos gépen is végre tudjuk hajtani.

19 19 Objektum-orientáltság fogalma Strukturált programozás (E.W. Dijkstra): Szintenként lehet elemezni a programot továbbra is nehezen áttekinthető programokat kaptak

20 20 Objektum-orientáltság fogalma Szükséges volt olyan szerkezetek kidolgozása, amelyek példányosíthatók, mint a változók, ugyanakkor a rajtuk értelmezett műveletek is példányosodnak. Az objektum-orientáltság célja az volt, hogy a programban az egy-egy objektumra vonatkozó összes adat/információ egyetlen helyen jelenjen meg, s ez az információ a program más részein (vagy más programokban) újra felhasználható legyen.

21 21 Objektum-orientáltság fogalma Az objektum-orientáltság egy szemléletmód (paradigma), amely a modellezéstől kezdve az implementáción keresztül a karbantartásig a teljes programfejlesztést átfogja. Az objektum-orientált módszertan alkalmazásával kifejlesztett rendszert együttműködő objektumok ként modellezték, s az implementáció során is az objektumokat szimuláló absztrakt gépeket programrészeket hoztak létre. köznapi gondolkodás, gyűjtőnevek.

22 22 Az objektumok tulajdonságai Az objektum egy valós absztrakt, azonosítható, egyedi dolog, a vizsgált környezet jól definiálható szereplője hatását gyakorol más objektumokra, és a más objektumok is gyakorolnak hatást rá jellemezhető a rajta elvégezhető műveletekkel és a műveletek hatására létrejött állapotaival bármi lehet, aminek pontos határai megállapíthatók

23 23 Az objektum fogalma Az objektum egy rendszer egyedileg azonosítható szereplője, amelyet a külvilág felé mutatott viselkedésével, belső struktúrájával és állapotával lehet jellemezni. Az objektumok belső struktúráját a külső szemlélő és a többi szereplő nem látja: az objektumok elrejtik az általuk hordozott információ egy részét. Ez az egységbe zárás (encapsulation): a „objektum” egységbe zárja a programozója a tulajdonságokat, az állapotokat és a végrehajtható műveleteket, az objektum viselkedését.

24 24 Az objektum felelőssége Az objektum maradéktalanul eljátssza a rá kiszabott szerepeket, így rendelkezik minden olyan képességgel és ismerettel ami a feladatok végrehajtásához szükséges. Minden objektumnak van egy felelősség i köre, melybe tartozó feladatokat végre kell hajtania. Minden objektum felelős önmagáért: lokális felelősség elve.

25 25 Az objektum tulajdonságai Az objektum viselkedése : a viselkedés az objektum által végrehajtott tevékenységsorozat. Egy objektum lehet aktív vagy passzív: aktív, ha a környezet ráhatása nélkül is folyamatosan működik, más objektumokat bír működésre… passzív, ha csak valamiféle üzenet hatására lép működésbe.

26 26 Az objektum tulajdonságai Az objektumok hatásukat egymásnak küldött üzenet ekkel (message) fejtik ki. Az üzenetek az objektumok az objektumok közötti adatcsere és a működésüket szabályozó eszköz. Az üzenetnek van neve és paraméterei. A név statikus (nem változik), az azonosítja az üzenetet az objektum számára. Az üzenet neve vezérlő jellegű: a név által hordozott információ határozza meg, miként viselkedik az objektum

27 27 Az objektum tulajdonságai Az objektumok hatásukat egymásnak küldött üzenet ekkel (message) fejtik ki. Az üzenetek az objektumok az objektumok közötti adatcsere és a működésüket szabályozó eszköz. Az üzenetnek van neve és paraméterei. A paraméterek változhatnak, ugyanaz az üzenet különböző paraméterekkel másféle lefutást eredményezhet. A paraméter tetszőleges változó (akár objektum is) lehet.

28 28 Az objektum tulajdonságai Egy objektum többféle nevű üzenetet fogadhat és egy üzenetet több objektum is képes lehet értelmezni. Előfordulhat olyan modellezés, hogy az objektum azonosítani tudja az üzenet küldőjét és szelektálni tud, hogy melyik küldőnek engedelmeskedjen.

29 29 Az objektum tulajdonságai Ha több aktív objektum engedélyezett – azaz van konkurencia – tisztázni kell a modellezéskor, hogy induláskor lehet-e több aktív objektum a rendszerben lehet-e aszinkron üzenetküldés, azaz nem kell-e az újabb üzenet küldésével megvárni az előbbi válaszreakcióját lehet-e objektumon belüli konkurencia, azaz egy objektum elfogadhat-e új üzenetet, amíg egy előzőre adott válaszreakció közben van

30 30 Az objektum tulajdonságai Esemény (event): azonosítható, pillanatszerű történés (a történés folyamata érdektelen a modellezés szempontjából) Az eseménynek is van neve (statikus jellemző) és lehetnek paraméterei (dinamikus jellemzők) Az eseményeket objektumok hozzák létre, és az események bekövetkezéséről értesülnek az érintett objektumok. Egy alternatív megfogalmazás az üzenetek helyett.

31 31 Az objektum tulajdonságai Tisztázni kell, hogy lehet-e címzettje egy eseménynek, azaz a kiváltó objektum irányíthatja-e hogy melyik objektum reagáljon eldöntheti-e az objektum, hogy melyik eseményekre reagáljon, s ha igen, hogyan egy eseményre csak egy objektum reagálhat-e vagy több is

32 32 Az objektum tulajdonságai Ha az objektum képes egy eseményt fogadni, akkor annak megkapására egy az üzenet neve által meghatározott metódus (method) végrehajtásával reagál. A kiváltott viselkedés pontos leírása (implementációja) a metódus kódjában található. Üzenet: azt mondja meg, mit kell csinálni. Metódus: azt mondja meg hogyan kell azt tenni.

33 33 Az objektum tulajdonságai Attól függően, hogy korábban milyen hatások érték az objektumot, másképpen reagálhat ugyanarra az üzenetre: a korábbi üzenetek hatására az objektum különböző állapot okba kerülhet. Az objektum állapota valahol az objektum egységébe zárva (encapsulated) megjelenik. Az objektum nem csak metódusokat, hanem állapotokat is tartalmazhat, egy-egy metódus megváltoztathatja a belső állapotot.

34 34 Az objektum tulajdonságai Az objektum állapotát az attribútum ai tárolják. Az attribútumok értékei a futás során változnak, ezért az attribútumokat változókkal reprezentáljuk.

35 35 Polimorfizmus Különböző objektumok megkaphatják ugyanazt az üzenetet, azonban előfordulhat, hogy máshogy reagálnak. Ha egy objektum úgy küldhet üzenetet egy másiknak, hogy nem kell arra figyelemmel lennie, hogy ki kapja az üzenetet, akkor polimorfizmusról (többalakúság) beszélünk.

36 36 Objektum összefoglalása Az objektum olyan modellje egy dolognak, amely a számára kívülről érkező üzenetekre reagálva valamiképpen viselkedik, van egy kívülről nem látható statikus struktúrája, amely magában foglalja az attribútumokat, melyek az objektum állapotát hivatottak leírni. Egy objektum állapota a struktúrát adott pillanatban kitöltő értékek halmaza. (behavior, structure, state)