1 / 172

Rational Unified Process Elemzés - Tervezés

Rational Unified Process Elemzés - Tervezés. Témáink. I. Objektumorientált alapfogalmak II. Elemzés - tervezés munkafolyamat 1. Egy lehetséges felépítmény 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.

johnda
Download Presentation

Rational Unified Process Elemzés - Tervezés

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Rational Unified ProcessElemzés - Tervezés

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

  3. I. Objektumorientált alapfogalmak

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

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

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

  7. Kovács János 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:

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

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

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

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

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

  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. Alakzat szín színváltás() kirajzolás() törlés() Vonal Poligon Körív végpontok sugár töréspontok kezdõszög kirajzolás() végszög kirajzolás() törlés() törlés() kirajzolás() törlés() Öröklés Ős Leszármazottak

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

  18. Jármű hajtóerõ terep hajtóerõ terep SzélHajtottaJármű MotorosJármű VíziJármű SzárazföldiJármű Vitorláshajó Hajó Kamion Leszármaztatás – diszkriminátor, különleges megszorítások {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. Alakzat forgatás() Kör Elipszis Téglalap forgatás() forgatás() forgatás() 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)

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

  22. Alakzat szín mozgatás() kirajzolás() törlés() Vonal végpontok kirajzolás() törlés() Absztrakt osztály • Nincsenek példányai 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. <<modell>> <<modell>> <<rendszer>> UzletiReteg Alkalmazas Adattipusok Reteg global 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

  40. <<modell>> <<modell>> UzletiReteg Alkalmazas Reteg 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

  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

  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. 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) Egy megközelítés az elemzés elvégzésére  • A megrajzolt kölcsönhatás (interakciós) diagramok segítségével derítsük fel az elemzési osztályok felelősségeit, biztosítva ezzel, hogy csak azt oldjuk meg, ami valóban a feladatunk.

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

  48. Elemzési osztályok • Az elemzési osztályok a rendszer fogalmi modelljét alkotják. „Dolgok, amivel a rendszernek foglalkozni kell.” • Az UML-ben osztályok reprezentálják, amelyek sztereotípiája: • <<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ő)

More Related