Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

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.

Hasonló előadás


Az előadások a következő témára: "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."— Előadás másolata:

1 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

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 > sztereotípusú osztály műveleteit. (A (2) eset a C# és a Java nyelvekben nem értelmezhető.) AB AB

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 AB AB AB AB AB

9 Navigáció az asszociáció mentén 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 AB AB AB AB AB a b a a b b b b b

10 Asszociáció (végeinek) számossága 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ó.) AB AB 0..* ab 0..1 b 0..*

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: AB 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 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.... AB AB 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 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ó

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?


Letölteni ppt "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."

Hasonló előadás


Google Hirdetések