Rational Unified Process Elemzés - Tervezés

Az előadások a következő témára: "Rational Unified Process Elemzés - Tervezés"— Előadás másolata:

1 Rational Unified Process Elemzés - Tervezés
Bemutatkozás!! Tanfolyam témái: UML Rational Unified Process Rational Rose Kapott anyagok Vég Csaba: Alkalmazásfejlesztés a Unified Modeling Language szabványos jelöléseivel Slide-show

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: Név Személy születési dátum születési hely életkor() Tulajdonságok Műveletek

11 Osztályozás, 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 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 - sorköteles 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 Vonal Körív Poligon szín színváltás() kirajzolás()
törlés() Vonal végpontok Körív sugár kezdõszög végszög Poligon töréspontok 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} {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 Elipszis Téglalap

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 Elipszis Téglalap Poligon

22 Absztrakt osztály Nincsenek példányai Alakzat Vonal szín mozgatás()
kirajzolás() törlés() Vonal végpontok 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.: <<system>>) Láthatóság Tesztelés egysége is lehet Adattipusok global <<rendszer>> Alkalmazas Reteg <<modell>> UzletiReteg Nagyméretű rendszerek esetén nélkülözhetetlen

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 <<modell>> 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 (<<use case realization>>) a tervezési modellben (név ugyanaz.) <<trace>> Jelentkezés tanfolyamra Jelentkezés tanfolyamra megvalósítása

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 Minden elemzési osztálynak általában több szolgáltatása is van. Ha csak egyet találunk, akkor az gyanús (túl egyszerű osztály). Ha nagyon sok van, tucatnyi, akkor valószínűleg szét kell darabolni az osztályt több osztályra. (Kerüljük a „hősöket”!) Az objektum létrehozását és törlését csak speciális esetekben jelenítsük meg külön, amikor valamilyen speciális viselkedés szükséges a létrehozáskor, vagy törléskor (nem lehet automatikusan törölni, ha bizonyos kapcsolatok léteznek).

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 A használati eset leírása a felhasználónak készül Lehetőségek a használati eset leírásának kiegészítése Nem egészítjük ki, hanem az interakciós diagramokat elég érthetőnek tekintjük Módosítjuk a használati eset eredeti leírását Új leírást készítünk, ami tartalmazza az összes részletet. Ha a használati eset belső és külső képe nagyon eltér, akkor ez a járható út.

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: <<boundary>> - külső kapcsolat <<entity>> - entitás, belső információ hordozó <<control>> - 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 <<entity>> és a <<control>> 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 <<boundary>> 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 <<boundary>> osztály feladatára kell koncentrálni és nem a hogyanra

52 <<entity>> 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 <<entity>> Ugyfel TanfolyamiIdopont

53 <<control>> 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 <<control>> 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 Vezérlő osztályok biztosította viselkedés: Környezet-független (nem változik, amikor a környezet változik) A vezérlési logikát (események sorrendjét) és a tranzakciókat definiálja Csak kissé változik, ha az entitások belső szerkezete vagy viselkedése megváltozik Egyszerre több entitással is foglalkozhat, azokat ilyenkor koordinálni kell Nem mindig ugyanúgy működik, hanem a használati esetben definiált alternatíváknak megfelelően JelentkezesVezerles <<control>>

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

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 Szekvencia diagram - Időzítés
Hívó Telefonvonal {b.sendTime() - a.receiveTime() < 1 sec} a : kagyló felemelése b : tárcsahang {c.sendTime() - b.receiveTime() < 10 sec} c : 1 tárcsázása 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 Együttműködési diagram
5: 9 tárcsázása 1: kagyló felemelése 3: 1 tárcsázása 6: 8 tárcsázása Hívó Telefonvonal 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 9: kagyló felemelése Hívott

67 Együttműködési diagram
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 Együttműködési diagram
5*[i:=9..8]: tárcsáz(i) 1: kagyló felemelése 3: 1 tárcsázása Hívó Telefonvonal 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 7: kagyló felemelése Hívott

