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

Rational Unified Process Elemzés - Tervezés. Témáink I. Objektumorientált alapfogalmak II. Elemzés - tervezés munkafolyamat –1. Egy lehetséges felépítmény.

Hasonló előadás


Az előadások a következő témára: "Rational Unified Process Elemzés - Tervezés. Témáink I. Objektumorientált alapfogalmak II. Elemzés - tervezés munkafolyamat –1. Egy lehetséges felépítmény."— Előadás másolata:

1 Rational Unified Process Elemzés - Tervezés

2 Témáink I. Objektumorientált alapfogalmak II. Elemzés - tervezés munkafolyamat –1. Egy lehetséges felépítmény meghatározása –2. A felépítmény finomítása –3. A viselkedés elemzése –4. Komponensek tervezése –5. Adatbázis tervezése

3 I. Objektumorientált alapfogalmak

4 Objektumorientált alapfogalmak - témák Objektumok Osztályok Általánosítás - pontosítás OO és strukturált módszerek

5 Az objektumorientált szemlélet Az objektumorientált szemlélet a valóság megközelítésének, modellezésének, ábrázolásának egy módszere A „mit” és nem a „hogyan” a lényeges A rendszer elemzését és tervezését is egyaránt az objektumorientált modellezés fogalomvilága segítségével végezzük el.

6 Objektum Intuitív: az objektumok egyedeket képviselnek, amely egyedek lehetnek akár fizikai, akár fogalmi, akár számítógépes dolgok

7 Objektum Diszkrét entitás, amelyet adott időpontban adott tulajdonságokkal írhatunk le, és amely tulajdonságok az időben változhatnak –állapot –viselkedés –egyediség: objektum-azonosító egységes ábrázolásúak Jelölés: Kovács János

8 Objektum állapota Az objektum ily módon létezik Az állapot időben változik Általában tulajdonságokat (attribútumokat) használunk a megvalósításhoz, amely tulajdonságok aktuális értékei és az objektum pillanatnyi kapcsolatai határozzák meg az objektum állapotát.

9 Objektumok viselkedése Hogyan hat az objektum a környezetére, és hogyan reagál a környezet hatásaira Üzenetküldés, eseménygenerálás Üzenet vagy esemény: egy objektumtól egy másik objektum (vagy önmaga) felé történő egyirányú információ továbbítás (adatközlés) OO: a kommunikációt csak bizonyos módszerek által alkotott felületen keresztül engedélyezzük (egységbe zárás fogalma), így a rendszer áttekinthetőbb és könnyebben módosítható lesz.

10 Osztály A közös tulajdonságokkal, viselkedéssel és kapcsolatokkal rendelkező objektumok csoportosítása Minden objektum valamilyen osztály példánya (instancia) Jelölés: Személy születési dátum születési hely életkor() Tulajdonságok Műveletek Név

11 Osztályozás, osztály, példány Osztály, példány

12 Osztályok elnevezése Az osztály neve célszerűen egyes számú főnév, ami a legjobban jellemzi az osztályt Ha nehezen tudunk nevet adni egy osztálynak, akkor az jelezheti azt, hogy nem jó az osztályunk A fogalomszótárt használjuk az elnevezéskor Névképzési konvenció: –Egyes számú főnév –Nagybetűvel kezdődik és csak betűket tartalmaz –Több szóból képzett név esetén a szó elején nagybetű van

13 Általánosítás - pontosítás Szuper- vagy ősosztály Al- vagy (le)származtatott osztály. Osztályszerkezet ÁtutalásosKifizetés kifizetésDátuma végösszeg pénzforgalmiJelzõszám Készpénzes Kifizetés kifizetésDátuma végösszeg kiadásiPénztárBizonylat Kifizetés kifizetésDátuma végösszeg ÁtutalásosKifizetés pénzforgalmiJelzõszám KészpénzesKifizetés kiadásiPénztárBizonylat

14 Elvonatkoztatás, mint megosztás Közös információk megosztása (sharing) Nõ - név - születésiDátum - születésiHely - lánykoriNév - lakcím + költözés() Férfi - név - születésiDátum - születésiHely - sorköteles - lakcím + költözés() Férfi - sorköteles Nõ - lánykoriNév Személy - név - születésiDátum - születésiHely - lakcím + költözés()

15 Osztályok tervezése / Általánosítás (öröklődés) A közös viselkedés és közös szerkezet kiemelhető egy ős-osztályba A leszármazottak öröklik az ős viselkedését és tulajdonságait - kód újrafelhasználás (re-use) Általánosításkor figyeljünk arra, hogy az ősbe kiemelt tulajdonságokat, műveleteket töröljük ki a leszármazottakból

16 Öröklés Alakzat szín színváltás() kirajzolás() törlés() Vonal végpontok kirajzolás() törlés() Körív sugár kezdõszög végszög kirajzolás() törlés() Poligon töréspontok kirajzolás() törlés() Ős Leszármazottak

17 Többszörös öröklés Jármű SzárazföldiJármű VíziJármű Hajó Autó KétéltűJármű

18 Leszármaztatás – diszkriminátor, különleges megszorítások Jármű SzélHajtottaJárműMotorosJárműVíziJárműSzárazföldiJármű hajtóerõ terep Kamion Vitorláshajó Hajó {overlapping}

19 Öröklés Halmaz-részhalmaz viszony Rendszerint különböző alternatívákat fejez ki (“or”) Egy osztály több különböző dimenzió mentén is specializálható –egy konkrét objektum minden dimenzióban részt vehet (“and” általánosítás) –Az általánosítás vonalához ún. diszkriminátor rendelhető, ezek különítik el a dimenziókat –ugyanaz a diszkriminátor - ugyanaz a dimenzió különböző diszkriminátor - független dimenziók

20 Felület és megvalósítás Polimorfizmus (többalakúság): azonos nevű műveletet más osztály objektumai másként is megvalósíthatnak Megvalósított művelet a módszer (method) Korai/késői (típusle-) kötés (early/late binding) Alakzat forgatás() Kör forgatás() Elipszis forgatás() Téglalap forgatás()

21 Egységbe zárás (encapsulation) előnyei Információ-rejtés Extenzív bővítés lehetősége Alakzat forgatás() Kör forgatás() Elipszis forgatás() Téglalap forgatás() Poligon forgatás()

22 Absztrakt osztály Nincsenek példányai Alakzat szín mozgatás() kirajzolás() törlés() Vonal végpontok kirajzolás() törlés() Absztrakt osztály Konkrét osztály

23 Paraméterezett osztály Paraméterezett (váz- vagy minta-) osztály

24 OO mint absztrakciós eszköz

25 Sztereotípusok (Stereotype) Az osztályok magas szintű tipizálása (milyen célt szolgál) UML: általános kiterjesztési mechanizmus Elem elé írjuk (Szinte mindennek lehet sztereotípiája) > Ábrázolható címkével illetve ikonnal

26 Strukturált és OO módszer

27 Folyamat felbontása

28 OO mint egységbe zárás egységbe zárás (encapsulation)

29 II. Elemzés - tervezés munkafolyamat

30 Elemzés - tervezés Az előzőekben összegyűjtött követelményeket kielégítő rendszer tervezése Robosztus felépítmény kialakítása A rendszerterv illesztése a megvalósítási környezethez és a hatékonysági elvárásokhoz

31 Munkafolyamat

32 Elemzés-tervezés A kidolgozás fázis kezdeti szakaszában az a cél, hogy a rendszerhez egy kezdeti felépítményt (architektúra) határozzunk meg (felépítmény jelölt) –Ez lesz az elemzési munka kiindulási pontja Ha a felépítmény már létezik –vagy azért, mert egy korábbi iterációban vagy korábbi projektben már kidolgoztuk, –vagy pedig azért, mert az alkalmazási keretrendszer eleve meghatározza azt akkor cél a meglévő felépítmény finomítása

33 Elemzés-tervezés A kiválasztott használati eseteket elemezni kell Meg kell határozni azokat az elemzési osztályokat, amelyek megvalósíthatják a használati esetekben definiált funkciót A használati eset viselkedését szét kell osztani az elemzési osztályok között –elemzési osztályok felelősségeinek meghatározása Meg kell határozni az elemzési osztályokat megvalósító tervezési osztályokat és alrendszereket Meg kell tervezni az adatbázist

34 Egy lehetséges felépítmény meghatározása

