Objektumorientált tervezés és programozás II.

2. 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)

A statikus modellezésCélja:Osztályok definiálása (a tagjainak

definiálásával)Osztályok közötti viszonyok (általánosítás /

specializáció, asszociációk, függések) megadása

Technikái:Osztálydiagram Objektumdiagram (előzetes elemzés osztálydiagram

készítéséhez vagy példányszintű részletek utólagos kifejtése)

Statikus modellek típusaiElemzési modell (a szakmai tartalomra

koncentrál)Tervezési modell (figyelembe veszi a

megvalósítás architektúráját, lehetőségeit; a programnyelvi környezet lehetőségeit)

Objektumdiagrama:Cikk

d:Cikk

c:Cikk

b:Cikk

e:Cikk

ad:Kapcsolat

- beepulDb: int = 7

ac:Kapcsolat

- beepulDb: int = 2

ab:Kapcsolat

- beepulDb: int = 10

de:Kapcsolat

- beepulDb: int = 2

dc:Kapcsolat

- beepulDb: int = 1

Egy konkrét termék (a) termékszerkezeti hálójának objektumdiagramja

A termékszerkezeti háló ábrán a csomópontok a cikkeket, a nyilak a beépülési kapcsolatokat képviselik. A nyilak a tartalmazó terméktől (szerelvénytől) a beépülő alkatrész (panel) felé mutatnak. A nyilak mellett a fajlagos beépülési darabszám (beepulDb) látható.

-kapcsoltCikk

-kapcsoltCikk

-kovetkezo

-kapcsoltCikk

-kapcsoltCikk

-kovetkezo

-kapcsoltCikk

-kovetkezo

-elsoKapcs

-elsoKapcs

Magyarázatok az objektumdiagramhoz / 1

Mit jelent a bal felső dobozban az a:Cikk jelölés?

Azt, hogy ez a doboz a Cikk osztályba tartozó a objektum szimbóluma.

Mit képviselnek az objektumdiagram Cikk osztályú objektumai?

A jobb alsó sarokban mutatott termékszerkezeti háló csomópontjait.

Mit képviselnek az objektumdiagram Kapcsolat osztályú objektumai?

A jobb alsó sarokban mutatott termékszerkezeti háló nyilait.

Mi az oka annak, hogy a termékszerkezeti háló nyilait is objektummal kell képviseltetni ezen a diagramon?

Az, hogy a nyilakhoz is tartoznak őket jellemző adatok. Ilyen az a -> d nyílhoz tartozó 7-es beépülési darabszám. Ezt csak egy objektum egy adattagjában (beepulDb) lehet letárolni.

Mit képviselnek az objektumdiagramon látható asszociációk (a diagramon látható nyilak)?

Az objektumok közötti navigációs lehetőségeket.

Magyarázatok az objektumdiagramhoz / 2

Mit mutat az a:Cikk -> ad:Kapcsolat asszociáció, ha még annak az ad felőli végéhez tartozó elsoKapcs szerepnevet is figyelembe vesszük?

Azt, hogy az a objektumtól létezik navigáció az elsoKapcs szerepet betöltő ad objektumhoz. (Ez a navigáció arra való, hogy az a objektumtól fel tudja szólítani az ad objektumot valamilyen művelet végrehajtására.)

Az előbbi asszociációból mi következik az a objektum (típusszinten a Cikk osztály) szerkezetére nézve?

Az objektumnak rendelkezni kell egy elsoKapcs nevű, Kapcsolat típusú adattaggal, amely éppen az ad objektumra mutat. – Típusszinten: A Cikk osztálynak rendelkezni kell elsoKapcs nevű, Kapcsolat típusú példányadattaggal.

Ezen objektumdiagram értelmében az ad:Kapcsolat objektum is felkérheti valamilyen művelet végrehajtására az a:Cikk objektumot?

Nem, mert ezen a diagramon az a:Cikk és az ad:Kapcsolat objektumok közötti asszociációban a navigáció csak egyirányú.

Magyarázatok az objektumdiagramhoz / 3

