A következő diagram az osztálydiagram, amelyet a fenti ábrán láthatunk. Több dolgot is meg kell említenünk ezzel kapcsolatban. Az adatbázis tantárgynál láttuk, hogy volt nekünk egy olyan, hogy tábla-struktúra s voltak attribútumaink. Az objektumorientált paradigma esetén van osztály, attribútumok és felelősségek. Ezt az alábbi táblázat foglalja össze: Relációs adatbázisok Tábla Attribútum
Lekérdezések eredményei Táblasorok
Objektumorientált paradigma Osztály Attribútum
Felelősség Felelősség Objektumok
Különbség Relációsban atomi, Objektumorientáltban bármennyire komplex lehet Kommunikációs Megvalósítási
Azért jobb az objektumorientált paradigma, mert egységbe zárja az adatstruktúrát és az objektum viselkedését. Pédául, a leves osztály tartalmazhat egy olyan attribútumot, hogy recept, amelyik egy tábla lehetne a következő struktúrával és tartalommal: Név Mennyiség Mértékegység Csirkehús 20 dkg Só 2 kanál Bors 1 csipetnyi Osztályhierarchia: Léteznek általános és specifikus osztályok. Példánkban az általános leves osztály a szülője a húsleves osztálynak. Az üresfejű nyíl az általános fele mutat. A specifikust ebben az esetben például úgy definiáljuk, hogy: a húsleves egy olyan leves, amely receptje húst is tartalmaz. A származtatott (specifikus) osztály mindig valamivel több, vagy másabb, mint az általános. Általában a specifikus osztály örökli az általános osztály minden attribútumát és felelősségét, viszont vagy valamelyiket átfogalmazza, vagy pedig valami új lesz benne, vagy atribútum vagy felelősség szintjén. Kommunikációs felelősségek: Az osztályok megvalósításai (az objektumok) egymással információkat közölnek. Hogy ez rendben megtörténjen az osztályokban meg kell adni a kommunikációs felelősségeket. Ezt olyan formán fogalmazhatjuk meg, hogy az osztályoknak FÜLE kell legyen, vagyis, aki kapja az üzenetet, abban az osztályban kell létezzen egy metódus (operáció). Amint ezt látjuk az osztálydiagram megvalósításából, az apánál van megvalósítva a fozzel(egyleves:husleves):void metódus. Ezt a nagyi komunikálja az apa felé. Valamennyire általános, mert a metódus neve a főzzél, s paraméterként adja át azt az információt, hogy az legyen egy leves, ami húsleves tipusú legyen. Visszatérő értéke nincs (void), ami azt jelenti, hogy a nagyi semmiféle választ nem vár ebben a kommunikációs pontban. Visszajelzésre csak a végén van szüksége, amikor elkészült már a leves. Apa, mivel főzni nem tud, de nagyinak szót kell fogadnia, a felelősséget továbbhárítja a lányok vagy az anya felé. Ez a továbbadás pontosan ugyanúgy történik, az információ se szűrve se feldolgozva nem volt. A fül paradigma miatt az anyánál és a lányoknál is meg kell legyen valósítva ugyanaz a függvény: fozzel(egyleves:husleves):void. A másik kommunikáció az apa és a lányok közötti: vaneKedv():boolean. Amint látjuk, ez egy olyan metódus, amelyiknek logikai viszatérő értéke van. Ez azt jelenti, hogy az apa válaszban vissza kell kapja azt az információt, hogy igen vagy nem, azért, hogy tudja, mit tegyen a következőben. Ha az első lánynál a válasz igen volt, az apának az elkövetkezendőkben csak várnia kell arra a kommunikációra, hogy kész a leves. A kommunikációs felelősségnél mostmár
csak ez maradt. Apánál és nagyinál is megvalósítjuk az etelKesz():void metódust, mert nekik kell fülük legyen hozzá. Paramétert is tehetünk a módszerhez, amelyik megadja, hogy egy húsleves készült el, de ebben az alkalmazásban, amely csak erről szól, ez nem szükséges, viszont általánosabb, ha megadjuk a paramétert. Visszatérve a vaneKedv():boolean felelősségre, ez az attribútum értékét olvassa ki. Általában ezek megvalósításaiban: getKedv():boolean és setKedv(egyKedv:boolean):void formában jelennek meg, amely felelősségek (operációk) kiolvassák és átírják az attribútumok értékét. Az attribútumok értékei, mint látható ebben az esetben konkrétan is az objektum állapotát határozzák meg. Megvalósítási felelősségek: A megvalósítási Osztálydiagram, összekapcsolások: Az osztálydiagramban leírtuk az összes szereplőt, aki részt vesz az alkalmazásban. Felrajzoltuk, milyen kapcsolatok vannak az alkalmazás szempontjából. Nekünk a háttérben nem kell tudnunk azt, hogy ez egy család. Nagyi és apa 1:1 kapcsolatban vannak, vagyis van egy nagyi és egy apa kapcsolatban az alkalmazás folyamán. Mivel nagyi is kommunikál apával, amikor kiadja a parancsot a főzésre (tud róla) és apa is kommunikál nagyival, értesíti, hogy kész van az étel (tud róla), ezért az összekötő nyíl helyett összekötő vonalat rajzoltunk a 2 osztály között. Apa kommunikál (hat) mindkét lányyal és az anyával is. Apa és a lányok közötti kapcsolat kardinalitása 1:2, apa és anya között 1:1. Mint láthatjuk az alkalmazás folyamatában nagyi nincs kapcsoaltban sem anyával sem a lányokkal, s az anya sincs kapcsolatban a lányokkal. Amiatt, amiért az apa kiadhatja a parancsot a lányoknak és az anyának, valamint visszafelé a lányok vagy az anya üzenhet apának, hogy kész a leves, itt is összekötő vaonalat használunk nyíl helyett, mert oda-vissza zajlik a kommunikáció. Láthatósági feltételek: + publikus # védett ~ csomagszintű - privát Az attribútumok alapértelmezésben privát tipúsuak. Ez azt jelenti, hogy sem a főprogram, sem más objektum nem fér hozzá közvetlenül az értékéhez, nem tudja módosítani, sem kiolvasni. A módosításhoz és a kiolvasáshoz általábat a setAttribute és getAttribute módszerek segítenek. Az olyan metódusokat is eldugjuk a private deklarációkkal, amelyek az objektum belső felelősségét valósítják meg.
Folytatjuk a húsleves elkészítésének megvalósítását
A fentebb levő ábán egy hierarchia tipusú osztálydiagramot láthatunk, amit másképpen öröklődési diagramnak is nevezünk. Ebben az esetben nem emberi rokonsági kapcsolatokat vizsgálunk, hanem az osztályok közötti hasonlóság mentén alakítjuk ki az osztályhierarchiát. Az alkalmazás adja meg ennek a struktúrának az értelmét. Amint látjuk, vettünk egy általános ember nevű osztályt. Ennek adhattunk volna egy attribútumot, amelyik lett volna a név:String. A nagyi és az apa abban hasonlítanak, hogy mindkettő kell fogadja azt az információt, hogy levesKesz, vagy etelKesz(egyleves:husleves). Azt mondhatjuk, hogy a nagyi osztály ugyanúgy viselkedik, mint az ember osztály, de pluszban van egy kommunikációs felelőssége, hogy meghallja azt az információt, hogy kész a leves. Továbbá azt mondhatjuk, hogy az apa osztály ugyanúgy viselkedik, mint a nagyi osztály, de van pluszban egy kommunikációs felelőssége, hogy
meghallja
azt
az
információt
a
nagyitól,
hogy
főzzön
levest:
fozzelLevest(egyleves:husleves). Amúgy ez a kommunikációs feladata megvan a másik ágon meghatározott anya és leány osztályoknak is, viszont olyan sokban különböznek a nagyitól és az apától, hogy teljesen más ágon ábrázoltuk őket. Azt mondhatjuk, hogy az anya is egy ember,
viszont van még az előbb megemlített kommunikációs felelősségen kívül még három más, belső felelőssége, hogy: főz, bevásárol, mosogat, amelyet a metódusoknál a következő operációkkal valósítjuk meg: foz(), vasarol(), mosogat(). Ezek a felelősségek, habár belső felelősségek nem lehetnek privát láthatóságúak, mert mint látjuk, a hierarchikus fában ezeket örökölni fogja a leány osztály. Hogy egy attribútumot vagy egy belső felelősséget örökölni lehessen a hierarchikus fában, a láthatóságuk védett (protected). Ezért ez a három felelősségnek a láthatósága protected lesz. Azt mondjuk továbbá, hogy a leány osztály hasonlóan viselkedik, mint az anya osztály, viszont van egy plusz attribútuma, a kedv nevű, meg egy plusz felelőssége, ami ennek az attribútumnak az értékét olvassa ki az osztályból, a vaneKedv():boolean felelősség.
Megvizsgáljuk a pont és a szakasz viszonyát. Az elején definiáljuk az attribútumokat és a felelősségeket.
Síkbeli pontról van szó az Euklideszi térben. Egy pontot két koordináta jellemez, az X és az Y koordináta Ezen koordináták lebegőpontos értéket vehetnek fel jelen esetben, amelyek a valós számokhoz kötődnek. A felelősségeket több féle képpen határozhatjuk meg, esetünkben van konstruktőr, beállító és lekérdező operátor és vannak más operátorok, amelyek az osztály létével kapcsolatosak. Az előbbiekben, a húsleves alkalmazásnál volt kommunikációs felelősség is. Egy konstruktőr egy olyan operátor, amelyik az osztály “sablon” használatával keletkező objektum keletkezési feltételeit adja meg. A konstruktőr neve ugyanaz, mint az osztály neve. Létezik üres konstruktőr, ez csak egy memória helyet foglal le. A pont osztálynál láthatunk ilyen üres konstruktőrt: pont(). Definiáltunk egy másik konstruktőrt is: pont(egyX:float, egyY:float). Ennek a konstruktőrnek a használata azt eredményezi, hogy a memóriában keletkező új pont már meghatározott koordinátákkal rendelkezik, vagyis az Euklideszi térben létezik. Amint látjuk, az attribútumok láthatósága privát. Az objektumorientált elv szerint az attribútumokat direkt módon nem lehet se beállítani, se kiolvasni, hanem az osztály kell biztosítson beállító és kiolvasó függvényeket. Ezek a set és a get operátorok. A beállító operátor az X koordinátára a következő nevet és alakot veszi fel: setXKoord(egyX:float):void. Láthatjuk, hogy ugyanaz a neve, mint az attribútumnak, csak egy set szócska van eléje téve. Se a főprogram, se senki nem várja, hogy a beállító függvény visszatéritsen valamilyen értéket, ezért látjuk a void szót a visszatárítési értéknél. Az értéket, amire be szeretnénk állítani az X koordinátát át kell adnunk paraméterként az objektumnak. Ez az egyX érték, amelyik float (lebegőpontos érték), ugyanúgy, mint az osztályban megadott X érték tipúsa. A végrehajtott művelet ennél a beállításnál: Xkoord=egyX lesz. Ha egyX=4.23, akkor Xkoord=4.23 értékre állítja ez a művelet. A kiolvasás (lekérdezés) a get szócska használatával történi: getXKoord():float. Ez a művelet egy lebegőpontos értéket ad vissza, például a főprogramnak. Hasonlóan képezzük azokat az operátorokat, amelyek az Y koordinátára vonatkoznak. A pont eléggé egyszerű objektum, ezért semmilyen más operátort nem definiálunk vele kapcsolatban. A szakasz nevű osztályt, a 2 végpontjával (VP1 és VP2) határozunk meg. Ezek, mint látjuk pont tipúsuak. Nem definiáltunk hozzá üres konstruktőrt. A fő konstruktőr: szakasz(egyPont:pont, masPont:pont), amelyik létező végpontokat kell átadjon az objektum keletkezésekor. Még
definiáltunk egy másik konstruktőrt is, amelyik a végpontok koordinátáit adja át, ezért a szakasz objektum keletkezése előtt keletkeznie kell az egyik és a másik végpontnak. A beállító, kiolvasó függvények hasonlítanak azokhoz, amelyeket a pont osztálynál definiáltunk, persze a lebegőpontos érték helyett a pont objektumot használjuk, mint tipust. Látjuk, hogy itt van nekünk egy tangens():float és egy hossz():float operandusunk, amelyek megadják a szakasz irányát a térben, na meg a szakasz hosszát. Ezek, végülis kiszámítható értékek a meglévő információk alapján.
y y2
VP2
y1
α VP1 x
O
x1
x2
Az ábra alapján kiszámítható a tg(α) és a szakasz hossza a következő képpen: tg (α ) =
y 2 − y1 x2 − x2
h = ( x 2 − x1) 2 + ( y 2 − y1) 2
Ahhoz,.hogy az x1,x2, y1,y2 információkat kiolvassuk a következő képen kell eljárnunk: Ha van egy szakasz objektumunk, amelyiknek a neve egySzakasz, akkor így kapjuk meg az értékeket: x1=egySzakasz.getVP1().getXKoord() x2=egySzakasz.getVP2().getXKoord() y1=egySzakasz.getVP1().getYKoord() y2=egySzakasz.getVP2().getYKoord() Az egySzakasz.getVP1() kiolvassa az első végpontot az egySzakasz nevű szakaszból. A getXKoord() kiolvassa a már kiolvasott pont X koordinátáját, amely egy lebegőpontos érték.
Az előző diagramot csomagdiagramnak nevezzük. Ez a csomagdiagram a könyvtári alkalmazás csomagdiagramját hivatott jelképezni. Az emberek csomagban a könyvári alkalmazásban résztvevő személyek adatainak modellezését szolgálja. A könyvtári alkalmazáshoz kell olyan modell, amelyik a használt (kölcsönzött, olvasott) objektumokat, és a köztük levő kapcsolatokat modellezze. A működés akkor történik meg, amikor egy könyvtári (pl. kölcsönzési) objektum kapcsolatba kerül egy kölcsönző személlyel. A kölcsönzés, visszahozás folyamán pl. a hallgató kapcsolatba kerül egy könyvvel. Ezt kölcsönzési tranzakciónak is nevezhetjük.
A modellezést a könyvadat, példányadat, tárgyszó és cutter osztályokkal kezdjük. A könyvadat olyan információkat kell modellezzen, amelyek pl. 10 egyforma könyvet jellemez. Ezek közül megjelenítettük a cím, szerző, kiadó, kiadási év és ISBN attribútumokat. Persze, ennyire nem egyszerűsíthető le az adatstruktúra, de az általunk elképzelt alkalmazásnak megfelel. A példány az, ami minden egyes könyvet jellemez. Ilyen a leltárszám, a könyv kölcsönözhetősége, az ára és az, hogy aktuálisan kölcsön van-e adva, vagy elérhető. Az ár azért tartozik ehhez az osztályhoz, mert több forrásból vehetünk könyvet, ami különböző árat is jelenthet.
xxx. ábra. Öröklődés a könyvtári alkalmazás emberek csomgajában Az öröklődés és az osztályhierarchia hasonló kifejezések ugyanannak a dolognak a megvalósítására. Esetünkben van egy főosztály, amely a felhasználó osztály. Azért, hogy ebből az osztályból örökölhetők legyenek az attribútumok, ezért minden attribútum láthatósága protected tipusú kell legyen. Mondhatjuk, hogy a hallgató is egy felhasználó, amelyik abban különbözik egy általános felhasználótól, hogy nem kölcsönözhet egyszerre, csak 5 könyvet, s a könyvek kölcsönzési határideje maximum 7 nap lehet. Az első szinten vannak a hallgató, oktató,
a főkönyvelő és egy általános könyvtáros. A könyvtárosok mindenike el kell tudjon végezni egy kölcsönzést, de amúgy különböző felelősségeik vannak a könyvtáron belül. A leíró könyvtáros a könyvek alapadataival foglalkozik, beviszi azokat az adatbázisba. Azonkívül még azzal is foglalkozik, hogy a könyvek keresési feltételeit megvalósítsa. Ezeket a tárgyszavakon keresztül történnek. A tárgyszavak, mint például: adatbázis, SQL, UML, informatika, programozási nyelvek stb. segítik a keresését azon könyveknek, amelyeknek a címük nem tartalmaz olyan utalást, ami bizonyos keresett fogalmakra vonatkozna.
xxx.ábra. A kölcsönzési tranzakció A könyvtári alkalmazás működése a fenti osztálydiagramhoz kötődik. A könyvtár legfontosabb szolgáltatása a kölcsönzés. A kölcsönzést egy asszociációs osztállyal valósítjuk meg. Mikor két osztály objektumai egymással kölcsönhatásba lépnek, s ennek eredménye egy másik osztály objektuma, akkor asszociációs osztályról beszélünk, vagy asszociációs objektumról. Ennek ábrázolása egy asszociációs összekötés a két osztály között, majd az összekötő vonalhoz, szagatott vonallal kapcsolt osztály. Esetünkben azt mondjuk, hogy egy hallgató objektum, ha kölcsönhatásba kerül egy könyvpéldánnyal, akkor keletkezhet egy kölcsönzési tranzakció. A kölcsönzési tranzakció jellemzői a dátum, amikor a könyvet kikölcsönözték, a határidő, amire a könyvet vissza kell vinni a könyvtárba, a visszahoz, amely dátum azt a dátumot jelenti,
amelyiken effektív visszahozták a könyvet. Szükséges, hogy a tranzakcióban megjelenjen a hallgató, a könyvpéldány és a kölcsönző könyvtáros. Ezek a futtatás során egy mutatót jelentenek, amely mutató arra a bizonyos hallgatóra, könyvpéldányra vagy könyvtárosra mutatnak, akik részt vettek a kölcsönzésben. A könyvtárosra azért van szükség, hogy ha a kikölcsönzött könyvvel valami probléma van, lehessen visszapörgetni az eseményeket, hátha kiderül, hogyan csúszhatott be egy esetleges hiba a rendszerbe. A működési hibalehetőségek megtalálása is érdekes minőségbiztosítási feladat lehet. Ahhoz, hogy az osztály azon felelőssége, hogy visszaadja nekünk a büntetés értékét, ami ehhez a tranzakcióhoz kapcsolódik két féle képpen járhatunk el. Első az, ahogy aktuálisan modellezve van, hogy a tranzakció tartalmazza az egy napi büntetés értékét. Ezt, ha megszorozzuk a (visszahoz-datum) által megadott napok számával, ki tudjuk számítani a büntetést. Ez feltételezi, hogy minden objektumban is benne kell legyen ez az érték, ami a memória-használat szempontjából nem jó. Másik megoldás az, hogy a buntetés felelősségnek paraméterként adjuk át a napi büntetés értékét, s akkor így fog kinézni a büntetés: buntetes(egynapiBunti:int). Ezt az értéket majd a főprogram fogja átadni, valószínűleg egy beállítási állományból, amely az alkalmazás beállításait tartalmazza.
xxxx. ábra. Asszociációs osztály. A szerződés Az asszociációs osztály legmarkánsabb példája a szerződés, azt is mondhatjuk, hogy az asszociációs osztály az szerződés tipusú oszstály. Egy szerződés létrejöhet például egy cég és egy természetes személy között. Ilyen a garanciális szerződés, banki hitelszerződés stb. Ezeknek több attribútumai vannak, mint, amit modelleztünk. Itt és most arra fekettünk hangsúlyt, hogy
milyen is az asszociációs osztály. Láthatjuk, hogy se a cég se a természetes személy nem tartalmaz attribútumot. Sok esetben, mikor valamire koncentrálunk, a dolgok másik részét hanyagoljuk. Itt a szerződésnek tartalmaznia kell egy számot, egy dátumot, hogy mikortól érvényes a szerződés, hogy kik között történt a szerződés megkötése, meg egy csomó más dolgot is, például azt, hogy mi a célja, meddig tart stb. Ezeket nem tettük be a modellbe, mert különböző üzleti modellek különböző szerződéseket igényelnek.
xxx. ábra.Cégek közötti szerződések Amint az előző ábrán láthatjuk, lehet olyan asszociációs osztályunk, amelyik ugyanazon osztály objektumai között valósul meg. Ilyen az a szerződés osztály, amelyik két cég közötti szerződést modellezi. Amikor az egyik cég kapcsolatba kerül egy másik céggel, az sok esetben szerződéskötésen keresztül valósul meg. Itt nem azt mondjuk, hogy a cég osztály önmagával van asszociációs kapcsolatban, hanem azt, amit az előbb fogalmaztunk metg, hogy a cég osztály egyik objektuma kapcsolatba kerül a cég osztály másik objektumával.
xxx. ábra. A tárgyszó struktúrája A könyvtári alkalmazásnál a tárgyszó egy fastruktúrában is benne lehet, amelyik a következő képpen nézhet ki:
Ha megnézzük a fentebbi ábrát láthatjuk, hogy magát a fastruktúrát is egy osztálydiagram segítségével készítettük el, egy osztályhierarchia-diagrammal. Kivettük az attribútumok és a felelősségek láthatóságát, hogy ne zavarja az összképet. Láthatjuk, hogy egy szülőnek több gyereke is lehet, míg egy gyerek csak egy szülőhöz tartozhat.
xxx. ábra. A bináris fák megvalósításának csomagdiagramja
xxx. ábra. Bináris fa ábrázolása A bináris fának a strukturális információja három pointert használ. Az egyik a szülőre mutat, a másik a bal gyerekre, a harmadik a jobb gyerekre. Ebben a struktúrában minden csomópont leírható ezzel a három információval. Ennek modellezése, majd az ábrázolása található a fenti két ábrán. A /-el jelölt információ azt jelenti, hogy valami hiányzik, vagyis vagy szülője nincs (a gyökérnek),
vagy pedig hiányzik valamelyik gyerek, vagy mindkettő.
Ezenkívül a
csomópontokhoz kötődik valamilyen plusz információ, amit fel kell dolgozni.
A hátizsák probléma és a mohó megoldása benne van jelen jegyzet negyedik fejezetében. Ehhez a mohó megoldáshoz készítettük el az alábbi ábrán látható osztálydiagramot. A feladatban sorbaállítjuk a dolgokat az egységnyi hasznosság szerint. A dolgok attribútumai a név, térfogat és hasznosság. Az egységnyi hasznosság már az osztály felelőssége, mert kiszámítható, mert egyenlő a hasznosság és a térfogat arányával. eh=hasznossag/terfogat
A hátizsák jellemzői ői a térfogat és a dologLista, amelyben megtalálható az összes dolog, ami a hátizsákba kerül. Lehet, hogy segítség lenne még egy attribútum, amelyik az aktuálisan üres (vagy teli) helyet adná meg, viszont az kiszámítható a hátizsákban levő dolgok térfogatainak összeadásával. A hátizsák szolgáltatásai az összesen elfoglalt térfogat, az összes hasznosság, annak ellenőrzése, hogy egy “következő” dolog belefér-ee a hátizsákba, na meg, ha belefér, akkor tegye bele a hátizsákba, vagyis abba a listába, amelyik a hátizsák hátizsák attribútuma.
xxx. ábra. A hátizsák probléma modellje
Kruskal algoritmusának osztálydiagramja. Kruskal algoritmusa egy minimális feszítőfa problémát old meg mohó megoldással. Az ábrán a lehetséges élek vannak felrajzolva. Ha bevesszük a megoldások közé, akkor a lehetséges élből valós él lesz.
Ebben az esetben a csomópontok közötti kapcsolat-osztály kapcsolat osztály a lehetséges élek osztálya. A csomópontnak legalább egy azonosító attribútuma kell legyen. A lehetséges él osztálynak attribútumai a csomópontok, amiket összeköt, az él költsége. Ahhoz, hogy a lehetséges lehets élből
megoldási él legyen, definiáltunk egy olyan logikai attribútumot, hogy megoldásban, amely kezdeti értéke hamis.
Xxx ábra. Kruskal algoritmus osztálydiagramja A főprogramban az elLista tartalmazza a lehetséges élek listáját. Erre kell egy rendezési algoritmus, amelyik az élek hossza szerint rendezi. Ez lesz a rendez() algoritmus. A hurokE(ujEL:lehetsegesEL):boolean az osztálynak az a felelőssége, hogy ha megadunk egy új élet, akkor egy logikai változón keresztül megadja, hogy hurok keletkezett-e a megoldásokban. Ha hurok keletkezne, azt az élet nem kell betenni a megoldási erdőbe.
Lényeges dolgok, amit a gyakorlatban (gyakorlati ZH-hoz) be kell tartani:
a) Az osztály általános (NEM Mars és Föld, hanem Bolygó, azok már objektumai az osztálynak) b) Az attribútumoknak tipusa van, s NEM int minden esetben. c) Az osztályok közötti kapcsolatoknak multiplicitása van. Általánosságban 1:1, 1:n és m:n. d) Az osztályhierarchiában az öröklődés megvalósításánál a láthatóság a protected vagy public e) A felelősségek megvalósításánál (operation) meg kell nézni, hogy az visszatérítő értéket ad-e, vagy szükség van-e paraméter megadásához. f)
Például, ha egy SET módszert adunk meg, amelyik beállít egy attribútum értéket, akkor paraméterként
meg
kell
adnunk
azt
az
értéket,
vagyis
így
néz
ki:
setAttrib(egyErtek:ertekTipus):void, g) amikor
kiolvassuk
egy
attribútum
értékét,
akkor
visszatérő
értéke
kell
legyen
getAttrib():ertekTipus, ahol az ertekTipus int, String vagy bármi más is lehet, akár egy másik osztályból keletkezett objektum. h) Történhet olyan is, hogy setAttrib(egyErtek:ertekTipus):visszateroErtekTipus. Ha megfigyeljük a hátizsák problémát, ott az egyik felelősség az, hogy a következő dolog befér-e a zsákba? Ennek megvalósítása a beleferE(egyDolog:dolog):boolean. Láthatjuk, hogy ez a felelősség igényel egy paramétert (egyDolog), amelyik a következő dolog, amit be szeretnénk tenni, s válasz is kell rá, hogy igen vagy nem, vagyis boolean tipust térit vissza.
1. Aggregáció és kompozíció (kutya feje és lába) 2. Asszociáció (lényeges a multiplicitás az osztályok között) a. Szerepek a kapcsolatban (pont és szakasz – szakasz végpontja, rajta van a szakaszon vagy rajta van az egyenesen, amit a szakasz meghatároz) 3. Asszociációs osztály (szerződés tipusú – dátum vagy idő kapőcsolódik hozzá) 4. Általánosítás, specifikáció (osztályhierarchia – emberek a könyvtári alkalmazásban, film, rajzfilm, bűnűgyi film, bűnűgyi rajzfilm)
Kompozíció és aggregáció. Egyes osztályok függnek egymástól, olyan mértékben, hogy akár egymás nélkül nem is létezhetnek. Amint az alábbi ábra mutatja, egy kutyát már nem lehet kutyának nevezni, ha nincs feje vagy törzse. Viszont, még mindig kutya, ha egy lába sincs, akkor is. Persze, ez alkalmazásfüggő. Nincs értelme lábatlan kutyáról beszélni egy olyan alkalmazásban, amelyben kutyafuttatás történik. Ebben az esetben a láb is kompozíció része lesz. Kompozíciós vagy aggragációs kapcsolatnak nevezzük 2 osztály azon kapcsolatát, ahol az egyik osztály egy objektuma magába foglalja a másik osztály egy vagy több objektumát. A kompozíciós kapcsolatban a bennfoglaló osztály objektuma nem létezhet a bennfoglalt osztály legalább egy objektuma nélkül. Az aggregációs kapcsolatban a különbség az, hogy létezhet olyan bennfoglaló objektum, amelyik nem tartalmaz egy bennfoglalt objektumot sem.
xxx. Ábra. A kompozíció és az aggregáció közötti különbség
xxx. Ábra. A kompozíció és aggregáció közötti különbség egy másik változata
Amint látjuk a fentebbi ábrából, egy vonatot nem lehet vonatnak mondani, ha nincs mozdonya, mert akkor nem tud elmozdulni egy elvárt irányba, viszont vagonok nélkül is lehet vonatnak hívni, ha van legalább egy mozdonyunk. Lehet több mozdonyunk is, például, mikor hegyre flefele halad a szerelvény, húzgatja két mozdony, vagy egyik húzza, másik taszítja. De lefele is jó a két mozdony, mert könyebben tudja fékezni a szerelvényt, s ha az egyik mozdonynak nem működne a fékrendszere, a másik esetleg meg tudná akadályozni a vonat elszabadulását a lejtőn.
xxx. Ábra. Bruttó felosztása adókedvezmény nélküli esetben Az aggregáció egy elokvens példája, amikor a bruttó fizetésből “kiszámoljuk” a nettó fizetést. Miután levonjuk a társadalombiztosítási összeget, az alkalmazott által fizetendő egészségűgyi hozzájárulást, a munkanélküli segélyhez való hozzájárulást és a nyugdíjalapot, marad nekünk egy X összeg, amelyik amúgy az adózandó összeggel is egyenlő, mivel nincs ebben az esetben semmiféle adóalap csökkentő összegünk. Ez esetben az X összegre kiszámított 16%-os fizetésadó + a nettó fizetés összege pont ezt az X összeget jelenti. Ha adókedvezményünk van, a rendszer kicsit megváltozik. A megmaradt X összeg egyenlő lesz ugyancsak a nettó + fizetésadó összegével, viszont az adó kiszámítása már nem ilyen egyértelmű. Ugyancsak ez a megmaradt X összeg egyenlő az adózandó összeggel + az adókedvezménnyel, mint az alábbi ábra is mutatja.
xxx. Ábra. Bruttó felosztása adókedvezmény létezése esetében Az asszociációs osztály Az asszociációs osztály egyik formájában szerződés tipusú.
xxx. Ábra. A szerződés tipusú asszociációs osztály
Definíció Asszociációs osztályhoz kell létezzen két osztály az asszociációs osztályon kívül. Az asszociációs osztály egy objektuma akkor keletkezik, amikor az egyik osztály objektuma kapcsolatba lép egy másik osztály objektumával. Ezért, a szerződés tipusú diagram esetében a dátum egy szükséges attribútuma az asszociációs osztálynak.
Az osztályhierarchia diagram. Specializálás és általánosítás. Az általánostól a speciális osztály felé haladva specializálásról beszélünk. A speciális osztálytól, ha az általános felé haladunk általánosításról beszélünk. A film az egy általánosabb fogalom. Ahhoz, hogy az attribútumokat, amelyeket beírtunk örökölhetőek legyenek a specializált osztályok által, protected láthatóságúak kell legyenek, amint az ábrán is a rács (sharp) jel mutatja.
xxx. Ábra. A film főosztály osztályhierarchia diagramja Azt mondjuk, hogy egy rajzfilm is egy film, csak a szereplőkhöz színészek adják a hangjukat. A felrajzolt ábrán újradefiniáltuk a hossz attribútumot. A bűnűgyi film is egy film, amelyhez
gyilkos fegyverlista tartozik, mert több gyilkos fegyver is szerepelhet a filmben. A bűnűgyi rajzfilm akár örökölhetne a rajzfilmtől is és a bűnűgyi filmtől is. Ez az eset viszont nem javasolt az objektumorientált paradigmában. A több ágon való öröklődés rossz példájakénta pl. hossz attribútumot is megnevezhetnénk. Ha a rajzfilm ágon úgy értelmezik, hogy percekbeni hossz (régebbi filmeknél a szalag hossza is lehetett volna), a másik bűnűgyi film ágán pl. megabájt(MB) –ban mérik a hosszúságot, akkor a bűnűgyi rajzfilm esetében ez elég nagy kavarodást okozhat, mert nem tudjuk, hogy mibe is mérjük vagy mérhetjük a hosszt. Nem lehet mindig egyértelműen megállapítani, hogy egyik vagy másik megközelítése jó egy osztálydiagram-tipúsnak. Az alábbi ábra pont ezt hivatott bizonyítani. Elfogadható kellő indoklással akármelyik változata az osztálydiagramnak.
xxx. Ábra. Egy másfajta ábrázolása a szakasz és a pont kapcsolatának Szerepek a kapcsolatban
xxx. Ábra. Ember és repülőgép közötti szerepek
Ha egy alkalmazásbankét osztály között többféle kapcsolat is létezhet, akkor azt mondjuk, hogy szerepek léteznek a kapcsolatban. Amint látjuk, a repülőgép és az ember közötti kapcsolatban, mikor egy repülőgép – személyszállítási alkalmazást modellezünk, az ember lehet utas, pilóta vagy utaskísérő. Persze, lehet szerelőmester is, de az lehet, hogy nem tartozik hozzá az alkalmazáshoz.
xxx. Ábra. Számítógép, alaplap, processzor és memória osztálydiagramja Amint látjuk, az alaplapon találhatóak a processzor és a memória. Az alaplap viszont a számítógép részét képezi.
Irodalomjegyzék [1] Angszter Erzsébet, Objektumorientált tervezés és programozás, Java, Akadémiai nyomda, Martonvásár,2002 [2] Raffai Mária, UML2, Modellező nyelvi kézikönyv, Palatia, Budapest, 2007. 2-ik kiadás [3] Sike Sándor, Varga László, Szoftvertechnológia és UML, Elte-Eötvös, Budapest, 2003, 2-ik kiadás [4]
Kondorosi
Károly,
szoftverfejlesztés,
Szirmay-Kalos
László,
László
Zoltán,
Objektumorientált
http://www.tankonyvtar.hu/en/tartalom/tkt/objektum-
orientalt/ch01.html [5] http://hu.wikipedia.org/wiki/Algoritmus [6] http://en.wikipedia.org/wiki/ISO/IEC_12207 [7] http://en.wikipedia.org/wiki/IEEE_12207 [8] http://hu.wikipedia.org/wiki/Mohó_algoritmus [9] Mark Norton, "Decisioning: A New Approach to Systems Development (Part 1)," Business Rules Journal, Vol. 8, No.1 (Jan. 2007), URL: http://www.BRCommuity.com/a2007/b326a.htm [10] Mark Norton, "Decisioning: A New Approach to Systems Development (Part 2)," Business Rules Journal, Vol. 8, No.1 (Jan. 2007), URL:http://www.BRCommunity.com/a2007/n326b.html