35 Egy lehetséges felépítmény meghatározása - Cél A rendszerfelépítmény kezdeti vázának elkészítése –A felépítmény szempontjából lényeges elemek meghatározása –Elemzési módszerek meghatározása –Az alrendszerek magas szintű körülhatárolása (rétegek és partíciók) –Használati eset megvalósítások létrehozása Az elemzési osztályok meghatározása a felépítmény szempontjából lényeges használati esetek elemzése alapján Az elemzési osztályok kapcsolatai alapján módosítani a használati esetek megvalósításait

36 Egy lehetséges felépítmény meghatározása Kapcsolódó tevékenységek: Felépítmény- (architekturális) elemzés –a rendszer számára egy kezdeti felépítmény meghatározása a cél. Használati esetek elemzése –A felépítmény szempontjából meghatározó használati esetek elemzése

37 Felépítmény- elemzés A rendszerhez egy lehetséges felépítmény meghatározása. –A kezdeti felépítmény meghatározása során a hasonló rendszerek fejlesztésében és az adott szakterületen szerzett tapasztalatokat lehet felhasználni. A rendszer számára felépítmény minták, módszerek és modellezési szabályok meghatározása. Újrafelhasználhatósági stratégia meghatározása A tervezési folyamat számára szükséges kiinduló anyagok biztosítása.

38 Felépítmény- elemzés Modellezési konvenciók kidolgozása –Nagyon fontos, hogy a modell miként adja vissza az elemzés eredményét Újrafelhasználható elemek azonosítása és az újrafelhasználás lehetőségeinek megvizsgálása Az alrendszerek magas szintű meghatározása (rétegek és partíciók) –Általában két réteg: üzleti és alkalmazás réteg –Az alacsonyabb szintű felbontás a felépítmény-tervezés feladata –UML eszköz a modell felbontására: csomag

39 Felépítmény (architekturális) elemzés - Csomag A rendszer építőelemeinek (osztályoknak, használati eseteknek, stb.) a magasabb szintű egységekbe való csoportosítása. Megadható: –Sztereotípus és jellemző (pl.: >) –Láthatóság Tesztelés egysége is lehet Adattipusok global > Alkalmazas Reteg > UzletiReteg >

40 Felépítmény elemzés - Függőség Két elem között függőség van, ha az egyik felületének megváltozása a másik (a függő) elem megváltozását is eredményezheti. Csomagok esetén: ha a függő csomag valamely eleme függ a másik csomag egy elemétől. A függőségeket célszerű minimálisra csökkenteni Alkalmazas Reteg > UzletiReteg >

41 Felépítmény elemzés Elemzési mechanizmusok, szempontok definiálása –Elemzési minták kiválasztása (szerkezeti, viselkedési) Minta: általános probléma általános megoldása A bonyolultságot csökkenti és konzisztenciát növeli –Számítástechnikai fogalmak és nem szakterületiek –Példa: perzisztencia megvalósítása (várható elemszám, méret, változási gyakoriság), hibakezelés Alapvető absztrakt fogalmak azonosítása –Elemzési osztályok és kapcsolatok (alap: fogalomszótár, üzleti vagy szakterületi modell, ha készült korábban) –Csak kigyűjtés: amelyek már korábban (üzleti modellezés, követelményelemzés) kiderültek

42 Felépítmény elemzés – Használati eset megvalósítása Használati esetek megvalósításának létrehozása –A használati esetek további elemzésének, tervezésének előkészítése –A használati eset modellben szereplő valamennyi használati esethez hozzunk létre egy használati eset megvalósítást ( >) a tervezési modellben (név ugyanaz.) Jelentkezés tanfolyamra megvalósítása Jelentkezés tanfolyamra >

43 Használati esetek elemzése - Cél Azonosítani azokat az osztályokat, amelyek az adott használati eset végrehajtásában részt vesznek. A használati eset megvalósítások segítségével szétosztani a használati eset viselkedését az azonosított elemzési osztályok között. Meghatározni az osztályok felelősségeit, tulajdonságait és kapcsolatait (attribútumait és asszociációit). A felépítményt alkotó mechanizmusok használatával kapcsolatos információk meghatározása.

44 Használati esetek elemzése / Elemzési osztályok felelősségei Felelősség (responsibility): szolgáltatás, ami az objektumtól kérhető. –Az elemzés során a műveletek ábrázolják az elemzési osztályok felelősségeit –Jellemzően: Valamilyen tevékenység, amit az objektum végez Valamilyen tudás, amit az objektum kezel, és felajánl más objektumoknak –Amennyiben az elemzési osztály egy komplex részrendszert takar (szimulációs rendszer - szimulációs motor), a felelősség a részrendszer szempontjából a használati esetek szerepét tölti be

45 Használati esetek elemzése - lépések A használati eset leírásának kiegészítése Minden egyes használati eset megvalósításhoz: –Keressük meg az elemzési osztályokat a használati eset által megszabott viselkedés alapján –Osszuk szét a viselkedést az osztályok között Minden egyes elemzési osztályhoz: –Írjuk le a felelősségeit –A tulajdonságait és kapcsolatait –Adjuk meg az egyéb jellemzőit Egységesítsük az elemzési osztályokat

46 Egy megközelítés az elemzés elvégzésére Keressünk elemzési osztályokat és alkossunk elemzési modellt belőlük a feladat és a használati esetek leírása alapján! (alulról felfelé) Valamilyen módon (kölcsönhatás diagramok) bizonyítsuk, hogy ez a modell szükséges és elégséges feltétele a feladat elvégzésének! (felülről lefelé elemzés)  A megrajzolt kölcsönhatás (interakciós) diagramok segítségével derítsük fel az elemzési osztályok felelősségeit, biztosítva ezzel, hogy csak azt oldjuk meg, ami valóban a feladatunk.

47 Használati eset leírásának kiegészítése A belső részleteket is tisztázni kell. Példa: –„Az ATM ellenőrzi a behelyezett kártya érvényességét”. –„Az ATM elküldi a központi rendszerbe a számlaszámot, és a PIN kódot. A központi rendszer pozitív választ ad, ha a számlaszám és a kód egyezik, és az ügyfél jogosult tranzakciókat végezni, különben hibajelzést küld vissza.” –Eredmény: Ellenőrzéshez szükséges adatok (számlaszám, PIN) Ki a felelős az ellenőrzésért (a központi rendszer, aki az ATM szempontjából szereplő) Két osztály-jelölt: –az ügyfél, akinek van számlaszáma, és PIN kódja –egy interfész osztály, aki az ATM és a központi rendszer közötti kommunikációért felelős

48 Elemzési osztályok Az elemzési osztályok a rendszer fogalmi modelljét alkotják. „Dolgok, amivel a rendszernek foglalkozni kell.” Az UML-ben osztályok reprezentálják, amelyek sztereotípiája: – > - külső kapcsolat – > - entitás, belső információ hordozó – > - vezérlő

49 Elemzési osztályok megkeresése Azonosítjuk, –Az üzleti modell vagy a használati esetek leírásaiban aláhúzzuk a főneveket –Elemzési mintákat keresünk és azokat alkalmazzuk a konkrét példára –Ez csak az > és a > típusú osztályokra működik és csak egy megoldási lehetőség elnevezzük –Ha nem lehet neki jó nevet adni, akkor talán nem is létezik és néhány mondattal leírjuk az elemzési osztályokat.

50 > osztályok A rendszer és környezete közötti adatcseréért felelősek, gyakorlatilag valamilyen protokollt valósítanak meg. Típusok: –Felhasználói felület osztályai - rendszer és ember –Kommunikációs osztályok - rendszer és rendszer –Eszközök reprezentánsai - rendszer és külső eszköz (pl.: érzékelő)

51 Speciális protokoll - felhasználói felület Minden használati eset - szereplő párhoz van legalább egy Képernyő vázlatot érdemes csinálni hozzá Nem részletes tervezés, csak a fő funkciók látszódjanak (ami kell a folyamatok lefutásához) Az elemzés során a > osztály feladatára kell koncentrálni és nem a hogyanra

52 > osztályok Információ-tárolás és kezelés Alapfogalmak, amivel a rendszer foglalkozik Az objektumok általában passzívak (nem kezdeményeznek) és perzisztensek (a példányaik tárolásra kerülnek) Nézzük a fogalomszótárt az entitások keresésekor Példa: Tanfolyam > Ugyfel > TanfolyamiIdopont >