71 Példa - Tanfolyami jelentkezés
: DlgLogin : Ugyfel : Frm Jelentkezes : Tanfolyam UML : Tanfolyam UML : 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 TanfolyamLista IdõpontLista Létrehoz Tanfolyam-lista megjelenítése Idõpont lista megjelenítése Van szabad hely? Logical View/Design Model/Use Case Realizations/Jelentkezés tanfolyamra/Jelentkezés tanfolyamra/

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 Műveletek koncepcionális szint: viselkedés lényegi elemei, specifikációs szint: publikus módszerek, implementációs szint: az osztály metódus. Jellemzők: <<signal>> {sequential} {guarded} {concurrent}

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 Láthatóság Jellemzőként is megadható, pl.: {public}.
+ (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 Példa nem-funkcionálisra: - 5 másodpercen belül meg kell jelennie - simán leírjuk, hogy majd az algoritmus tervezésekor figyeljünk rá - nem lehetnek duplikált ügyfelek - csinálunk egy új szolgáltatást, ami mindig ellenőrzi, hogy van-e már ilyen ügyfél

76 Példa - Tanfolyami jelentkezés
: DlgLogin : Ugyfel : Frm Jelentkezes : Tanfolyam UML : Tanfolyam UML : 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ó") tanfolyamLista( ) idopontLista( ) letrehoz( ) kiirTanfolyamLista( ) kiirIdopontLista( ) Van ilyen ügyfél vanSzabadhely( ) Logical View/Design Model/Use Case Realizations/Jelentkezés tanfolyamra/Jelentkezés tanfolyamra/

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() <<entity>> Problémák: Egy konkrét tanfolyamról beszélünk, hogyan lehet tanfolyam listát kérni az „UML” tanfolyamtól? Osztály-függvény Külön osztály kell a tanfolyamok nyilvántartására Én ezt design-ra hagynám! Mi az az adott tanfolyam? - az az objektum, amit megszólítottunk Általában probléma a dátum. A valaha volt összes tanfolyamra, összes időpontra kiváncsi vagyok, vagy csak a jövőbeniekre?

78 Példa - Tanfolyami jelentkezés
: 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) Másik oldalról: Ha az információnak komplex viselkedése van, ha az információn két vagy több osztály osztozik, esetleg referenciaként közlekedik két vagy több osztály között, akkor ÖNÁLLÓ osztályként kell modellezni.

80 <<entity>>
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 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. Tanfolyam - tematika: string - megnevezes: string - idotartam: integer <<entity>>

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 Tanfolyam - megnevezes : string
- idotartam : integer - tematika : string + tanfolyamLista() + idopontLista() <<entity>> TanfolyamiIdopont - kezdet : date - veg : date - hely : string + vanSzabadhely() <<entity>> Ugyfel - nev : string - lakcim : cim - felhasznaloiNev : string - jelszo : kodoltString + ugyfelKereses() <<entity>> Megjegyzések: Cim KodoltString

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! A háromféle lehetőség közül majd a tervezés során választunk. Ebben a fázisban még nincs elegendő információnk a döntéshez. Az elemzés során asszociációkat és aggregációkat használunk annak jelzésére, hogy az objektumok között üzenetek mennek.

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ég Személy Alkalmazás munkaadó munkavállaló Név Szerepkör

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ég Személy {ordered} Csúcspont Poligon 0..n 0..n 1 1 *
Alkalmazás munkaadó munkavállaló * {ordered} Csúcspont Poligon 0..n 0..n 1 1

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

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

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

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

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)
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 Poligon 1 1 {ordered} Jellemzők szín felület Csúcspont

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 FrmJelentkezes Tanfolyam - megnevezes : string
Regisztracio + letrehoz() <<entity>> Tanfolyam - megnevezes : string - idotartam : integer - tematika : string + tanfolyamLista() + idopontLista() Ugyfel - nev : string - lakcim : cim - felhasznaloiNev : string - jelszo : kodoltString + ugyfelKereses() DlgLogin + megjelenít() <<boundary>> FrmJelentkezes + kiirTanfolyamLista() + kiirIdopontLista() JelentkezesVezerles <<control>> TanfolyamiIdopont - kezdet : date - veg : date - hely : string + vanSzabadhely() 1 *

99 Példa - Tanfolyam Tanfolyam - megnevezes : string Kepzettseg Oktato
Regisztracio + letrehoz() <<entity>> 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 Oktato Kepzettseg Tartas

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 Minden egyes szemponthoz adjunk meg annyi jellemző értéket, amennyi csak lehetséges. Használhatunk intervallumokat, ahol az kell, vagy nagy a bizonytalanság. Az elemzés alatt ezek a számok általában erősen spekulatívak

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 (<<entity>> 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) Cél: Minden elemzési osztály egyetlen jól-definiált fogalmat takarjon anélkül, hogy a szolgáltatások átfednék egymást. Ne maradjon felfedezetlen osztály

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 <<entity>> 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) Tervezési osztályokat célszerű rögtön valamilyen tervezési csomagba besorolni %%% Utánanézni: Hol jönnek létre a tervezési csomagok? Egyébként Guideline: Design Package Tervezési alrendszerek: Az alrendszer szolgáltatásait igénybe-vevő kliensek jól definiált interfészeken keresztül kommunikálnak a tervezési alrendszerrel, és a belső megvalósítás nem érdekli őket. Egy vagy több elemzési osztályból keletkezik egy tervezési alrendszer

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 Másképp megfogalmazott, illetve további kérdések: Ki használja, rögzíti, törli az információkat? Kinek van szüksége valamely funkcionalitásra? A vállalaton belül hol fogják ezt a rendszert használni? Ki fogja a rendszert karbantartani? Milyen más rendszerektől kap a rendszerünk adatot, milyen más rendszernek kell adatot szolgáltatni?

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) Minden, az alrendszer által megvalósított interfész művelethez tartoznia kell egy vagy több szekvencia-diagramnak, amely az alrendszer belső működését dokumentálja Milyen osztályok vesznek részt az interfész megvalósításában Belül minek kell történnie az alrendszer funkcionalitásának biztosítására Milyen osztályok küldenek üzenetet az alrendszeren kívülre Az interfész megvalósítását leíró diagram rajzolásakor valószínűleg újabb osztályokat / alrendszereket találunk, amelyek a kívánt viselkedés implementálásához szükségesek A tevékenység nagyon hasonló a „Használati eset elemzéséhez”, csak használati eset helyett műveletekkel foglalkozunk. Vigyázzunk arra, hogy különböző alrendszerekben ne hozzuk létre ugyanazt az osztályt. Időről időre térjünk vissza az Architektúrális tervezéshez és vizsgáljuk meg az alrendszereink határait (általában a duplikátumok arra utalnak, hogy rossz volt az eredeti határ).

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 Elvileg: A függés kifejezhető az alrendszerek közötti függés ábrázolásával A függést kifejezhetjük az az interfészek közti függéssel is A tervezőnek teljes szabadsága marad az alrendszer belső szerkezetének tervezésekor, mindaddig, amíg a külső viselkedést (amit az interfész ír le) biztosítja. De nem fejezhetjük ki az elemek közötti kapcsolatokkal Rose-ban nem lehet csomagos interfészt rajzolni!

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 / <<Boundary>> 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ó <<Boundary>> 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 <<boundary>> 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
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! <<tablewindow>> tblTanfolyam <<column>> név : String <<column>> tematika : Long String <<event>> doubleClick() <<tablewindow>> frmJelentkezo tlbTanfolyamIdopont <<datafield>> név : String <<column>> tanfolyam kezdete : Date <<datafield>> cím : Long String <<column>> tanfolyam vége : Date <<datafield>> telefonszám : String <<column>> oktatók : String <<datafield>> cégnév : String <<event>> doubleClick() <<button>> regisztráció()

