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. Követelmények kezelése Követelmények megállapítása, leírása Követelmények érvényességének nyilvántartása (rendszertervezési változatok)

Hasonló előadás


Az előadások a következő témára: "Gyurkó György. Követelmények kezelése Követelmények megállapítása, leírása Követelmények érvényességének nyilvántartása (rendszertervezési változatok)"— Előadás másolata:

1 Gyurkó György

2

3 Követelmények kezelése Követelmények megállapítása, leírása Követelmények érvényességének nyilvántartása (rendszertervezési változatok) Követelmények teljesítésének követése

4 Követelmények típusai Funkcionális követelmények Nem funkcionális követelmények (pl. egyidejűleg kiszolgált felhasználók száma, skálázhatóság,...)

5 A Use Case modell célja: A funkciók / funkcionális követelmények meghatározása A rendszer határainak megvonása Felhasználó szerepkörök és jogosultságaik meghatározása A projekt által igényelt erőforrások becslése A projekt ütemezésének, idő- és költségtervezésének, megalapozása A tesztspecifikációk készítésének támogatása (a használati esetek képezik a felhasználói tesztesetek / tesztspecifikációk közvetlen bemenetét)

6 A használati eset diagram szimbólumai Használati esetek (use case-ek, „krumplik”): a rendszernek a felhasználó által látható funkciói, szolgáltatásai Felhasználói szerepkörök (aktorok, pálcikaemberek): felhasználói szerepek vagy kapcsolódó más alkalmazások Kapcsolatok (asszociációk): aktor és használati eset közötti kapcsolatok Függőségek: használati eset közötti viszonyok Általánosítás / specializáció: aktor-aktor, illetve eset-eset viszonyok

7 Egy áttekintő use case diagram

8 Magyarázatok a „KIR áttekintése” ábrához / 1 Miért kell modellezni az aktorokat mint szerepköröket? Mert a szerepkörökhöz így rendelhetők hozzá a szolgáltatások használatára vonatkozó jogok. Mit fejeznek ki az előző ábra általánosítás / specializáció értelmű nyilai? Azt, hogy a KIR felhasználó szerepkörnek specializációi az Érkeztető, az Iktató, az Ügyintéző, az Irattáros és a Rendszergazda szerepkörök. A milyen állításoknak van helye a KIR felhasználó szerepkör specifikációjában? Olyan állításoknak, amelyek közösen érvényesek minden felhasználóra, azaz a KIR felhasználó szerepkör minden specializációjára. Mit fejez ki egy aktor és egy használati eset közötti asszociáció? Azt, hogy az aktorral képviselt szerepkörnek joga van használni a használati esetet (szolgáltatást).

9 Magyarázatok a „KIR áttekintése” ábrához / 2 Milyen szolgáltatásokhoz van hozzáférése az Iktató szerepkörnek? A Kézbesítés és az Ügyiratkezelés szolgáltatás(csomagok)hoz. Mire való a megjegyzés szimbólum a diagramon? Olyan tudnivalókat közölhetünk vele, amelyeket a diagram nem tud kifejezni. Azonos konkrét felhasználónak (konkrét személynek) egyidejűleg lehet- e több szerepköre? Igen. Ugyanis az „Ezt a szerepkört is általában az iktató látja el az ügyintéző helyett”* megjegyzésből az következik, hogy lehet olyan felhasználó, aki egyszerre rendelkezik mind az Iktató, mind az Ügyintéző szerepkörrel. * Az „Ezt a szerepkört is általában az iktató látja el az ügyintéző helyett” megjegyzésből, nem következik, hogy az iktató ügyeket is elintéz. Inkább arról van szó, hogy a KIR egy iratkezelő rendszer neve, és az Ügyintézés szolgáltatáscsomag valójában az ügyintézésben érintett iratok keletkezésével, mozgásával, állapotváltozásával kapcsolatos adatok rögzítésére ad lehetőséget, de ezeket az adatokat mégsem az ügyintéző rögzíti ő csak olyan feljegyzéseket ír a mappára vagy a fizikailag (papíron) létező iratra, amelyek alapján az iktató el tudja végezni a rendszer által az ügyintézés következményeiről várt adatok bevitelét.

10 Az előző diagram „Küldemények kezelése” esetének kifejtése