53 > osztályok A rendszer viselkedését koordinálják Egyes használati esetekhez felesleges - ha nagyon egyszerű manipulációról van szó, akkor a boundary és az entity osztályok ezt önállóan elvégezhetik Általában azonban egy vagy több vezérlő osztály tartozik egy használati esethez –tranzakció-kezelés –erőforrás-kiosztás –hibakezelés

54 > osztályok A vezérlő osztályok hatékonyan választják el az interfészeket és az entitásokat  jobb változás-tűrés, újrafelhasználhatóság Vannak olyan feladat, amely nem lehet egyetlen entitás példány feladat sem, ezért ott a vezérlő osztályok létrehozása szükséges (példányok darabszámának meghatározása) Példa JelentkezesVezerles >

55 Viselkedés elosztása az osztályok között Vegyük a használati eset leírását és formalizáljuk valamelyik interakciós diagrammal (szekvencia vagy együttműködési) Minden használati esethez legalább egy diagram, de pontosabb, ha folyamatonként egy diagram Használjuk a korábban megtalált elemzési osztályokat

56 Viselkedés szétosztása az osztályok között – Kölcsönhatás (interakciós) diagramok Az objektumok együttműködésének a formáját írják le egy adott funkció megvalósítása érdekében Hasonló információk különböző megjelenítési formái: –szekvencia diagram (sequence diagram): az üzenetek explicit sorrendjét fejezi ki –együttműködési diagram (collaboration diagram): az objektumok közötti kapcsolatok leírása Az üzeneteket műveletek implementálják, dolgozzák fel

57 Szekvencia diagram (sequence diagram) Az adott folyamat egy konkrét végrehajtását írja le az objektumok közötti kommunikáción keresztül Azt a célt szolgálják, hogy megértsük az objektumok együttműködésének módját, a rendszer működését Minden használati esethez tartoznia kell legalább egy forgatókönyvnek, hiszen minden folyamatnak legalább egy módon le kell zajlani

58 Szekvencia diagram Az objektumokat (nem osztályokat) függőleges vonalak reprezentálják A vonal akkor kezdődik, amikor az objektum létrejön és akkor fejeződik be, amikor az objektum megszűnik Az események, üzenetek vízszintes címkézett nyilak az objektumok között Az idő fentről lefelé halad

59 Hívó kagyló felemelése Hívott Telefonvonal 1 tárcsázása 8 tárcsázása 9 tárcsázása tárcsahang csöngetési hang csöngetési hang vége kagyló felemelése tárcsahang vége csöngetés vége csöngetés Idő Példa - hívjuk fel a tudakozót

60 Szekvencia diagram Alapvetően egy lefutás érzékletes ábrázolására lehet használni. Nem az algoritmusok ábrázolására szolgál, hiszen nincs benne igazi elágazás. (Erre a célra az aktivitás diagram használható) Jól ábrázolhatóak a tesztelés esetei a segítségével Meg lehet érteni egy komponens vagy egy kész rendszer adott működését (napló/log állomány  szekvencia diagram)

61 Szekvencia diagram Időpont megjelölés: –Jelezni lehet azt az időpontot, amikor egy üzenet elindul vagy megérkezik –Az időpontot jelölő szimbólumokat időzítési feltételekben lehet használni –(A szabvány szerint az üzenetnek lehet rövid nevet adni és ezt lehet meghivatkozni az időzítésre vonatkozó megszorításokban, például msg.sendTime(), msg.receiveTime() stb... )

62 Hívó a : kagyló felemelése Telefonvonal c : 1 tárcsázása b : tárcsahang {b.sendTime() - a.receiveTime() < 1 sec} {c.sendTime() - b.receiveTime() < 10 sec} Szekvencia diagram - Időzítés Időzítési feltétel

63 Együttműködési diagram (collaboration diagram) Az üzenetek áramlásának egy másfajta ábrázolása, bár a kifejező képessége nem különbözik a szekvencia diagramtól, az UML egyre inkább hangsúlyozza a szerepét Objektumokat és kapcsolatokat tartalmaz. Ezek: –vagy a művelet előtt is léteztek –vagy a művelet során keletkeznek esetleg szűnnek meg Ha sok objektum kevés üzenettel kommunikál, akkor áttekinthetőbb lehet, mint a szekvencia diagram

64 Együttműködési diagram elemei I. Az együttműködésben objektumok vesznek részt Objektum speciális előfordulási formái a diagramon: –Multiple instance Egy-több kapcsolat több oldalán álló objektumokat jelképezi –Active object Az objektum saját szállal rendelkezik és önállóan képes a működésre Az objektumba írható szöveg: „objektum neve” / „minősítő szerepkör” : „minősítő” [‘.’ „minősítő”]*

65 Együttműködési diagram elemei II. Üzenetek: címkézett vonal, a szöveghez rendelt nyíl jelzi az üzenet irányát több üzenet is tartozhat ugyanahhoz a kapcsolathoz A nyilak alakja fontos jelentéssel bír (UML 1.3): –Eljárás hívás, beágyazott hívás –Egyszerű szekvencia, általában aszinkron –Aszinkron végrehajtás –Eljárás visszatérése

66 Hívó Telefonvonal Hívott 5: 9 tárcsázása 1: kagyló felemelése 3: 1 tárcsázása 6: 8 tárcsázása 9: kagyló felemelése 2: tárcsahang 4: tárcsahang vége 7: csöngetési hang 10: csöngetési hang vége 8: csöngetés 11: csöngetés vége Együttműködési diagram

67 Egyéb elemek az üzenet-címkén Sorszám (sequence number) - az üzenetek egymásutániságát hivatott jelezni. Az egymásba ágyazott eljáráshívásokat a ponttal elválasztott sorszámok jelölik. –[2.1.4] a [2.1] üzenet által hívott eljárás része, a [2.1.3] üzenet után következik –a párhuzamos szálakat betűvel jelöljük. [1.2a] és [1.2b] párhuzamosan (konkurrensen) hajtódik végre

68 Együttműködési diagram Egyéb elemek az üzenet-címkén Sorszám –az iterációt *-gal jelöljük (*[feltétel]). Jelentése: ugyanolyan formájú üzenet többször megy el –feltétel is megfogalmazható ( [feltétel]) Az üzeneteknek lehet paraméterlistája A visszatérési érték a speciális üzenet neve

69 Együttműködési diagram Egyéb elemek az üzenet-címkén ### Az egymástól vesszővel elválasztott sorszámok listája ([sorszám, sorszám]) azt jelzi, hogy párhuzamos végrehajtás esetén az üzenet mely üzenetek után következhet. (Szálak szinkronizálása)

70 Hívó Telefonvonal Hívott 5*[i:=9..8]: tárcsáz(i) 1: kagyló felemelése 3: 1 tárcsázása 7: kagyló felemelése 2: tárcsahang 4: tárcsahang vége 6a: csöngetési hang 8a: csöngetési hang vége 6b: csöngetés 8b: csöngetés vége Együttműködési diagram

71 Példa - Tanfolyami jelentkezés : Jelentkezõ : DlgLogin : Ugyfel : Frm Jelentkezes : TanfolyamUML : TanfolyamUML : Tanfolyami Regisztracio : Jelentkezes Vezerles Beír "név", "jelszó" Megnyomja "OK" Kiválaszt "UML" Kiválaszt " " Jóváhagy Megjelenít "Regisztráció" Keres ügyfelet ügyfél-keresés Megjelenít TanfolyamLista IdõpontLista Létrehoz Tanfolyam-lista megjelenítése Idõpont lista megjelenítése Van szabad hely?

72 Műveletek Tevékenység, amelyet az osztály végre tud hajtani. Művelet megvalósítása a metódus (módszer). Egy osztály minden konkrét objektuma azonos műveletekkel rendelkezik. Minden művelet implicit argumentumként "ismeri" az objektumát, el tudja érni annak tulajdonságait és műveleteit. UML szintaktika: –láthatóság név(paraméterek):típus {jellemzők} –paraméterek :- {in,out,inout} név:típus=alapértelmezett