Mit jelent az elsoKapcs szerepnév előtti – (mínusz) jel?

A Cikk osztályban a szerepnév alapján generálódó elsoKapcs nevű példányadattagot private láthatóságúnak deklaráljuk.

Az objektumdiagramon miből látszik, hogy az a cikkbe éppen három másik cikk (a d, a c és a b) épül be közvetlenül?

Abból, hogy az a:Cikk objektumra az elsoKapcs szerepnevű, illetve a kovetkezo szerepnevű asszociációkkal éppen három Kapcsolat-példány van felfűzve: az ad, az ac és az ab; és ezek a kapcsoltCikk szerepnevű asszociációikkal rendre a d, a c, illetve a b cikkekre mutatnak.

Az objektumdiagramon miből látszik, hogy a c cikk nemcsak az a cikkbe épül be közvetlenül?

Abból, hogy a c:Cikk objektumra a dc:Kapcsolat objektum is rámutat egy olyan asszociációval, amelyben a c cikk szerepneve kapcsoltCikk; továbbá mivel a dc objektum a d cikkből induló kapcsolatláncra (listára) van felfűzve, a dc kapcsolat a c cikknek a d cikkbe való közvetlen beépülését reprezentálja.

Magyarázatok az objektumdiagramhoz / 4

Az objektumdiagram alapján összesen legalább hány példányadattagja lesz a Kapcsolat osztálynak?

Három:-beepulDB : int;-kovetkezo : Kapcsolat;- kapcsoltCikk : Cikk;Az utóbbi kettő az asszociációk szerepneveiből generálódik.

Minden Kapcsolat-példánynak ki van töltve a kovetkezo nevű adattagja?

Nem, mert például az ab példány esetében üresnek (null értékűnek) kell lennie.

Minden Cikk-példánynak ki van töltve az elsoKapcs nevű adattagja?

Nem, mert például a c példány esetében üresnek (null értékűnek) kell lennie.

Az előbbi objektumdiagramból származtatott osztálydiagram

Magyarázatok az osztálydiagramhoz / 1

Hogy került a ListaElem osztálydiagramra, ha az objektumdiagramon nem is volt ilyen osztályú objektum?

A ListaElem osztály megjelenésében két tény játszhatott közre:1. A Kapcsolat osztályú objektumoknak

rendelkezni kell olyan kovetkezo nevű adattaggal, amellyel az ilyen objektumok listába fűzhetők.

2. A tervező észre veszi, hogy fejlesztő környezet osztálykönyvtárában létezik egy olyan ListaElem osztály, amelynek egy kovetkezo nevű példányadattagja éppen arra való, hogy vele az osztály példányait listába fűzhessük. Tehát az 1. pontban leírt követelmény úgy is teljesíthető, hogy a Kapcsolat osztályt a ListaElem osztályból származtatjuk.

Az osztálydiagramon miből látszik, hogy a ListaElem osztálynak van egy kovetkezo nevű példányadattagja?

Abból, hogy ListaElem osztály egy kovetkezo szerepnevű asszociációban áll önmagával.

Magyarázatok az osztálydiagramhoz / 2

E modell szerint hogyan lesz a Kapcsolat osztálynak egy kovetkezo nevű példányadattagja?

Úgy, hogy a ListaElem osztálytól megörökli.

A ListaElem osztályból származtatás nélkül is megoldható lett volna, hogy a Kapcsolat osztálynak legyen egy kovetkezo nevű példányadattagja?

Igen. Úgy, hogy Kapcsolat osztályhoz veszünk fel egy olyan kovetkezo szerepnevű asszociációt, amely a Kapcsolat osztályra mutat vissza.

Az, hogy ListaElem osztály önmagával áll egy kovetkezo szerepnevű asszociációban, azt jelenti, hogy az osztály példányai is önmagukkal állnak ilyen asszociációban?

NEM!!! Azt jelenti, hogy egy listaelem és a (listában) rákövetkező listaelem is a ListaElem osztály példányai.

A diagramon milyen jelentésű szimbólum kapcsolja össze a ListaElem osztályt és a Kapcsolat osztályt?

