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

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

I. Objektumorientált alapfogalmak

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

Miért népszerű az OO? Paradigma-váltás, szemlélet-váltás Valósághoz közelebbi koncepciók alkalmazásával egyszerűbbé, áttekinthetőbbé és könnyebben módosíthatóvá válik a fejlesztés. Hadfield: Az objektumorientált nyelvek elérhetővé teszik az előnyöket, de azokat nem használják ki automatikusan.

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 analízisét és tervezését is egyaránt az objektumorientált modellezés fogalomvilága segítségével végezzük el.

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

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

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.

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.

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: Osztály neve Személy születési dátum születési hely életkor() Attribútumok Műveletek

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

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

Á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

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

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

Öröklés EgydimenziósÁbra 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 Ős Leszármazott

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

Öröklés Jármű SzélHajtottaJármű MotorosJármű VíziJármű SzárazföldiJármű hajtóerõ terep Kamion Vitorláshajó Hajó {overlapping} {overlapping}

Öröklés 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

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

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

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

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

OO mint absztrakciós eszköz

Sztereotípiák (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

Strukturált és OO módszer

Folyamat felbontása

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

II. Elemzés - tervezés munkafolyamat

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

Munkafolyamat

Munkafolyamat

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

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

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

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

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 mechanizmusok meghatározása Az alrendszerek magas szintű definiálá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

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

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.

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

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ípia é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

Felépítmény elemzés - Függőség Két elem között függőség van, ha az egyik definíciójának 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

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 Analízis 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

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

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.

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

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 definiált 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 Az attribútumait és kapcsolatait Adjuk meg az egyéb jellemzőit Egységesítsük az elemzési osztályokat

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 (interakció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.

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.

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ő

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.

<<boundary>> osztályok A rendszer és környezete közötti kommunikációé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.: szenzor)

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

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

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

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

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

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

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

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

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

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)

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

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

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

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ő”]*

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

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

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

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

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)

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

Példa - Tanfolyami jelentkezés : DlgLogin : Ugyfel : Frm Jelentkezes : Tanfolyam UML : Tanfolyam UML19990301 : Tanfolyami Regisztracio : Jelentkezes Vezerles Beír "név", "jelszó" Megnyomja "OK" Kiválaszt "UML" Kiválaszt "1999.03.01" 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/

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}

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

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ő

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

Példa - Tanfolyami jelentkezés : DlgLogin : Ugyfel : Frm Jelentkezes : Tanfolyam UML : Tanfolyam UML19990301 : TanfolyamiIdopont Regisztracio : Regisztracio : Jelentkezes Vezerles Beír "név", "jelszó" Megnyomja "OK" Kiválaszt "UML" Kiválaszt "1999.03.01" 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/

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?

Példa - Tanfolyami jelentkezés : Dlg Login : Ugyfel : Frm Jelentkezes : Tanfolyam UML : Tanfolyam UML19990301 : 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 "1999.03.01" 13: vanSzabadhely( ) 14: Jóváhagy Regisztracio : Regisztracio 15: letrehoz( )

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.

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

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)

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

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.

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

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, az asszociáció egy konkrét előfordulása, példánya, két konkrét objektumpéldány, akik a jelzett kapcsolatban állnak Általában bináris (a 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

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)

Példa Cég Személy Alkalmazás munkaadó munkavállaló Asszociáció neve Szerepkör Szerepkör

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 az asszociációban szereplő másik 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

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

Osztálynak önmagával való kapcsolata (self-association) <<Interface>> <<Interface>> Fonö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 Megvalósít Szerepkör

Kapcsolóosztály (association class) Cég Személy * +munkavállaló +munkaadó Alkalmazás fizetés : double Részleg 1 Asszociációs osztály Asszociáció attribútumai Asszociáció vagy attribútum?

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

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

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

Aggregáció és összetétel (composition) Poligon Kompozíció 1 1 {ordered} Jellemzők szín felület Csúcspont

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.

(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

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 *

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

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

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: 100-1000 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

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

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

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

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

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

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

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

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)

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é

Tervezési minták Az OO szemlélet lehetővé teszi a problémák és a megoldások absztrakt é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. (Gomb kontra kabát effektus) 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

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-definiált interfészei 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 speciális használata, amelynek osztályszerű tulajdonságai, viselkedése van

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

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

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 szinkronizálást végző erőforrások allokálása, a folyamatok életciklusának azonosítása a modell elemeinek szétosztása a folyamatok között.

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

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…

A viselkedés elemzése

A viselkedés elemzése

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

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.

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

Összetevők tervezése

Összetevők tervezése

Ö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?

Ö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

Használati esetek tervezése Az interakciók 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űveleihez kapcsolódó követelmények finomítása

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 feü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).

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!

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

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

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

Boundary  felhasználói felület Az elemzés eredménye egy osztály, amely leírja, hogy mit kell tudnia az adott felhasználói interakcióban a rendszernek <<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()

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

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ó()

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

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

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á

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

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.

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

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!

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.

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!

Á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

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

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, …)

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

Á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

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

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

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() ]

Á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

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

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

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

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

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 esemény: művelet

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

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

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

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

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)

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

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ó

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

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!

Valósidejű komponensek tervezése

Valósidejű összetevők tervezése

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)

Adatbázis tervezése

Adatbázis tervezése

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

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

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 struktúra 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 szeparálni

Elemzés - tervezés - tevékenységek

Elemzés tervezés – Tevékenységek és szereplők

Elemzés - tervezés - termékek

Elemzés – tervezés - Termékek