73 Műveletek csoportosítása Lekérdezés (query): mindössze értékeket kér le –nem változtatja a megfigyelhető állapotot (observable state) –tetszőleges sorrendben végrehajthatók Módosító (modifier): –Végrehajtása után van olyan művelet, amelynek a végrehajtása nem ugyan azzal az eredménnyel jár, mint előtte. Ez tehát a megfigyelhető állapotot módosítja. Ezek végrehajtási sorrendje nem közömbös és ha tranzakció kezelésre kerül a sor, akkor ezekre kell figyelni. Elérő (accessor): tulajdonságértékek eléréséhez használt lekérdező műveletek (getNeve():String, isMarried():Boolean) Beállító (mutator): tulajdonságértékek beállításához (setNeve(n:String))

74 Láthatóság –+(public) nyilvános –- (private) saját –#(protected) védett –Az implementation és a protected is nyelvfüggő módon értelmezett Jellemzőként is megadható, pl.: {public}. Nyelvfüggő módon értelmezik, azonban a nyilvános felelősségek a teljes alkalmazásból elérhetők, ha az osztály is elérhető

75 Elemzési osztályok felelősségei Szolgáltatások felfedezése: –Az interakciós diagramok üzeneteiből. Vizsgáljuk meg az üzeneteket, és döntsük el, hogy a címzettnek van-e már olyan szolgáltatása, ami ehhez az üzenethez kell. –Nem-funkcionális követelményeket figyelembe kell venni! (Bővítsük a leírást a nem-funkcionális követelményben előírtaknak megfelelően, vagy definiáljunk új szolgáltatást, ami segíti a kielégítését.) Dokumentálás: –Rövid név –Rövid leírás: mit csinál az objektum a szolgáltatás végrehajtása érdekében, és mit ad vissza

76 Példa - Tanfolyami jelentkezés : Jelentkezõ : DlgLogin : Ugyfel : Frm Jelentkezes : TanfolyamUML : TanfolyamUML : TanfolyamiIdopont Regisztracio : Regisztracio : Jelentkezes Vezerles Beír "név", "jelszó" Megnyomja "OK" Kiválaszt "UML" Kiválaszt " " Jóváhagy megjelenít( ) "Regisztráció" ugyfelKereses("név", "jelszó") megjelenít( ) tanfolyamLista( ) idopontLista( ) letrehoz( ) kiirTanfolyamLista( ) kiirIdopontLista( ) Van ilyen ügyfél vanSzabadhely( )

77 Példa – Tanfolyam osztály tanfolyamLista –Visszaadja az összes tanfolyam listáját idopontLista –Visszaadja az adott tanfolyamhoz tartozó időpontok listáját Tanfolyam tanfolyamLista() idopontLista() >

78 Példa - Tanfolyami jelentkezés : Jelentkezõ : Dlg Login : Ugyfel : Frm Jelentkezes : Tanfolyam UML : Tanfolyam UML : TanfolyamiIdopont : Jelentkezes Vezerles 1: "Regisztráció" 2: megjelenít( ) 3: Beír "név", "jelszó" 4: Megnyomja "OK" 5: ugyfelKereses("név", "jelszó") 6: megjelenít( ) 7: tanfolyamLista( ) 8: kiirTanfolyamLista( ) 9: Kiválaszt "UML" 10: idopontLista( ) 11: kiirIdopontLista( ) 12: Kiválaszt " " 13: vanSzabadhely( ) 14: Jóváhagy Regisztracio : Regisztracio 15: letrehoz( )

79 Használati esetek elemzése / Tulajdonságok és kapcsolatok leírása Tulajdonságok (attribútumok): információkat tárolnak –Az értékük az, ami fontos, azaz objektum egy tulajdonságát tartalmazzák valamilyen szempontból –Az objektum kizárólagos tulajdonában vannak (azaz nem hivatkozik rájuk más objektum) –Get/set műveletek és egyszerű átalakítások végezhetők rajtuk, nincs valódi viselkedésük A tulajdonság neve mindig főnév és a tulajdonság által hordozott információtartalomra utal –Rövid leírás: csak abban az esetben hagyható el, ha a tulajdonság neve minden kétséget kizár A tulajdonság típusa: egyszerű (egyediséggel nem rendelkező) adattípus az elemzés során (összeg  cím)

80 Tulajdonságok Az UML nyelvtana: láthatóság név: típus = kezdetiÉrték {jellemzők} –a tulajdonság név elnevezi a szempontot, –a tulajdonság típusa megadja a lehetséges értékeket (típusértékhalmaz). –a kezdeti érték az objektum készítésekor beállítandó értéket jelenti. –a jellemzők (spec. megszorítások) speciális tulajdonságokat mutatnak (pl. frozen) –a tulajdonság értéke megadja, hogy az objektum milyen az adott szempontból Tanfolyam - tematika: string - megnevezes: string - idotartam: integer > a Tanfolyam osztály objektumainak van tematikája, az objektum meg tudja mondani a tematikáját, illetve az beállítható, megvalósítás: az objektumnak van egy tematika mezője.

81 Tulajdonságok A tulajdonságok tekinthetők kicsi, egyszerű és korlátozott funkcionalitású osztályokként. Az objektumot egyedi módon azonosító objektum- azonosítót (OID) nem szabad tulajdonságként felvenni, mivel az a megvalósításhoz kapcsolódik. Az osztály és a tulajdonság nem áll messze egymástól Az osztály szintű tulajdonságot aláhúzással jelöli az UML (A Rose-ban $ jel jelöli)

82 Példa - Tanfolyam Ugyfel - nev : string - lakcim : cim - felhasznaloiNev : string - jelszo : kodoltString + ugyfelKereses() > TanfolyamiIdopont - kezdet : date - veg : date - hely : string + vanSzabadhely() > Tanfolyam - megnevezes : string - idotartam : integer - tematika : string + tanfolyamLista() + idopontLista() >

83 Használati esetek elemzése / Osztályok közötti kapcsolatok Az osztályok szolgáltatásaikat rendszerint csak más osztályokkal együttműködve tudják biztosítani - kapcsolatnak kell lenni közöttük Formák: –Egy objektum lehet globális, és akkor a rendszer bármely osztálya küldhet üzenetet neki –Egy objektumot paraméterként át lehet adni és így egy objektum tud üzenetet küldeni a paraméterként kapott objektumnak –Egy objektumnak állandó kapcsolata lehet, egy másikkal, amelyiknek üzenetet küldhet – kapcsolat (asszociáció) Nem az elemzés során kell dönteni, hogy valóban kapcsolat (asszociáció) lesz-e, de itt azt használjuk!

84 Kapcsolatok leírása Térjünk vissza a Használati esetek elemzése / Elemzési osztályok felelősségei lépésben definiált kölcsönhatás (interakciós) diagramokhoz Ha két objektum között üzenettovábbítás van, az azt jelzi, hogy az osztályaik között kapcsolatnak kell lennie. Az együttműködési diagram még kifejezőbb

85 Kapcsolatok (association) Különböző osztályok objektumai közötti kapcsolat absztrakciója –Asszociáció (association): osztályok között –Kapcsolatpéldány (link): objektumok között, a kapcsolat egy konkrét előfordulása, példánya, két konkrét objektumpéldány, akik a jelzett kapcsolatban állnak Általában kétoldalú (bináris: magasabb fokú kapcsolatok általában felbonthatók binárisokra, bár ekkor részben elveszíti a mondanivalóját) A kapcsolat nagyon sok szabály és megkötés kifejezésére alkalmas, de mindenre nem  OCL

86 Kapcsolatok (association) Név adható neki, de nem kötelező Nevet akkor kötelező adni egy kapcsolatnak, ha ugyanazon osztályok között több kapcsolat is él Az kapcsolatok végeit szerepkörnek nevezzük: ahogyan az adott osztályt a vele kapcsolatban lévő osztály látja –Egyes vélemények szerint ez pongyola megfogalmazás, a típust és az osztályt el kellene választani egymástól –Hasonló a szerepe mint a tulajdonságnak (pl: láthatóság)

87 Példa CégSzemély Alkalmazás munkaadómunkavállaló Szerepkör Név

88 Többszörösség (multiplicitás, multiplicity, számosság) Azt határozza meg, hogy egy osztály egy példányához hány példány tartozhat a kapcsolat másik végénél szereplő osztályból Egészekből (intervallumokból) álló listával adjuk meg –* : sok (nem meghatározott, 0 vagy több) –0..1 : opcionális –1+ : sok, de legalább egy {ordered} az elemek rendezettek és a sorrend jelentéssel bír

89 Példa CégSzemély Alkalmazás munkaadómunkavállaló ** CsúcspontPoligon 1 0..n 1 {ordered}