Ez a nyíl az általánosítás / specializáció szimbóluma. Azt jelzi, hogy a Kapcsolat osztály specializációja (leszármazottja) a ListaElem osztálynak

Magyarázatok az osztálydiagramhoz / 3A kovetkezo szerepnevű asszociáció-nak a navigálható végén (azaz a nyilas végén) a 0..1 számosságban miért szerepel 0 alsó határ?

Mert egy lista utolsó eleme nem mutat egyetlen következő elemre sem. (Ha mutatna, akkor nem ő lenne az utolsó elem a listában.)

A kovetkezo szerepnevű asszociáció-nak a navigálható végén (azaz a nyilas végén) a 0..1 számosságban miért szerepel 1 felső határ?

Mert egy lista bármely eleméhez legfeljebb egy közvetlenül rákövetkező elem kapcsolódhat.

A kovetkezo szerepnevű asszociáció-nak a nem navigálható végén (azaz a nem nyilas végén) a 0..1 számosság-ban miért szerepel 0 alsó határ?

Mert egy lista első eleméhez nincs olyan listaelem, amelyre ő lenne a rákövetkező elem. (Ha lenne, akkor nem ő lenne az első elem a listában.)

A kovetkezo szerepnevű asszociáció-nak a nem navigálható végén (azaz a nem nyilas végén) a 0..1 számosság-ban miért szerepel 1 felső határ?

Mert egy lista bármely eleméhez legfeljebb egy közvetlenül megelőző elem létezhet a listában.

Magyarázatok az osztálydiagramhoz / 4Még az objektumdiagramhoz fűzött magyarázatok között azt állítottuk, hogy a Kapcsolat osztálynak három adattagja lesz:-beepulDB : int;-kovetkezo : Kapcsolat;- kapcsoltCikk : Cikk;Akkor az osztálydiagramon a Kapcsolat dobozban miért csak a beepulDB : int adattag látszik?

A kovetkezo adattagot azért nem kell feltüntetni a dobozban, mert ezt az adattagot a Kapcsolat osztály a Listaelem osztálytól megörökli. A kapcsoltCikk adattagot azért nem kell feltüntetni a dobozban, mert ezt a diagramon a Kapcsolat osztályból indított asszociáció kapcsoltCikk szerepneve képviseli.

A Kapcsolat(Cikk, int) konstruktor mire használhatja a megkapott paramétereket?

Az első paramétert az új Kapcsolat-példány kapcsoltCikk adattagjának adja értékül, a második paraméter értékét pedig a beepulDb veszi fel.

A kapcsoltCikk szerepnevű asszociá-ciónak a navigálható végén (azaz a nyilas végén) miért határozottan 1 a számosság?

Mert egy Kapcsolat-példány csak azért jön létre, hogy az mutasson egy kapcsolt cikkre; illetve az objektumdiagramon látszik, hogy egy Kapcsolat-példány csak egy cikkre mutathat.

Magyarázatok az osztálydiagramhoz / 5

A kapcsoltCikk szerepnevű asszociá-ciónak a nem navigálható végén (azaz a nem nyilas végén) a 0..* számosság-ban miért szerepel 0 alsó határ?

Mert vannak olyan cikkek, amelyekre mint kapcsolt cikkre egyetlen Kapcsolat-példány sem mutat (lásd az objektumdiagramon az a cikket).

A kapcsoltCikk szerepnevű asszociá-ciónak a nem navigálható végén (azaz a nem nyilas végén) a 0..* számosság-ban miért szerepel * felső határ?

Mert vannak olyan cikkek, amelyekre mint kapcsolt cikkre több Kapcsolat-példány is mutat (lásd az objektum-diagramon a c cikket). - Csupán az objektumdiagram alapján a 0..2 számosságra is következtethettünk volna, de itt a tervező számításba vett a diagramon nem ábrázolt eseteket is.

Az elsoKapcs szerepnevű asszociáció-nak a navigálható végén (azaz a nyilas végén) a 0..1 számosságban miért szerepel 0 alsó határ?

