Objektumorientált tervezés és programozás II. 3. előadás

Az előadások a következő témára: "Objektumorientált tervezés és programozás II. 3. előadás"— Előadás másolata:

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

2 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

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

4 1. példa: Összegfokozatos nyomtatás

5 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.

6 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ó.

7 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

8 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

9 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

10 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

11 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.

12 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.

13 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

14 Függések további esetei

15 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.

16 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ó.

17 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ó.

18 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.

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

20 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?