90 Osztálynak önmagával való kapcsolata (self-association) Személy házasság +feleség +férj 0..1 hierarchia +főnök +beosztott 0..1 * Főnök > Beosztott > 0..n n Személy Felület megvalósítása Szerepkör

91 Kapcsolóosztály (association class) CégSzemély **** +munkavállaló+munkaadó Alkalmazás fizetés : double Részleg 1*1* Kapcsolóosztály: ha a kapcsolatnak a végobjektumokon kívül más tulajdonságai is vannak… A kapcsolat tulajdonságai Kapcsolat vagy tulajdonság? Ha a típusa azonosítható objektum, akkor kapcsolat!

92 Minősítő (qualifier) Számla teljesítés dátuma fizetési határidõ Számlatétel sorszám : int megnevezés ár*11* Számla teljesítés dátuma fizetési határidõ Számlatétel megnevezés ár 1 sorszám : int 11 1

93 Termék 1 1 érvényességKezdete: Date 1 Ár eladásiÁr érvényességVége Termék Ár eladásiÁr érvényességKezdete érvényességVége* 1 * 1 Minősítő (qualifier)

94 Aggregáció (aggregation) “Rész-egész” kapcsolat A részek élettartama az egész élettartamától függ Kompozíció (composition): nem változtatható a beágyazás Viták: –Coad: szervezet és hivatalnokai közötti viszony aggregáció –Rumbaugh: nem az –Probléma van tehát az aggregáció tényének megállapításával –Kifejezőbbé teszi az osztály szerkezetet, amely így jobban visszaadja az üzleti modellt

95 Aggregáció és összetétel (composition) Csúcspont Poligon 1 Jellemzők szín felület 1 {ordered} Aggregáció: a csúcspontok közösek lehetnek más alakzatokéival Összetétel: a jellemzők kizárólag csak az adott poligonpéldányhoz tartoznak

96 Aggregáció (aggregation) Az aggregáció a kapcsolatok különleges változata. –antiszimmetrikus viszony. Pl.: egy Szoba része lehet egy adott Lakásnak, de a viszony megfordítása soha nem lehet igaz. –Néha tranzitív, pl.: egy Lakás Szobájának Ajtaja egyben a Lakás Ajtaja is. –az egész bizonyos tulajdonság-értékeit fel kell ajánlani (propagation) a részeknek, –az egész bizonyos műveleteit továbbítani kell (delegation) a részek felé. Az aggregáció egyik legfontosabb jellemzője a törlés (lebontás) továbbítása.

97 (Kompozíció) Összetétel Összetétel esetén az objektum adott része csak egyetlen "egész" objektumhoz tartozhat, illetve a rész az egésszel "együtt él és hal", azaz a rész élettartama az egészhez kötődik Itt értünk vissza a tulajdonságokhoz, hiszen az összetétel érték szerint tartalmazás Mindkét változat irányított körmentes gráfot feszít ki az osztályok közti aggregációk segítségével

98 Példa - Tanfolyam Regisztracio + letrehoz() > Tanfolyam - megnevezes : string - idotartam : integer - tematika : string + tanfolyamLista() + idopontLista() > Ugyfel - nev : string - lakcim : cim - felhasznaloiNev : string - jelszo : kodoltString + ugyfelKereses() > DlgLogin + megjelenít() > FrmJelentkezes + megjelenít() + kiirTanfolyamLista() + kiirIdopontLista() > JelentkezesVezerles > TanfolyamiIdopont - kezdet : date - veg : date - hely : string + vanSzabadhely() > 1 * 1 * ****

99 Példa - Tanfolyam Regisztracio + letrehoz() > Ugyfel - nev : string - lakcim : cim - felhasznaloiNev : string - jelszo : kodoltString + ugyfelKereses() > Tanfolyam - megnevezes : string - idotartam : integer - tematika : string + tanfolyamLista() + idopontLista() > TanfolyamiIdopont - kezdet : date - veg : date - hely : string + vanSzabadhely() > * 1 * 1 **** Oktato - nev : string - felhasznaloiNev : string - jelszo : kodoltString > ** Kepzettseg 1 * Tartas ** * 1

100 Bejárhatóság (navigability) A kapcsolat bejárhatóságának iránya –Megadja, hogy mely irányból mely irányba lehet eljutni a kapcsolat segítségével –Az alapos elemzés során lehet felderíteni, de ez nagyban függ a követelményektől –A kapcsolat végére rajzolt nyíl jelzi a bejárható irányokat A bejárhatóság pontos felderítése lehetővé tenné az objektum orientált adatbázis kezelők használatát és az adott feladatnak leginkább megfelelő adatbázis kialakítását –Bővebben az adatbázisok tervezésénél lesz róla szó...

101 Használati eset elemzése Az osztály által használt/használható elemzési módszerek azonosítása Az elemzési módszerekhez tartozó egyéb információk megadása Például a Tanfolyam osztály perzisztens: –Várható objektum-szám: –Méret: 1 M –Elérési gyakoriság: Létrehozás/törlés: 20 / negyedév Módosítás: 5 / hónap Lekérdezés: 300 / nap

102 Elemzési osztályok egységesítése Az elemzési osztály neve: –fejezze ki azt a szerepet, amit az adott osztály a rendszerben játszik –legyen egyedi, szinonimák sem megengedettek Vonjuk össze: –a hasonló viselkedésű, azonos szerepű osztályokat –azokat az entitásokat ( > osztályokat), amelyeknek azonosak a tulajdonságaik, még ha a viselkedésük különböző is (a viselkedést is fésüljük össze) Az osztályok módosításakor módosítsuk a kapcsolódó használati esetek leírását és a folyamatokat (együttműködési diagram)

103 A felépítmény finomítása

104 A felépítmény finomítása - Cél Az elemzési tevékenységek leképezése tervezési tevékenységekké –Az elemzési elemeknek megfelelő tervezési elemek azonosítása –Az elemzési módszereknek megfelelő tervezési módszerek azonosítása A felépítmény teljességének és konzisztenciájának biztosítása –Az aktuális iterációban azonosított, új tervezési elemek integrálása a már korábban létező tervezési elemekhez –A meglévő összetevők és tervezési elemek újrafelhasználásának maximalizálása a tervezés lehető legkorábbi szakaszában A rendszer futás idejű és telepítési felépítményének meghatározása A tervezés és a megvalósítás közötti átmenetet lehetővé tevő megvalósítási modell szervezése

105 A felépítmény finomítása Kapcsolódó tevékenységek: Tervezési módszerek azonosítása –az elemzési módszerek megfeleltetése tervezési módszereknek, a megvalósítási környezet figyelembe vételével Tervezési elemek azonosítása –az elemzési modell elemei alapján a tervezési modell elemeinek meghatározása Létező tervezési elemek egyesítése –a meghatározott tervezési elemek egységesítése, –a modell szerkezetének szükség esetén történő átalakítása –az újrafelhasználhatóság lehetőségeinek felderítése

106 A felépítmény finomítása A futás idejű felépítmény leírása –a párhuzamosság kezelésének és a folyamatok működésének a leírása Műveletek és feladatok elosztása –Ezt a lépést elosztott rendszerek fejlesztése esetén kell elvégezni. A felépítmény szemlézése –a megtervezett felépítmény ellenőrzése, –a talált hibák kijavítása

107 Tervezési módszerek azonosítása Tervezési módszerek, modellezési konvenció kialakítása a tervezéshez Tervezési minták meghatározása

108 Modellezési konvenció Egységes látásmód kialakítása –Ehhez ki kell alakítani a modell alapvető részegységeit –Meg kell határozni azokat az UML profilokat, amelyek használatára a tervezés során sor kerül –Ha különleges területről van szó, akkor saját profil kialakítására van szükség –Meg kell határozni a születendő dokumentumok típusát, mert az is befolyásolhatja a modell pontos szerkezetét A tervező kezének részleges megkötése –A rendszer egységes képet mutasson –A tervezőnek csak a felépítménynek megfelelő lehetőségek közül kelljen választania!!! (A hatékony tervezés alapja)

109 UML profil Az UML szabványos eszköze a különleges területek modellezésének lefedésére –Nem definiál új UML elemeket, hanem a szabványos kiterjesztési mechanizmusok segítségével a UML elemek értelmezésére egy szabályt ad az adott témakörben –A sztereotípusok, modell elemek jellemzői és szabályok (OCL) segítségével leszabja az UML-t az adott területre, így a modell a profil ismeretében mindenkinek egyértelmű –Az UML 1.3-as szabványa 2 profil-t tartalmaz, a Unified Process a szoftverfejlesztés a Business Modeling pedig az üzleti folyamatok UML ábrázolását teszi lehetővé