133 Osztályok tervezése / <<Entity>> 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 <<Entity>> osztályokból keletkeznek, hanem például folyamat- vagy tranzakció-vezérlő osztályokból is (nem-funkcionális követelmények) A perzisztens elemzési mechanizmust megvalósító tervezési mechanizmus lehet: In-memory tárolás Flash card Bináris állomány DBMS Attól függően, hogy az osztálynak mire van szüksége

134 Osztályok tervezése / <<Control>> osztályok
A használati esetek végrehajtásáért felelősek, azt a logikát tartalmazzák, ami nem a <<Boundary>> és nem az <<Entity>> 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) A szimpla get/set műveleteket majd a generátorok létrehozzák, nem kell a modellt bonyolítani velük.

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 <<class>> sztereotípust használjuk Láthatóságból mindig legszigorúbbat válasszuk, ami még elfogadható, nézzük meg a szekvencia diagramot!

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 Állapotok (state) Egy időtartam, ami alatt az objektum események bekövetkeztére vár Jelölés: Lezárt Lezárt

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

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 Példa Végállapot Kezdőállapot Várakozó Tárcsázó Kapcsoló
[ number.isValid() ] hallgató felvétele Végállapot Kezdőállapot Tárcsázó 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() ]

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 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. B A1 A2 H C megszakítás újrakezdés

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 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 Állapot entry: bemeneti akció exit: kimeneti akció do: tevékenység event: művelet

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 Jelentkezés Nyitott Nyitott Inicializálás alatt
Jelentkezés / jelentkezõk száma=1 do: Jelentkezõ regisztrálása do: Jelentkezõ regisztrálása entry: jelentkezõk számának növelése exit: jelentkezõk számának növelése [ jelentkezõk száma=15 ] Megtelt Megtelt H H Újraélesztés Törlés Törölve

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 Attribútumok szükségessége: Már az elemzés korai fázisában definiáljuk őket, így könnyen előfordulhat, hogy mellékhatásként bennmaradnak a modellben, holott valójában nincs már rájuk szükség. Az extra attribútumok objektumok ezreiben vagy millióiban jelentősen növelhetik a tárigényét és ronthatják a hatékonyságot

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 Beágyazás előnyei: gyorsabb üzenetküldés egyszerűbb modell Hátrányai: Statikusan allokált hely a beágyazott osztályoknak akkor is, ha épp nincs példányuk A beágyazott osztálynak nincs önálló identitása, csak a beágyazott osztályon keresztül érhető el

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 1 Személy Cím - város - utca - házszám - irányítószám 1..* Cég 1 Megosztott aggregációról beszélünk, ha az „egész” oldal multiplicitása több egynél. Ilyenkor az „egész” lebontása nem jelenti a „rész” lebontását is. Megosztott aggregációt használunk, ha a kapcsolat nagyon szoros a két osztály között, de ugyanaz az objektum két különböző aggregációban is részt vehet. Példa: Kisvállalkozás, ami a lakáson működik. Ilyenkor ténylegesen ugyanaz a cím van mind a Személy mind a Cég objektumban. Ha a cég megszűnik, a személy címe még mindig megmarad. Ha a cég nagy lesz és elköltözik, akkor megszűnik megosztott lenni az aggregáció

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 Attribútum vagy kompozíció Kompozíció, ha Önálló, független létezése is van a tulajdonságnak, sok más objektum is hivatkozhat rá Sok osztálynak vannak ilyen tulajdonságai A tulajdonság maga is összetett, bonyolult SzámlaTétel Szá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