Objektumorientált tervezés és programozás II. 3. előadás Gyurkó György

A tervezés vetületei és modellezési technikái (UML) Használati eset vetület (nézet) Funkcionális követelmények leírása Statikus modellek (szerkezeti modellezés) Osztályok definiálása, osztályok közötti viszonyok (általánosítás/specializáció, asszociációk, függések) esetleg objektumok és azok viszonyai Dinamikus modellek (viselkedésmodellezés) Objektumok együttműködése/kommunikációja, állapotváltozásai (cél az osztályok metódusainak meghatározása, a statikus modell finomítása) Üzleti folyamatok leírása tevékenységdiagrammal (cél: a követelmények meghatározása, pontosítása) Alkalmazás / komponensmodul működésének leírása tevékenységdiagrammal Kivitelezési modellek (architektúramodell) Komponensdiagram (az alkalmazás felépülése kódkomponensekből) Telepítési diagram

Statikus modellek (szerkezeti modellezés) - folytatás példákkal

1. példa: Összegfokozatos nyomtatás

Az 1. példa célja Megmutatni, hogy az OO technológia kézenfekvő lehetőségeket kínál egy egész problémasereg egyszeri megoldására. Megmutatni a kiterjesztés és a megvalósítás közötti különbséget. Megmutatni az asszociáció és a (szűkebb értelemben vett) függés közötti különbséget.

1. példa: Összegfokozatos nyomtatás általános megoldásának modellje A modellnek megfelelő, C# nyelvű kódváz az „1.példa a 3.előadáshoz.txt” nevű textfájlban található.

A specializáció két változata Kiterjesztés: A B osztály plusz képességet ad hozzá az az A ősosztály képességeihez, vagy valamit az ősosztálytól eltérő módon old meg. (Két interfész között csak kiterjesztés viszony lehet.) Megvalósítás: A B osztály megvalósítja (1) az A interfészt vagy (2) egy <<type>> sztereotípusú osztály műveleteit. (A (2) eset a C# és a Java nyelvekben nem értelmezhető.) A B A B

Az asszociáció változatai (Sima) asszociáció: Az egyik osztály (mondjuk az A) példánya azért tudja használni a másik osztály (mondjuk a B) egy példányát, mert az A-nak van egy olyan példány-adattagja, amely B típusú, azaz a B egy példányára hivatkozik. Kompozíció: Tartalmazási asszociáció. Az A-példány tartalmazza a B-példányt. A B egy példányát az A-nak legfeljebb egy példánya tartalmazhatja; és a B egy már tartalmazott példánya más osztály példányaival sem lehet tartalmazotti viszonyban. Aggregáció: Gyengébb tartalmazási reláció. A B egy példányát az A-nak több példánya is „tartalmazhatja”; illetve más osztályú objektumok is „tartalmazhatják”. A B A B A B A B A B A B

Navigáció az asszociáció mentén b Két irányú navigáció: Az a:A objektum elérheti/használhatja a b:B objektumot, mert az a:A-nak van egy olyan példány-adattagja, amely a b:B objektumra mutat. De fordítva is: a b:B objektum elérheti/használhatja az a:A objektumot, mert a b:B-nek van egy olyan példány-adattagja, amely az a:A objektumra mutat. (A szerepnevekből adattagok lesznek.) Egy irányú navigáció : Az A példánya elérheti/használhatja a b:B objektumot, mert az A-nak van egy olyan példány-adattagja, amely a b:B objektumra mutat. Fordítva nem igaz. (Csak a navigálható véget kell szerepnévvel ellátni.) A B a b A B a b A B b A B b A B b A B

Asszociáció (végeinek) számossága b 1. példa: Az a:A objektum elérhet/használhat legfeljebb egy b:B objektumot. (A b szerepnévből egy skalár-adattag lesz az A definíciójában.) A b:B objektum elérheti/használhatja az A-nak akár több példányát is. (Az a szerepnévből egy gyűjtemény-adattag lesz a B definíciójában.) 2. példa : Az A egy példánya elérhet/használhat legfeljebb egy b:B objektumot, de az A-nak több példánya is elérheti/használhatja a B ugyanazon példányát. (Itt a B definíciójában nem lesz A osztályú adattag, mert az asszociáció A-vége nem navigálható.) A B 0..* 0..1 b A B 0..* 0..1

Osztályok közötti függés fogalma Tágabban értelmezve: A B osztály függ az A osztály-tól, ha valamilyen módon használja az A osztályt (annak definícióját). Ezen értelmezés szerint a speci-alizáció és az asszociáció is függés. Szűkebben értelmezve: A tágabb értelemben vett függések olyan esetei, amelyek mind a specializáció- tól, mind az asszociációtól különböznek. A szűkebb értelemben vett függés jelölése: A B Egyéb utalás hiányában függésen a szűkebben értelmezett függést foguk érteni.

Miért kell megjelölni a függéseket? Mert ha a B osztály függ az A osztálytól, akkor az A osztály definíciójának megváltoztatása kihathat a B osztály működésére is . Tehát a függések jelzésével azt dokumentáljuk, hogy valamely osztály definíciójának megváltoztatása mely más osztályok működésére lehet hatással.

Asszociáció és függés összehasonlítása b Asszociáció: Mindig az osztályok példányai között valósul meg. Nem példányosodó osztályra nem értelmezhető. A példa szerinti asszociáció esetében az A osztálynak van egy b:B példány-adattagja. Függés: Nem példányosodó osztály(ok)ra is értelmezhető. Akkor nem példány-példány, hanem osztály-példány vagy osztály-osztály viszonyt fejez ki. - A példa szerinti függés esetében az A osztálynak nincs B osztályú példány-adattagja, esetleg az A nem is példányosodik. Itt csak másfajta viszony lehetséges. Pl. az A egy tagfüggvényének egyik paramétere B típusú, vagy az A egy tagfüggvényének visszaadott értéke egy B típusú objektumra való hivatkozás, vagy .... A B A B

Függések további esetei

2. példa: Több irányból öröklődés A legtöbb fejlesztő környezet nem támogatja azt az esetet, amikor osztály egynél több ősnek kiterjesztés típusú specializációja.

2. példa: Több irányból öröklődés kiváltása kompozícióval – 1. változat A modellnek megfelelő, C# nyelvű kód az „2.példa a 3.előadáshoz.txt” nevű textfájlban található.

2. példa: Több irányból öröklődés kiváltása kompozícióval – 2. változat A modellnek megfelelő, C# nyelvű kód az „2.példa a 3.előadáshoz.txt” nevű textfájlban található.

3. példa: Dinamikus specializáció Az egyik osztály példányaként létrejött objektum utóbb másik osztály példányaként folytatja az életét. A fejlesztő környezetek nem támogatják.

3. példa: Dinamikus specializáció kiváltása kompozícióval

4. példa: Egyke (Singleton) Olyan objektum, amelyből egy rendszeren belül garantáltan csak egy példány lehet. s: az egyetlen példány mutatója, getSingleton(): az egyetlen példány mutatóját adja vissza. Miért nem oldható meg ez a probléma úgy, hogy a szolgáltatás() egy nem példá-nyosodó osztály osztályműve-lete?