Rational Unified Process Elemzés - Tervezés

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