110 Tervezési minták Az OO szemlélet lehetővé teszi a problémák és a megoldások elvont és általános ábrázolását Az újrafelhasználás: –Kód szintű, ha a megírt programot használjuk fel újra. Ez nem túl hatékony, mert gyakran a megírt komponenshez keresünk rendszert. (Gombhoz a kabátot) –A tervezés újra használata, tipikus problémák adott környezetben működő megoldásának újbóli felhasználása.  Tervezési minták –Elemzés eredményeinek újra felhasználása esetén tipikus követelményekre egy típus rendszert határoz meg, amely minden kérdésre kitér az adott problémakörben.  Elemzési minták

111 Tervezési elemek azonosítása Elemzési osztályok: olyan fogalmi dolgok, amelyek valamilyen viselkedéssel rendelkeznek. A tervezés során tervezési osztályokká és alrendszerekké válnak –tervezési döntések –megvalósítási környezet Alrendszer: speciális csomag, amelynek jól meghatározott felületei vannak, egyébként zárt –Csomag: különösebb szemantika nélküli fogalom az UML-ben a modell-elemek csoportosítására –Alrendszer: a csomag-fogalom egy különleges használata, amelynek osztályszerű tulajdonságai, viselkedése van

112 Tervezési elemek azonosítása Tervezési osztályok: az egyszerű elemzési osztályokból egy-egy tervezési osztály keletkezik –Tipikusan az > osztályok ilyenek Tervezési alrendszerek: az összetett elemzési osztályokból keletkezik. Az elemzési osztály által definiált viselkedés túl összetett ahhoz, hogy egyetlen osztály szolgáltatásaival megvalósítható legyen. –Megvalósításban: szoftver-összetevők –Példa: hitel- vagy kockázatértékelő mechanizmusok (pénzügy) szabályalapú kiértékelési mechanizmusok (kereskedelem) biztonsági szolgáltatások (minden rendszer)

113 Létező tervezési elemek egyesítése Az újrafelhasználás lehetőségeinek feltérképezése Meglévő összetevők és adatbázisok visszafejtése (reverse-engineer) A Tervezési Modell átstrukturálása

114 A futás idejű felépítmény leírása A párhuzamosságra vonatkozó követelmények elemzése, a folyamatok azonosítása, a folyamatok közötti adatcserélő módszerek azonosítása, a folyamatok közötti időzítést végző erőforrások lefoglalása, a folyamatok életciklusának azonosítása a modell elemeinek szétosztása a folyamatok között.

115 Műveletek és feladatok elosztása Annak meghatározása, hogy az egyes funkciók hogyan oszlanak meg a csomópontok között A hálózati konfiguráció megtervezése A folyamatok elosztása a csomópontokba

116 A felépítmény szemlézése Olyan eddig fel nem tárt kockázatok felderítése, amelyek hatással lehetnek az ütemezésre vagy a költségvetésre. A felépítmény tervezése során elkövetett hibák felfedezése –ezek azok a hibák, amelyek a legnagyobb költséggel javíthatóak Felderíteni a követelmények és a tervezett felépítmény közötti ellentmondásokat. –Ilyenek lehetnek például a hiányzó, vagy nem valószerű követelmények vagy a túl bonyolult felépítmény. A felépítmény néhány jellemző tulajdonságának becslése: –teljesítmény, megbízhatóság, módosíthatóság, robosztusság, biztonság…

117 A viselkedés elemzése

118 A viselkedés elemzése - Cél A használati esetekben leírt viselkedés elemzése alapján meg kell határozni azokat az elemeket, amelyek a tervezés alapjául szolgálnak

119 A viselkedés elemzése Kapcsolódó tevékenységek: Használati esetek elemzése –a használati esetek elemezése és a használati eset megvalósítások elkészítése Tervezési elemek azonosítása –újabb tervezési elemek azonosítása A tervezés szemlézése –az eddig elkészített tervezési modell elemeinek ellenőrzése.

120 A tervezés szemlézése Annak igazolása, hogy a tervezett modell megfelel a rendszer követelményeinek és jó alapként szolgál a megvalósításhoz Annak ellenőrzése, hogy a tervezési modell megfelel-e a tervezési útmutató alapelveinek

121 Összetevők tervezése

122 Összetevők tervezése - Cél A tervezési elemek meghatározásának finomítása azon részletek kidolgozásával, amelyek az adott tervezési elem elvárt viselkedésének megvalósításához szükségesek A használati esetek megvalósításainak finomítása és módosítása az újonnan megtalált tervezési elemek alapján A fokozatosan kialakuló tervezési modell szemlézése A tervezési elemek alapján az összetevők megvalósítása A megvalósított összetevők tesztelése annak ellenőrzésére, hogy megfelelnek-e az egységteszt követelményeknek

123 Összetevők tervezése Kapcsolódó tevékenységek: Használati esetek tervezése –a használati esetek leírásának kiegészítése az megvalósításhoz szükséges információkkal. Osztályok tervezése –a tervezési osztályok tulajdonságainak meghatározása Részrendszerek tervezése –a tervezési részrendszerek kialakítása és részletes dokumentálása A tervezés szemlézése –az eddig elkészített tervezési modell elemeinek ellenőrzése

124 Használati esetek tervezése A kölcsönhatások alapján a használati eset megvalósítások finomítása A tervezési osztályok műveleteivel kapcsolatos követelmények finomítása A részrendszerek és azok felületeinek műveleteihez kapcsolódó követelmények finomítása

125 Részrendszerek tervezése Az alrendszer szolgáltatásait a felületei biztosítják a külvilágnak –Egy felület-osztály eljárásaival: ennek végrehajtásában közreműködhetnek más osztályok –A felületet megvalósító alrendszer felületével Az alrendszeren belüli elemek együttműködését szekvencia illetve tevékenység diagrammal dokumentáljuk Az alrendszer belső szerkezetét ábrázoljuk egy vagy több osztálydiagrammal (az osztályok tervezése a következő lépés)

126 Részrendszerek tervezése Dokumentáljuk az alrendszerek közti függéseket: –Amikor az alrendszerünk egy eleme egy másik alrendszerben lévő elemet használ, akkor függ attól a másiktól Fizetési Ütemezés Számlázás

127 Osztályok tervezése - lépések Tervezési osztályok kialakítása típusonként, perzisztens osztályok azonosítása Részletes tervezés –Az osztályok láthatóságának meghatározása –Műveletek, eljárások –Állapotok –Tulajdonságok –Függések –Kapcsolatok –Öröklődés –Az osztályhoz kapcsolódó nem-funkcionális követelmények kezelése

128 Osztályok tervezése A lépések nem egymás után következnek, az osztályok specifikációja fokozatosan finomodik A megfelelő tervezési minták alkalmazása A tervezés végén az összes osztálynak közvetlenül megvalósíthatónak kell lennie, tehát a tervezés során használt modell szorosan összefügg a megvalósítási környezettel

129 Osztályok tervezése / > osztályok Az elemzés során egy osztályt definiáltunk minden ablak számára - nagyon magas szint A GUI fejlesztőeszközökben rendszerint létre tudjuk hozni a felhasználói felület osztályait - csak azt kell megtervezni, ami automatikusan nem jön létre A más rendszerekkel kapcsolatot tartó > osztályokat általában alrendszerekként tervezzük, mivel általában összetett viselkedést takarnak. Ha egyszerű adattovábbítás a feladat, akkor lehet tervezési osztály is belőle

130 Boundary  felhasználói felület Az elemzés eredménye egy osztály, amely leírja, hogy az adott felhasználói kölcsönhatásban a rendszernek mit kell tudnia Tanfolyami jelentkezés + Jelentkező adatainak megadása(név, cím, telefonszám, cégnév) + tanfolyam lista megjelenítése(cím, rövid tematika, teljes tematika) + tanfolyam kiválasztása() + időpontok listájának megjelenítése(kezdete, vége, oktatók) + időpont kiválasztása() + regisztráció a kiválasztott időpontra() >

131 Felhasználói felület megvalósítva