Mert van olyan cikk, amelyhez nem kapcsolódik elsoKapcs szerepben egyetlen Kapcsolat-példány sem (lásd az objektumdiagramon a c cikket).

Magyarázatok az osztálydiagramhoz / 6Az elsoKapcs szerepnevű asszociáció-nak a navigálható végén (azaz a nyilas végén) a 0..1 számosságban miért szerepel 1 felső határ?

Mert egy cikkhez legfeljebb egy Kapcsolat-példány kapcsolódhat elsoKapcs szerepben .

Az elsoKapcs szerepnevű asszociáció-nak a nem navigálható végén (azaz a nem nyilas végén) a 0..1 számos-ságban miért szerepel 0 alsó határ?

Mert van olyan Kapcsolat-példány, amely egyik cikknek sem első kapcsolata (lásd az objektumdiagramon pl. az ac kapcsolatobjektumot).

Az elsoKapcs szerepnevű asszociáció-nak a nem navigálható végén (azaz a nem nyilas végén) a 0..1 számos-ságban miért szerepel 1 felső határ?

Mert egy Kapcsolat-példány legfeljebb csak egy cikknek lehet első kapcsolata.

Mit fejez ki, hogy az elsoKapcs szerepnevű asszociációnak csak az egyik vége navigálható (azaz csak a Kapcsolat osztály felőli végén van nyílas)?

Azt, hogy egy Cikk-példány meg tudja szólítani az első kapcsolatát képező Kapcsolat-példányt, de nincs szükség arra, hogy Kapcsolat-példány megszólítsa azt a cikket, amelynek ő az első kapcsolata

Magyarázatok az osztálydiagramhoz / 7

Igaz-e, hogy a modell szerint egy Kapcsolat-példány soha nem szólíthat meg egy Cikk-példányt?

Nem. Egy Kapcsolat-példány meg tudja szólítani a hozzá kapcsoltCikk szerepben kapcsolódó Cikk-példányt.

Közelebbről mit jelent az, hogy egy x objektum meg tudja szólítani az y objektumot?

A x objektum fel tudja kérni az y objektumot egyik metódusa végrehajtására.

A diagramon látott asszociá-cióknak miért csak az egyik végéhez tartozik szerepnév?

Mert a nem navigálható véghez felesleges szerepnevet megadni.

Mit jelent az, egy navigáció egyik végén sincs nyíl?

1. Kidolgozott („végleges”) modellben azt, hogy az asszociáció mindkét vége navigálható.2. Kezdeti modellben jelentheti azt, hogy a navigálhatóságot még nem definiáltuk.Egy diagramon az 1. eset úgy tehető egyértelművé, hogy az asszociáció mindkét végéhez szerepnevet rendelünk.

Példa az„Egy szupermarket parkolási rendszere” esettanulmányból

Példa az „Egy szupermarket parkolási rendszere” esettanulmányból

Az előbbi osztálydiagramból származtatott osztály-diagram (elemzési modell)

Példa az „Egy szupermarket parkolási rendszere” esettanulmányból

Osztálydiagram - tervezési modell változat (figyelembe veszi a szálakat)

Az elemzési modelltől való eltérés jellemzőbb okai:- Különböző forrásnyelvi környezetek- Különböző készen adott osztálykönyvtárak.

Az asszociáció speciális változatai Kompozíció: Tartalmazási

asszociáció. Az A tartalmazza B-t. A B egy példányát az A-nak legfeljebb egy példánya tartal-mazhatja; é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 „tartalmazhat-ják”.

A B

A B

A B

A B

Példa megvalósításra és függőségre

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

Osztályok közötti függés fogalmaTá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

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.

Még egy példa függőségreProgram.cs:...namespace OO_szemléltetés{ static class Program { /// <summary> /// The main entry point for the application. /// </summary> [STAThread] static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new Form1()); } }}

Még egy példa függőségre - folytatás

További példák függőségre

Az osztálydiagram szimbólumai

Osztály (interfész, típus, C#-ban struktúra is)

Általánosítás / specializáció (kiterjesztés, megvalósítás)

AsszociációAggregáció, kompozícióFüggőség