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

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ánakmodellje 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 Ainterfé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 a 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:Bobjektum elérheti/használhatja az a:A objektumot, mert a b:B-nek van egy olyan példány-adattagja, amely az a:Aobjektumra 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 a 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:Bobjektum 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..1 0..* 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 Aosztály-tól, ha valamilyen módon használja az A osztályt (annak definícióját). Ezen értelmezés szerint aspeci-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 Aegy tagfüggvényének egyik paramétere B típusú, vagy az Aegy 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éskivá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éskivá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 aprobléma úgy, hogy a szolgáltatás() egy nem példá-nyosodó osztály osztályműve-lete?