132 Felhasználói felület modellje tblTanfolyam > név : String > tematika : Long String > doubleClick() > tlbTanfolyamIdopont > tanfolyam kezdete : Date > tanfolyam vége : Date > oktatók : String > doubleClick() > frmJelentkezo > név : String > cím : Long String > telefonszám : String > cégnév : String > regisztráció() A tervezés során a modellezési konvenciónak a megvalósító környezet fogalmai szerint kell megjeleníteni a szerkezetet. Ezt a felépítmény tervezés szakaszában kell kialakítani!

133 Osztályok tervezése / > osztályok Általában passzívak és perzisztensek Perzisztens: képes az állapotát tárolni valamilyen háttértáron Lehetnek perzisztens és tranziens példányai a perzisztensnek jelölt osztályoknak is Az adatbázis tervezés során kell őket figyelembe venni Perzisztens osztályok nemcsak > osztályokból keletkeznek, hanem például folyamat- vagy tranzakció-vezérlő osztályokból is (nem- funkcionális követelmények)

134 Osztályok tervezése / > osztályok A használati esetek végrehajtásáért felelősek, azt a logikát tartalmazzák, ami nem a > és nem az > osztályokhoz tartozik  alkalmazási logika vagy üzleti logika A tervezésük során figyelembeveendő szempontok: –Bonyolultság: az egyszerű vezérlés megoldható határ- vagy entitás osztályokkal is –Változás valószínűsége: ha kicsi, akkor a vezérlőosztályok bevezetése nem indokolt –Elosztás és hatékonyság: ha elosztott a rendszerünk, akkor rendszerint kellenek vezérlőosztályok –Tranzakció-kezelés: ha a keretrendszerünk nem tartalmazza, akkor szükség van vezérlőosztályra

135 Osztályok tervezése / Láthatóság meghatározása Minden egyes osztályhoz határozzuk meg a láthatóságát: –Nyilvános (public): az osztályt tartalmazó csomagon kívülről is elérhető –Rejtett (private) (esetleg „implementation”): csak az osztályt tartalmazó csomag osztályai hivatkozhatnak rá

136 Osztályok tervezése / Műveletek definiálása Vegyük sorra az elemzési osztályok szolgáltatásait, és mindegyikhez definiáljunk egy műveletet –A szolgáltatás leírása alapján készítsük el a művelet első leírását –Nézzük meg azon használati eset megvalósításokat, amelyekben az osztály részt vesz, így pontosíthatjuk a művelet definícióját, paramétereit, visszatérési értékét, leírását –A használati esetben megfogalmazott nem-funkcionális követelményeket is vegyük figyelembe

137 Osztályok tervezése / Műveletek tervezése A használati eset megvalósításokban megadottakon kívül más műveletekre is szükség lehet: –Létre lehet-e hozni, lehet-e kezdőértékezni az osztály példányát? (Beleértve a más objektumokkal való kapcsolatot is.) –Szükséges e annak ellenőrzése, hogy két objektum azonos e (azaz tulajdonságaik és kapcsolataik megegyeznek-e, elosztott rendszerben nehéz ügy)? –Le kell-e másolni (klónozni) egy objektumot? –Szükség van-e egyéb műveletekre a mechanizmusok megvalósításához? (Például szemétgyűjtési mechanizmus megköveteli, hogy egy objektum törölni tudja az összes egyéb objektumra vonatkozó hivatkozásait)

138 Osztályok tervezése / Műveletek tervezése Minden művelethez meg kell adni: –A művelet neve: rövid, de kifejező név (mit fog a művelet eredményezni) A megvalósítási nyelv nyelvtana szerint –Visszatérési érték típusa –Rövid leírás: néhány mondat a művelet hívójának szemszögéből (nem algoritmus) –Paraméterek: Minden paraméterhez: –Név –Típus –Rövid leírás: a paraméter jelentése, cím vagy érték szerinti, kötelező vagy választható, alapértelmezett értéke, érvényes értékek Kevesebb paraméter  könnyebben használható fel újra, könnyebben érthető ( OO előny! )