11 Magyarázatok a „Küldemények kezelése” ábrához / 1 Az ábrán az Érkeztető felhasználót csak három használati esettel („krumplival”) köti össze asszociáció. Ez azt jelenti ez a felhasználó csak ezt a három szolgáltatást veheti igénybe (csak ezeket a „krumplikat” érheti el)? Nem. Igénybe veheti azok kötelező részeit ( >) és opcionális kiterjesztéseit ( >) is. – Másképpen: elérheti az összes „krumplit”, amelyhez (az említett három „krumpliból” vezet > és / vagy > sztereotípusú függésekből álló láncolat. Mit fejeznek ki a Küldeményadatok kezelése – általános használati esetből kiinduló > függések? Azt, hogy a Küldeményadatok kezelése – általános használati eset kötelezően tartalmazza a nyilakkal mutatott hat másik használati esetet (szolgáltatást). – Pl. a Küldeményadatok kezelése – általános használati esetben egy a felhasználó egy olyan képernyőt kezel, amelynek hat panelje van. (Ha a hat panel túl nagy felületet adna ki, elképzelhető az is, hogy a képernyőt hat füleslap alkotja.)

12 Magyarázatok a „Küldemények kezelése” ábrához / 2 Mit fejeznek ki az ábra használati esetei közötti általánosítás / specializáció értelmű nyilak? 1. A Küldeményadatok kezelése – általános használati esetnek specializációi a Küldeményadatok megtekintése és az Érkeztetés iktatás nélkül esetek. 2. A Küldeményadatok megtekintése esetnek specializációja a Küldeményadatok módosítása eset. Az ábrán az Érkeztető felhasználótól nem vezet > és / vagy > sztereotípusú függésekből álló láncolat a Küldeményadatok kezelése – általános használati esethez. Ezek szerint a felhasználó ezt az esetet nem használhatja? A felhasználó konkrétan a Küldeményadatok kezelése – általános használati esetet nem használhatja, hiszen az egy absztrakt használati eset, amely csak a konkrét esetek specifikációjának egyszerűsítésére szolgál azáltal, hogy azok specifikációjának közös elemi ebben kiemelhetők.

13 Magyarázatok a „Küldemények kezelése” ábrához / 3... Tehát a felhasználó Küldeményadatok kezelése – általános eset szolgáltatásait nem éri el? Amikor a felhasználó a Küldeményadatok kezelése – általános eset valamelyik specializációját használhatja, abban benne vannak (elérhetők) az általános esetnél specifikált szolgáltatások is. Mivel egyszerűsíti a Küldeményadatok kezelése – általános használati esetet jelenléte más használati esetek specifikációját? Azt a tényt, hogy a képernyő történetesen tartalmazza a Küldemény főbb adatai, a További beküldők, a Mellékletek,..., Csatolmányok paneleket / füleslapokat, nem kellett duplán, az Érkeztetés iktatás nélkül és a Küldeményadatok megtekintése eseteknél is specifikálni.

14 Példa a „Digitális óra” esettanulmányból Áttekintő változat Részletező változat

15 Példa az „Egy lakás biztonsági rendszere” esettanulmányból

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

17 Egy használati eset részleteinek kifejtése Másik - részletező - use case diagram Szöveges forgatókönyv (scenárió) A viselkedésmodellezésből vett technikák (szekvenciadiagram, tevékenységdiagram)

18

19 A statikus modellezés Cé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)

20 Statikus modellek típusai Elemzé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)

21 Objektumdiagram

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

23 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ú.

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

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

26 Objektumdiagram – C# környezethez illeszkedő

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

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

29 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

30 Magyarázatok az osztálydiagramhoz / 3 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 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.

31 Magyarázatok az osztálydiagramhoz / 4 Mé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.

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

33 Magyarázatok az osztálydiagramhoz / 6 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 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

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

35 Osztálydiagram – C# környezethez illeszkedő

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

37 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)

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

39 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

40 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

41 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..*

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

43 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

44 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 fogunk érteni.

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

46 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

47 Példák osztályok közötti függőségre

48 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


Letölteni ppt "Gyurkó György. Követelmények kezelése Követelmények megállapítása, leírása Követelmények érvényességének nyilvántartása (rendszertervezési változatok)"

Hasonló előadás


Google Hirdetések