139 Osztályok tervezése / Műveletek tervezése Láthatóság: –Nyilvános (public, +): minden más modell-elem hivatkozhat rá –Megvalósítás szerinti (implementation): csak az osztályon belül használható –Védett (protected, #): az osztály, leszármazottai és barátai (friend) hivatkozhatnak rá –Rejtett (private, -): csak az osztályban és az osztály barátaiban (friend) használható Osztály-műveletek –Szükség van néha arra, hogy egy műveletet az osztály összes példányán végrehajtsunk  osztályművelet –Például: hozzunk létre új példányt, adjuk vissza az összes példányt, stb –Jelölés: a művelet aláhúzásával történik, jelenleg a Rose-ban a > sztereotípust használjuk

140 Osztályok tervezése / Műveletek tervezése A művelet algoritmusa (method): hogyan hajtódik végre a művelet (nemcsak mit csinál) –Hogyan kell a műveletet megvalósítani? –Milyen tulajdonságok kellenek és hogyan használja azokat a művelet? –Milyen kapcsolatok kellenek? –Együttműködési diagramok használhatóak a folyamat dokumentálására! –Esetleg tevékenység diagram alkalmazható az algoritmus leírásra.

141 Osztályok tervezése / Állapotok Az osztályok egy részénél a művelet végrehajtása attól függ, hogy az objektum milyen állapotban van Állapotátmenet diagram (State Transition Diagram) vagy állapot diagram (State Diagram) használható a viselkedés ábrázolására –Ha egy művelet végrehajtása után létezik olyan művelet, amely más eredménnyel fut le mint előtte, akkor az adott osztály rendelkezik állapottal, különben honnan tudná, hogy másként kell reagálnia. –Összefüggés az együttműködési diagrammokkal!

142 Állapot-átmenet diagram (state) Az objektumok dinamikus viselkedésének leírására szolgál Az objektumok külső hatások eredményeként változtatják állapotukat, és hatnak környezetükre Egy állapot-diagramot mindig egy osztályhoz készítünk, vagy egy magasabb szintű diagram pontosításaként A legtöbb osztálynak a gyakorlatban nincs állapot- diagramja, mert például egyszerű kisegítő (utility) osztályok

143 Állapot-átmenet diagram Állapot: egy konkrét objektum egy adott időpontban vett tulajdonság-értékei és kapcsolatai együttesen. Az állapot az a nem nulla hosszú időszak, amíg az objektum valamely esemény bekövetkezését várja. Esemény vagy üzenet: egy objektumnak egy másik objektumra történő hatása (egyirányú információ-átvitel)

144 Események elemi dolog nem szakítható meg az információ egyirányú aszinkron átvitele lehetnek paraméterei formátum: eseménynév( paraméter : típus, …)

145 Lezárt Állapotok (state) Egy időtartam, ami alatt az objektum események bekövetkeztére vár Jelölés:

146 Várakozó Aktív Idõ lejárt Csöngetés do: csöngetõ hang Tárcsázás Idő lejárt do: Szaggatott hang Érvénytelen do: sípoló hang Kapcsolás Csöngetés do: csöngetõ hang Foglalt do: foglalt hang Beszélgetés [ 15 mp lejárt ] tárcsáz( n )[ nem teljes a szám tárcsáz( n )[ érvénytelen a szám ] tárcsáz( n )[ érvényes a szám ] / kapcsol [ foglalt a vonal ] [ szabad a vonal ] hívott felveszi / beszélgetés engedélyezése [ 15 mp lejárt ] tárcsáz( n ) hívó leteszi a kagylót / bontja a vonalat felveszi a hallgatót / tárcsahang Tárcsahang do: búgó hang Állapot-átmenet diagram - Példa

147 Megjegyzések a példához Az állapotok “finomíthatók” alállapotokkal. Egy “A” szuperállapotban lévő objektum lehet az “A1”, “A2”, “A3” alállapotok bármelyikében –Példában: “Aktív” szuperállapot, “Tárcsahang”, “Idő lejárt” stb. alállapotok

148 Összetett állapot (composite state) A modellt távoli, nagyvonalú nézőpontból készítjük el először. Egy ilyen diagram több alacsonyabb szintű állapotot kezel egységként. Az alállapotok közötti átmenetek a magasabb elvonatkoztatási szinten nem látszanak, azokkal nem foglalkozunk. Az összetett állapotnak mindig van egy kezdő alállapota (starting substate), és lehet végállapota (terminal state)

149 Tárcsázó Start entry: búgó hang kezdete exit: búgó hang vége Tárcsázás folyamatban entry: number.append(n) Start entry: búgó hang kezdete exit: búgó hang vége Tárcsázás folyamatban entry: number.append(n) tárcsáz( n ) [ number.isValid() ]tárcsáz( n ) VárakozóTárcsázóKapcsoló [ number.isValid() ]hallgató felvétele Példa Kezdőállapot Végállapot

150 Átmenet (transition) Az objektum válasza egy külső eseményre Általában eljáráshívással jár együtt, vagyis valamilyen tevékenység végrehajtásával Az átmenet során az objektum egy másik állapotba kerülhet Két típus: –külső: új állapotba vezet (eljáráshívás vagy történik vagy nem) –belső: eljáráshívás anélkül, hogy az objektum állapota megváltozna

151 Átmenet (transition) Az átmenetet egy esemény váltja ki, ami az objektummal történik Az átmenethez őrfeltétel (guard condition) tartozhat. Az átmenet csak akkor következik be, ha az esemény bekövetkezik ÉS a feltétel igaz. Ha egy címke nélküli átmenethez feltétel tartozik, akkor az átmenet a feltétel igazzá válásakor rögtön megtörténik. A feltétel megfogalmazható OCL segítségével.

152 Átmenet Az átmenethez tartozó eljárás elemi és nem megszakítható Az átmenet szintaxisa: esemény(paraméterlista) [feltétel] ^célobjektum.küldöttEsemény(paraméterlista) /művelet(paraméterlista)

153 BA1 A2 H A1 A2 H C megszakítás újrakezdés Emlékező állapot (history state) Olyan állapot, amely emlékszik arra, hogy melyik alállapotból terminált, és képes arra, hogy az állapotba való újabb belépéskor ugyanabba az alállapotba kerüljön.

154 Műveletek (operations) az átmenethez tartozó tevékenység nem szakítható meg az objektum metódusaként valósítható meg bemeneti tevékenység (entry operation): az állapotba való belépéskor hajtódik végre kimeneti tevékenység (exit operation): az állapot elhagyásakor hajtódik végre

155 Állapot entry: bemeneti akció exit: kimeneti akció do: tevékenység event: művelet Tevékenységek (activities) Olyan, az állapothoz tartozó művelet, aminek a végrehajtásához idő kell Egy esemény megszakíthatja Felfogható pszeudo-átmenetnek, amelyet a do pszeudo-esemény vált ki

156 Osztályok tervezése / Állapotok A markánsan dinamikus viselkedésű osztályokhoz készítünk állapot-diagramot Minden esemény az állapot-diagramon megfeleltethető egy műveletnek –A művelet algoritmusának leírását ki kell egészíteni az állapotra jellemző adatokkal - az egyes állapotokban hogyan kell a műveletnek viselkednie Az állapotokat gyakran tulajdonságok reprezentálják –Az állapot-diagram jó segítség a tulajdonságok megadásához

157 Példa - Tanfolyami időpont Törölve Inicializálás alatt Nyitott do: Jelentkezõ regisztrálása entry: jelentkezõk számának növelése Jelentkezés / jelentkezõk száma=0 Jelentkezés Megtelt [ jelentkezõk száma=15 ] törlés

158 Példa Újraélesztés Törölve Inicializálás alatt Nyitott do: Jelentkezõ regisztrálása exit: jelentkezõk számának növelése Megtelt H Inicializálás alatt Nyitott do: Jelentkezõ regisztrálása entry: jelentkezõk számának növelése Jelentkezés / jelentkezõk száma=1 Jelentkezés Megtelt [ jelentkezõk száma=15 ] H Törlés

159 Osztályok tervezése / Tulajdonságok Minden tulajdonsághoz meg kell adni: –nevét - az implementációs nyelv szabályai szerint –típusát - az implementációs nyelv alaptípusai közül –alapértelmezett vagy kezdeti értékét - ezzel az értékkel kezdőértékezzük a tulajdonságot az objektum létrehozásakor –láthatóságát: public implementation protected private –a perzisztens osztályoknál azt is, hogy a tulajdonság perzisztens (default) vagy tranziens Ellenőrizzük, hogy minden tulajdonságra tényleg szükség van- e

160 Osztályok tervezése / Függőségek meghatározása Minden egyes esetben, amikor két objektum kommunikál, a küldő és a címzett között függőségi kapcsolatot kell használni, ha: –Paraméterként jut el a címzetthez a referencia. Az együttműködési diagramon jelöljük meg, hogy a kapcsolat láthatósága a paraméter –A címzett globális objektum. Az együttműködési diagramon jelöljük meg, hogy globális a kapcsolat –A címzettet a művelet hozza létre és szünteti meg. Az együttműködési diagramon jelöljük meg, hogy lokális a kapcsolat)

161 Osztályok tervezése / Asszociációk, aggregációk Szorosabb kapcsolat, mint a függőség (Az együtt- működési diagramon a láthatóság mező (field)) Ellenőrizni kell az asszociáció irányítottságát. Alapértelmezésben mindkét osztály objektumai látják a másikat. Ahol erre nincs szükség ott egyirányúvá kell tenni az asszociációt Határozzuk meg, hogy az asszociáció valamelyik oldalán rendezettek-e az elemek ({ordered}) Ha egy osztállyal csak az adott osztálynak van kapcsolata, akkor érdemes megfontolni a beágyazását

162 Aggregáció vagy kompozició Rész-egész viszony: aggregáció vagy kompozíció Megosztott aggregáció Cím - város - utca - házszám - irányítószám Személy 11 Cím - város - utca - házszám - irányítószám 1..* Cég 11

163 Aggregáció vagy összetétel (kompozíció) Összetétel: szoros kapcsolat a rész és az egész között, –a rész és az egész élettartama szorosan összetartozik –az egész megszűntével a rész is megszűnik –az egész nem teljes a részek nélkül –ha egyszer egy kapcsolat létrejött, nem változtatható meg –az egész oldal számossága csak 1 lehet Összetétellel modellezhetjük az összetett értékű tulajdonságokat is SzámlaTételSzámla

164 Aggregáció vagy asszociáció Aggregáció csak akkor, –ha tényleg rész-egész kapcsolatról van szó –ha a rész nem értelmes az egész nélkül Asszociáció, ha az osztály a másik oldal nélkül is értelmes, független, önálló létezése van Kétségek esetén asszociációt használjunk!

165 Valósidejű összetevők tervezése

166 Valósidejű kapszula tervezés Kapszula: aktív objektum, amelynek saját vezérlése van. Legtöbbször valami aktív számítástechnikai egységet jelképez –Viselkedés: állapotdiagrammal írható le –Párhuzamos folyamatok/állapotok –Kapszulák egymásba ágyazása –Kapuk (port), protokollok, kapcsolóelemek (connectors)

167 Adatbázis tervezése

168 Adatbázis tervezése - Cél Tervezés során a perzisztens osztályok meghatározása A perzisztens osztályok tárolására megfelelő adatbázis szerkezet meghatározása A teljesítmény elvárásoknak megfelelő mechanizmusok és stratégiák kidolgozása az adatok tárolására és visszakeresésére

169 Adatbázis tervezése Kapcsolódó tevékenységek: Osztályok tervezése –finomítani kell a tervezési osztályokat a perzisztens adatok kezelésére vonatkozó követelmények, jellemzők megadásával és modellbe integrálásával Adatbázis tervezése –a tervezési modell perzisztens adatainak tárolását és visszakeresését reprezentáló adatmodell létrehozása A tervezés szemlézése –az elkészített adatmodell megfelelőségének vizsgálata

170 Adatbázis tervezése A perzisztens tervezési osztályok leképezése adatmodellre A leképezést elősegítő félautomatikus eszközök: Java Hibernate/Persistence Konzisztens és hatékony tárolási szerkezet kialakítása Adatelérés optimalizálása Jelenlegi fejlesztéseknél elsődleges fontosságú, mert az adatbázis hordozza magán az üzleti logika jelentős részét Későbbiekben fontos lenne az adatbázis tervezést minél inkább szétválasztani

171 Elemzés tervezés – Tevékenységek

172 Elemzés – tervezés - Termékek


Letölteni ppt "Rational Unified Process Elemzés - Tervezés. Témáink I. Objektumorientált alapfogalmak II. Elemzés - tervezés munkafolyamat –1. Egy lehetséges felépítmény."

Hasonló előadás


Google Hirdetések