Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

UML-alapú fejlesztés. Software Engineering – szoftverfejlesztési folyamat Software Engineering értelmezése –Az a folyamat, mely eredményekénk létrehozunk.

Hasonló előadás


Az előadások a következő témára: "UML-alapú fejlesztés. Software Engineering – szoftverfejlesztési folyamat Software Engineering értelmezése –Az a folyamat, mely eredményekénk létrehozunk."— Előadás másolata:

1 UML-alapú fejlesztés

2 Software Engineering – szoftverfejlesztési folyamat Software Engineering értelmezése –Az a folyamat, mely eredményekénk létrehozunk egy adott feladatot megvalósító szoftver rendszert. –Tevékenységek, technológia, módszerek, eszközök… –Számítógép alapú rendszert hozunk létre.

3 Szoftverfejlesztési folyamat Rendszerfejlesztési folyamat („rendszer”…) –System Engineering –Általános értelemben vett rendszer fejlesztés. Szoftverfejlesztési folyamat (szoftver…) –Software Engineering –Szoftver alkalmazásokat, eszközöket ad a SE által definiált feladatok megoldására. –A szoftver rendszer (alkalmazás) létrehozására koncentrál.

4 Rendszerfejlesztés Rendszerfejlesztés alapkérdései –Általános értelemben vett rendszer fejlesztés –Rendszerfejlesztés lehet: Business Process Engineering ha vállalat (működésének) (át)szervezésével foglalkozunk Product Engineering ha egy termék előállítása a cél pl.: mobil telefon, repülőgép vezérlő rsz. Szoftverfejlesztési folyamat

5 Szoftverfejlesztés értelmezése –Az a folyamat, amelynek eredményekénk létrehozunk egy adott feladatot megvalósító szoftverrendszert, számítógép alapú rendszert hozunk létre. Szoftverfejlesztés lépései –Fázisok Szoftverfejlesztési modellek, módszertanok: –struktúrált (vízesés modell, Boehm-féle spirálmodell, V modell stb.) –objektumorientált (OMT, OOA/OOD, Bocch2, RUP)

6 Vízesés modell

7 A fejlesztés életciklusa System engineering – Rendszerfejlesztés –Business process eng. – Üzleti modellezés üzleti folyamatok tervezése, szervezése az üzleti környezet modellezése –Product eng. – Termék modellezés termékek tervezés termék modellezése, annak használata Requirements – Követelménykezelés Analysis – Elemzés Design – Tervezés Implementation – Implementáció Testing – Tesztelés, Telepítés Karbantartás, Rendszerkövetés, Továbbfejl. Software eng. Rendszerfejlesztés – System Eng.

8 Módszertan Modellező nyelv Eljárások

9 Tanácsok: milyen lépések szükségesek a rendszer elkészítése során és azokat milyen sorrendben kell végrehajtani. Az egyes lépéseket milyen szerepkört betöltő embereknek kell elvégezni. Milyen termékek születnek az egyes lépések során és hol kerülnek felhasználásra.

10 Szerepkörök és tevékenységek A szerepkör (worker) egyfajta viselkedést ír le. A szerepkört betöltő személy vagy személyek felelősek meghatározott termékek (artifact) előállításáért. Minden munkatárs meghatározott tevékenység- sort végez a termékek előállítása érdekében. Minden valóságos személy többféle munkatársi szerepkört is betölthet a projekt folyamán, többféle felelőssége lehet.

11 Szerepkörök és tevékenységek a RUP-ban Munkafolyamat részletek Megadja, hogy az adott feladat során milyen lépéseket kell végrehajtani, ki a felelős az adott feladat végrehajtásáért és milyen termékeket kell a lépések során előállítani.

12 Termékek (Artifact) A projekt során előállított, használt dolgok. Például: –Dokumentum –Modell (pl.: használati eset modell) –Modell-elem (pl.: használati eset) –Riportok: modellekből, modell-elemekből előállított dokumentumok. A termékek tevékenységek során állnak elő, és útmutatók (guideline), sablonok (template) segítik a készítésüket: –Pl.: hogyan találjuk meg és dokumentáljuk a használati eseteket? –Nem termékhez kapcsolódó útmutatók: például hogyan szervezzünk workshopot.

13 Modellező nyelv Jelölésrendszer (általában grafikus), amellyel leírjuk a rendszert, rendszertervet a fejlesztés során. A kommunikáció alapja: –megrendelő és fejlesztő csoport között, –fejlesztő csoport tagjai között. Fontos, hogy a modellező nyelv alkalmas legyen mind a valóság, mind rendszer belső szerkezetének ábrázolására: –üzleti modelltől, telepítési modellig.

14 Rational Unified Process Szoftverfejlesztési módszertan, közvetlen elődje az Objectory (Jacobson). Booch, Rumbaugh és Jacobson munkájának eredménye. Világszerte elterjedt fejlesztési módszertan. Nagyon sok előző módszertanból merít és mindazt egyesíti („nem spanyol viasz”). NAGY fejlesztési módszertan  testre kell szabni. A módszertan, ill. a hozzá fejlesztett eszközök a teljes fejlesztési ciklust támogatják: –üzleti modellezés, követelmények elemzése, elemzés, tervezés, tesztelés, stb.

15 A RUP szerkezete tartalom (mit kell végrehajtani?) idő (mikor, milyen sorrendben?)

16 RUP módszertan A Rational Unified Process egy UML-t, mint modellező nyelvet használó szoftver fejlesztési módszertan: –UML modellező nyelv jelölésrendszerét használja. –Eljárásaiban megadja, hogy milyen lépéseket kell végrehajtani, milyen sorrendben. –A feladatok elvégzéséért ki a felelős. –Milyen termékeket kell előállítani a feladat végrehajtása során. –Eszközökkel támogatja a fejlesztés egyes szakaszait. –Tool-mentorok segítik az eszközök használatát. –Sablonokat, útmutatókat ad az egyes feladatokhoz. +

17 Az UML modellező nyelv Unified Modelling Language - Egységes Modellező Nyelv Objektumorientált elemzés, tervezés és üzleti modellezés eszköze: –Az üzleti modellezés esetén a valóság folyamatait írja le. –Analízis (elemzés) során a megoldandó feladat leírása. –Tervezés során a megoldást (implementálandó rendszert) írja le. Szabványos (Object Management Group - OMG) –1997. november óta Alapvetően grafikus nyelv. Modellező nyelv, nem módszertan.

18 UML diagramok 1.Use Case (használati eset) diagram 2.Tevékenységi/Aktivitási (Activity) diagram 3.Eseménykövetési/Szekvencia (Sequence) diagram 4.Együttműködési/Kollaborációs (Collaboration) diagram 5.Osztály (Class) diagram 6.Objektum (Object) diagram 7.Állapot-átmeneti (Statechart) diagram 8.Komponens (Component) diagram 9.Telepítési (Deployment) diagram

19 A RUP szerkezete tartalom (mit kell végrehajtani?) idő (mikor, milyen sorrendben?)

20 Munkafolyamatok

21 A RUP munkafolyamatai Üzleti modellezés Követelmény-elemzés Elemzés-tervezés Implementáció Tesztelés Telepítés Konfiguráció és változás-kezelés Projektvezetés Környezet kialakítása Mérnöki munkafolyamatok Támogató munkafo- lyamatok

22 Mérnöki munkafolyamatok A fejlesztési munka konkrét feladatai: Üzleti modellezés (Business Modeling) –Cél megérteni annak a szervezetnek a felépítését, folyamatait, amely támogatására az alkalmazást fejlesztjük. Követelmény-elemzés (Requirements) –Cél meghatározni azokat a feladatokat, amelyeket a rendszernek meg kell oldani (scope) és a megrendelőkkel együttműködve egy egységes képet kell kialakítani a fejlesztendő rendszerről. Elemzés-tervezés (Analysis & design) –Cél a követelményelemzés során meghatározott elvárásoknak megfelelő, robosztus rendszer tervezése.

23 Mérnöki munkafolyamatok Implementáció (Implementation) –Cél a terv alapján a rendszert alkotó komponensek implementálása, egységtesztjeinek elvégzése és integrálása. Tesztelés (Test) –Cél annak ellenőrzése, hogy az implementált rendszer megfelel-e az elvárásoknak, és hogy valamennyi követelmény implementálva lett-e. Telepítés (Deployment) –Cél a kész alkalmazást elérhetővé tenni a felhasználó számára.

24 Támogató munkafolyamatok Azok a feladatok, amelyek a fejlesztés során folyamatosan segítik a fejlesztők munkáját: Konfiguráció és változás-kezelés –Cél a fejlesztés során előálló termékek verzióinak kezelése. Projektvezetés –Cél irányelvek megadása és a projekt ellenőrzésével és irányításával kapcsolatos feladatok elvégzése. Környezet kialakítása –Cél a szoftverfejlesztési környezet (módszertan, eszközök) kialakításával kapcsolatos feladatok ellátása.

25 RUP szerkezete Munkafolyamatok A munkafolyamatot egy „folyamatábra (activity) segítségével mutatja be. Ez segít a feladat típusa, és a fejlesztés aktuális fázisa szerint meghatározni a további feladatokat.

26 RUP szerkezete Munkafolyamat részletek Megadja, hogy az adott feladat során milyen lépéseket kell végrehajtani, ki a felelős az adott feladat végrehajtásáért és milyen termékeket kell a lépések során előállítani.

27 Szerepkörök és tevékenységek A szerepkör (worker) egyfajta viselkedést ír le. A szerepkört betöltő személy vagy személyek felelősek meghatározott termékek (artifact) előállításáért. Minden munkatárs meghatározott tevékenység- sort végez a termékek előállítása érdekében. Minden valóságos személy többféle munkatársi szerepkört is betölthet a projekt folyamán, többféle felelőssége lehet.

28 Termékek (Artifact) A projekt során előállított, használt dolgok. Például: –Dokumentum –Modell (pl.: használati eset modell) –Modell-elem (pl.: használati eset) –Riportok: modellekből, modell-elemekből előállított dokumentumok. A termékek tevékenységek során állnak elő, és útmutatók (guideline), sablonok (template) segítik a készítésüket: –Pl.: hogyan találjuk meg és dokumentáljuk a használati eseteket? –Nem termékhez kapcsolódó útmutatók: például hogyan szervezzünk workshopot.

29 Fázisok és iterációk

30 Fázisok A Rational Unified Process a szoftverfejlesztés életciklusát négy egymást követő fázisra bontja: –Előkészítés (Inception, Kiindulás, Elindulás). –Kidolgozás (Elaboration). –Megvalósítás (Construction). –Átadás (Transition).

31 Előkészítés fázis A rendszer határainak meghúzása Az üzleti lehetőségek tervezése és előkészítése Egy lehetséges architektúra meghatározása A projekt során alkalmazott fejlesztési környezet előkészítése Mérföldkő: A követelmények rögzítése

32 Kidolgozás fázis Az architektúra meghatározása és alkalmazhatóságának igazolása A Projekt Vízió finomítása A megvalósítás fázis részletes iterációs tervének elkészítése A fejlesztési folyamatok finomítása és a fejlesztési környezet kialakítása a megvalósítási feladatok támogatására Az architektúra finomítása és újrafelhasználható komponensek kiválasztása Mérföldkő: Szoftver architektúra rögzítése

33 Megvalósítás fázis Erőforrás kezelés, ellenőrzés és optimalizálás Teljes komponens fejlesztés és tesztelés az elfogadási kritériumok alapján A termék verziójának értékelése az átvételi kritériumok alapján Mérföldkő: Kibocsátás béta tesztelésre

34 Átadás fázis A telepítési terv végrehajtása A végfelhasználókat támogató anyagok elkészítése Az átadott szoftver tesztelése a felhasználó telephelyén A termék verziójának elkészítése A felhasználók visszajelzéseinek összegyűjtése A visszajelzések alapján a rendszer végső beállításainak elvégzése A rendszert elérhetővé tenni a felhasználók számára Mérföldkő: Termék kibocsátása

35 A RUP szerkezete Egy-egy fázis elkészítése minden munkafolyamatot érint, amelyek a különböző fázisokban különböző intenzitásúak, és erőforrás-igényűek. Más megközelítésben: –A fázisok iterációkra bonthatók. –Minden egyes iteráció egy mini fejlesztés: kezdődik üzleti modellezéssel, követelményelemzés, elemzés, tervezés, implementáció, tesztelés, befejeződik telepítéssel.

36 Fázisok Minden fázis végén jól-definiált mérföldkövek vannak: kritikus döntéseket kell hozni: –Értékelni az eddigi eredményeket, –Dönteni a folytatásról.

37 Iterációk A RUP szerint a fejlesztés egyes fázisai tovább bonthatóak iterációkra. Az iteráció egy olyan fejlesztési ciklus, amely során minden alapvető munkafolyamatot egyszer elvégzünk. Vízesés Iteratív - “sok kis vízesés”

38 Iterációk Az iterációk során egyre több termék áll elő, és a termékek érettsége egyre nő.

39 Fázisok és iterációk Az aktuális feladat dönti el, hogy hány iterációra van szükség a feladat elvégzéséhez. Az iterációk tervezése kritikus feladat a projekt tervezése során.

40 V. A fejlesztés menete a RUP ajánlásával

41 A RUP szerkezete tartalom (mit kell végrehajtani?) idő (mikor, milyen sorrendben?)

42 V.1. Üzleti modellezés – Business Modeling

43 Üzleti modellezés Megérteni annak a szervezetnek a felépítését, viselkedését, amely számára a rendszert ki akarjuk fejleszteni Feltárni a szervezet aktuális problémáit és meghatározni a javítás lehetőségeit Biztosítani, hogy az ügyfelek, végfelhasználók és fejlesztők egységes képet kapjanak az adott szervezetről A szervezetet támogató rendszerrel szemben felmerülő követelmények felderítése

44 Üzleti modellezés Azt a környezetet írja le, amelyikben a rendszer működik, vagy amelyikben a rendszer működni fog. A rendszernek az üzleti környezetben, a szakterületi környezeten belüli helyét határozza meg. Más néven szakterületi (domén) modellezés. Értelmezhető mind a jelenlegi, mind a tervezett rendszer üzleti környezetére.

45 Üzleti modellezés

46 Az üzleti folyamatok állapotának felderítése (Assess Business Status) –A fejlesztett rendszer által támogatott szervezet (cél szervezet) állapotának felderítése.

47 Üzleti modellezés Az aktuális üzleti folyamatok leírása (Describe Current Business) –Feltárni a cél szervezet folyamatait és szerkezetét. –Nem cél a szervezet részletes leírása. –Addig a szintig kell az elemzéseket elvégezni, amíg képesek leszünk kategorizálni a szervezet folyamatait és kiválasztani azokat a részeit, amelyekre a projekt hátralevő részét alapozni fogjuk. –Üzleti szereplők, használati esetek, entitások és workerek azonosítása.

48 Üzleti modellezés Az üzleti folyamatok azonosítása (Identify Business Processes)

49 Üzleti modellezés - tevékenységek

50 Üzleti modellezés - termékek

51 Üzleti folyamatok leírása UML segítségével Csomag elem, csomag diagramok: –Összetett tevékenységek, folyamatok strukturálása. –Logikai rendszerezés. –Átlátható struktúra kialakítása. Business use case, business use case diagram: –Üzleti folyamatok leírása.

52 Üzleti folyamatok leírása UML segítségével Business aktorok: –A megbízó szervezettel a működése során kapcsolatba kerülő személyek. Business workerek: –A megbízó szervezet alkalmazottjai. Aktivitási diagram: –Az üzleti folyamatok működésének részletezése, lépéseinek leírása.

53 A szakterület folyamatai (üzleti folyamat diagram) (Diplomáztatás esettanulmány)

54 Szakterületi modell (Diplomáztatás esettanulmány)

55 Követelmény (elemzés)

56 Követelményanalízis/kezelés –a szoftverfejlesztési folyamat első lépcsőfoka –már konkrét specifikáció, amely alapját képezi valamennyi szoftverfejlesztési tevékenységeknek, a teljes szoftverfejlesztési folyamatnak –végrehajtásához a következő tevékenységek javasoltak: problémafeltárás problémaértékelés és megoldás keresés/alternatív megoldások felállítása modellezés specifikáció áttekintés, felülvizsgálat, ismertetés

57 Követelményanalízis/kezelés –a probléma információs, funkcionális és a viselkedési doménére!!! koncentrál – követelmények összegyűjtése –követelmények elemzése – konzisztencia, prioritások, köv. típusok –követelmények specifikálása –követelmények validálása –produktuma: szoftver követelményspecifikáció dokumentum

58 Követelményelemzés A megrendelővel (felhasználóval) egyetértésre jutni, hogy pontosan mit kell a szoftverrendszernek tudnia. A fejlesztőknek pontos képet adni a rendszerről. Meghúzni a rendszer határait. Biztosítani az iterációk tervezéséhez szükséges technikai információkat. A rendszerhez a felhasználói igényeknek megfelelő felhasználói interfész meghatározása.

59 Követelményelemzés A tervezett szoftverrendszernek kívülről, a felhasználó szempontjából történő leírását adja meg.

60 Követelményelemzés

61 Követelmény Követelmény: olyan feltétel, képesség, szolgáltatás, melynek teljesítését (vagy az annak való megfelelést) elvárjuk a tervezett alkalmazástól.

62 Követelménymenedzsment A követelmény menedzsment: –folyamatos tevékenység, amely végigkíséri a fejlesztés teljes folyamatát. –Célja a követelmények feltárása, rendszerezése, dokumentálása. –További fontos feladata a követelmények változásának nyomon követése és ezek érvényesítése a fejlesztési folyamatra.

63 Követelmények változásainak nyomon követése A fejlesztés során a megrendelőnek, a felhasználónak újabb elképzelései, igényei merülhetnek fel. A korábban specifikált követelmények tehát a fejlesztés folyamán változhatnak, módosulhatnak. A rendszert fel kell készíteni a követelmények változásának követésére. –A változáskövetés során első lépésben elemezni kell a fejlesztés folyamán jelentkező új igényeket, majd –meg kell vizsgálni az új igények milyen hatással lesznek a már felállított követelményrendszerre. –A vizsgálat eredményének kiértékelése után lehet csak dönteni a változások megvalósíthatóságáról.

64 Követelmények szerepe A követelmények jellegének meghatározása abban nyújt segítséget, hogy eldönthessük: –milyen funkcionalitást, –milyen felületet biztosítson a program a felhasználó felé, –milyen belső funkciókat kell teljesítenie ahhoz, hogy a felhasználó igényeit kielégítse, –és működése közben milyen előírásokat, szabályokat kell alkalmaznia, betartania.

65 Tipikus módszerek: megbeszélés, interjú Gaus&Weinberg által javasolt 3 kérdéscsoport módszer: –szövegkörnyezet független kérdések Ki fogja majd használni az alkalmazást? Ki lesz az alkalmazás felhasználója? Milyen gazdasági előnyökkel jár egy sikeres alkalmazás? Kinek az érdekeit szolgálja a fejlesztés? –a fejlesztés specifikus kérdések Le tudná írni azt a környezetet, amelyben a megoldást alkalmazzák? Létezik bármilyen dolog vagy megszorítás, amely hatással lehet az alkalmazás megvalósítására? –meta-kérdések: amelyek a megbeszélés eredményességére fókuszálnak - A témához kapcsolódó kérdésekkel találkozott? Nem volt sok a feltett kérdések száma? Követelmények feltárását, összegyűjtését segítő technikák

66 Követelmények csoportosítása A követelmények hierarchikus rendszert alkotnak, a rendszer elemei pedig összefüggésben állnak egymással. Az összefüggések lehetnek közvetlen ok- okozati, származási, illetve egyéb logikai kapcsolatok. A követelményrendszer felépítéséhez célszerű a követelményeket típusokba sorolni.

67 A követelmények csoportosítása Felhasználói követelmények Funkcionális és nem funkcionális követelmények Szakterületi követelmények

68 Felhasználói követelmények A felhasználónak a szoftverrendszerrel szembeni igényei, elvárásai felhasználói célok un. felhasználói követelmények formájában fogalmazódnak meg.

69 Felhasználói követelmények Magas szintű, gyakran absztrakt követelmények – a rendszerrel szembeni legfőbb megrendelői elvárások. Ábrázolásukhoz általában diagramokkal kiegészített természetes nyelvű leírásokat használunk. A cél annak definiálása, hogy milyen szolgáltatásokat várunk el a rendszertől, és annak milyen feltételek, megszorítások mellett kell működnie.

70 Felhasználói követelmények Meg tudják adni, le tudják írni a szervezetnek azt a területét/területeit (alrendszer), azt a szervezeti környezetet, amelyikben majd a fejlesztendő szoftveralkalmazás működni fog. Megadják a rendszertől elvárt szolgáltatásokat, és azokat a feltételeket (megszorításokat), amelyeket a rendszer fejlesztése és majdani működése során be kell tartani. Vannak elképzeléseik az alkalmazás használatára, az alkalmazás bemenetére, kimenetekre (pl. listák, bizonylatok formája).

71 Felhasználói követelmények A felhasználói követelmények: –un. magas szintű célok –kategorizálni kell, közöttük prioritási sorrendet kialakítani, majd a felállított fontossági sorrend alapján az igényeknek megfelelően, szükséges mélységben részletesen ki kell fejteni. A követelmények kategorizálásnak és minősítésének számos hatékony módszerei: –A szakirodalom a Software Engineering Institute (SEI) és az ISO által kidolgozott módszereket javasolja alkalmazni. – Az egységesített módszertan a követelmények csoportosítását a FURPS+ modell alapján végzi.

72 Felhasználói követelmények A felhasználói követelmények alapot képeznek: –a szoftverrendszertől elvárt konkrét szolgáltatások (szoftverfunkciók, amiket a szoftver csinál) meghatározására.

73 Követelmények Az alkalmazástól elvárt szolgáltatások, szoftverfunkciók a követelménymodellben: –funkcionális (a rendszer működésére vonatkoznak) és –nem funkcionális követelmények (a működést befolyásoló egyéb követelmények) formájában fogalmazódnak meg.

74 Funkcionális követelmények A rendszer által nyújtandó szolgáltatások ismertetése (hogyan kell reagálnia a rendszernek bizonyos eseményekre, hogyan kell viselkednie egyes szituációkban). A funkcionális követelmények a rendszertől várt funkciókat és/vagy szolgáltatásokat írják le. Már a szoftverrendszer működésére, a tényleges funkcionalitásra vonatkozó leírások.

75 Funkcionális követelmények Funkcionális követelmények: –azokat a követelményeket értjük, amelyek a szoftverrendszert kívülről nézve, a felhasználó szemszögéből írják le.

76 Funkcionális követelmények A funkcionális követelmények: –leírják, hogy a rendszert ért hatásokra, eseményekre a szoftveralkalmazásnak hogyan kell reagálni, –a megfogalmazott feltételek, megadott megszorítások függvényében a rendszernek milyen alternatív végrehajtást kell biztosítani, –a bekövetkezett események hatására milyen más funkciókat kell aktivizálni.

77

78 Nem funkcionális követelmények A rendszer funkcióival és szolgáltatásaival kapcsolatos megszorítások. Például –időbeli korlátozások, szabványok, hardver és szoftverkörnyezeti előírások, teljesítménykövetelmények, stb.

79 Szakterületi követelmények A rendszer szakterületén alkalmazott előírások, megszorítások (számítási előírások, jogszabályok, stb.). A szakterületi követelmények természetesen lehetnek funkcionális és nem funkcionális követelmények.

80 Tesztelés követelmények alapján

81 Szoftverrendszerek tesztelése A szoftver fejlesztés célja: –a specifikációban leírt követelményeket kielégítő szoftver készítése. –Fejlesztés során különböző ellenőrző, elemző lépéseket kell végrehajtanunk a cél elérése érdekében. A vizsgálat során két egymástól eltérő célunk lehet: Vizsgálhatjuk azt, hogy a megfelelő terméket készítjük-e. Ebben az esetben validációt végzünk. Vizsgálhatjuk azt, hogy a terméket jól készítjük- e. Ebben az esetben verifikációt végzünk.

82 V & V: verifikáció és validáció A verifikáció: –azt vizsgáljuk, hogy a fejlesztés során egymás után végrehajtott fejlesztési lépések során előállított szoftver (ill. annak terve) megfelel-e a specifikációban rögzített elvárásoknak, tulajdonságoknak. –A verifikáció során a vizsgálat alapja mindig valamilyen fejlesztés során előállított információ (termék).

83 V & V: verifikáció és validáció A validáció: –általánosabb folyamat, –Azt vizsgáljuk, hogy az elkészített termék megfelel-e a megrendelő elvárásainak. –A validáció tehát magában foglalja a specifikáció ellenőrzését is.

84 Szoftvertesztelés alapsémája A tesztelés lényege összehasonlítás: –A tesztelt szoftver (software under test, SUT) kimeneteit, működését, viselkedését összehasonlítjuk valamilyen referenciával. – Az összehasonlítás alapjául szolgáló referencia leírása sok forrásból származhat, attól függően, hogy a szoftverfejlesztés mely stádiumában hajtjuk végre a tesztelést. Származhat az információ a specifikációból nyert adatokból, prototípus szoftver leírásából/megfigyeléséből, vagy a fejlesztés során előállított, rendszer viselkedését leíró modellből.

85 Szoftvertesztelés alapsémája

86 Funkcionális követelmények leírása A felhasználói célokat a követelményelemzés munkafolyamat során a funkcionális követelményekben definiált funkciókkal teljesítjük. A funkcionális követelményeket az UML-ben use case-ekkel írjuk le, ábrázoljuk. Minden felhasználói célhoz tartozni kell a funkcionális követelmények egy bizonyos halmazának, de legalább egy use case-nek.

87 Követelmények megvalósításának ábrázolása EA-ban

88 Követelményelemzés A megrendelővel (felhasználóval) egyetértésre jutni, hogy pontosan mit kell a rendszernek tudnia. A fejlesztőknek pontos képet adni a rendszerről. Meghúzni a rendszer határait. Biztosítani az iterációk tervezéséhez szükséges technikai információkat. A rendszerhez a felhasználói igényeknek megfelelő felhasználói interfész meghatározása.

89 Követelményelemzés Általános célok, feladatok: A megrendelővel (felhasználóval) egyetértésre jutni, hogy pontosan mit kell a rendszernek tudnia. A fejlesztőknek pontos képet adni a rendszerről. Meghúzni a rendszer határait. Biztosítani az iterációk tervezéséhez szükséges technikai információt. A rendszerhez a felhasználói igényeknek megfelelő felhasználói interfész meghatározása.

90 Új rendszer fejlesztése A probléma elemzése: –Nincs egy meglévő rendszer, amely meghatározná a megoldandó feladatot és az alapvető követelményeket. A probléma elemzését elsősorban az előkészítés fázisban, és a kidolgozás fázis korai szakaszában hajtjuk végre. Kapcsolódó tevékenységek: –Fogalomtár készítése –Use case modell: szereplők és use case-ek megkeresése –Követelmény kezelési terv kidolgozása –Projekt Vízió kidolgozása.

91 Fogalomtár készítése Közös fogalmak megkeresése. –a probléma domain területének közös fogalmai –az itt definiált fogalmakat konzisztens módon használhatjuk a rendszer bármilyen szöveges dokumentációjában –elkerülhetőek a projekt tagjai közötti félreértések A fogalomtár kialakítása során a következő típusú fogalmakat kell figyelembe venni: Üzleti fogalmak, amelyekkel az adott szervezet a mindennapi munkája során találkozik Valós világbeli fogalmak, amelyeket a rendszernek figyelembe kell venni, például: számla, utas, vevő… Események, amelyeket a rendszernek kezelnie kell, például megbeszélések, hiba előfordulások.

92 Új rendszer fejlesztése - Lépések –Felvázolni a rendszer funkcionális működését –Meghatározni, melyek azok a funkciók, amelyeket a rendszernek meg kell valósítani, és melyek azok, amelyek a rendszer határain kívül vannak –Meghatározni, hogy KI vagy MI fog kapcsolatba kerülni a rendszerrel –A készülő modellt csomagokra bontani a megtalált aktorok és használati esetek figyelembe vételével –Elkészíteni a használati eset modellt –A használati eset modell áttekintő leírásának elkészítése

93 Elvégzendő feladatok Felhasználói követelményeket teljesítő: –funkcionális és –nem funkcionális követelmények meghatározása. Funkcionális követelmények leírása UML segítségével: –Use case-ek.

94 Elvégzendő feladatok Use case-ek struktúrálása. Use case-ek és az aktorok kapcsolatának meghatározása: –use case diagram. Use case modell(ek).

95 Use case modell A követelményspecifikáció végére előálló use case modell: –a rendszer tervezett funkcionális működését, –a rendszer viselkedését írja le –a rendszert kívülről, a felhasználó szemszögéből nézve.

96 Use case modell elemei use case-ek (szoftverfunkciók), amelyeket a fejlesztendő szoftverrendszernek meg kell valósítani, aktorok, akik/amik a rendszer határán kívül vannak, a rendszerrel kapcsolatba kerülnek, hogy a rendszerrel feladatokat (szoftverfunkciók) hajtsanak végre, a kapcsolat az aktorok és use case-ek közötti viszonyrendszert definiálja.

97 Az aktorok és a use case-ek megkeresése gyakorlat: –gyakran elég nehéz a use case-ek listájának felállítása –a gyakorlat szerint elsőként könnyebb az aktorok listájának elkészítése, majd ezután a use case-k megkeresése –vegyük sorra a szereplőket, és nézzük meg – a felhasználó szemszögéből – mit várnak el a rendszertől! Mi az elsődleges funkció, amit a szereplő elvár a rendszertől? A szereplő fog adatot bevinni a rendszerbe, módosítani vagy törölni? stb.

98 Aktorok és use case-ek megkeresése - Aktorok azonosítása Cél: –Meghatározni, hogy KI vagy MI fog kapcsolatba kerülni a rendszerrel

99 Use case modell elemei - Aktorok

100 Aktorok Az aktor: –egy szerep, amit az érdekelt játszik/végrehajt a rendszerrel folytatott interakcióban. –A rendszer szereplője, valaki vagy valami a rendszer határán kívül, aki/ami kapcsolatba kerül a rendszerrel. –Az aktorok nem kizárólag személyek, lehetnek elemek, dolgok, gépek-berendezések, üzleti egységek, vagy a rendszerrel kapcsolatot létesítő valamely külső rendszerek, rendszerkomponensek.

101 Aktorok - szerepkör A szereplő elnevezés helyett gyakran a szerepkör kifejezés. Szerepkör: –A rendszer felhasználói meghatározott feladatkört (szerepet, jogosultságot) betöltve léphetnek csak kapcsolatba a rendszerrel, csak konkrét szerepkör birtokában használhatják a szoftverrendszert és azok szolgáltatásait.

102 Aktorok sajátosságai Egy felhasználó többfajta szerepet is játszhat/végezhet, többféle szerepkörben lehet; egy szerepkört több felhasználó is betölthet; –Ha van a rendszerben két azonos aktor, akkor az csak egy aktor.

103 Aktorok sajátosságai Az aktoroknak a rendszerrel kapcsolatban igényeik vannak, feladatok végrehajtását kezdeményezik, vagy a rendszer által nyújtott funkciók, szolgáltatások megvalósításában vesznek részt. –A feladatok végrehajtását kezdeményező szereplőket kezdeményező szereplőnek, a funkció (use case) megvalósításában részt vevőket résztvevő szereplőnek hívjuk. –Egy use case-t mindig csak egy aktor kezdeményezhet, egy use case megvalósításában viszont több aktor is részt vehet.

104 Aktorok sajátosságai Az aktorok egymással együttműködve megvalósítják a rendszer céljait; Az aktor nem objektum, hanem csak egy osztályszerű elem, amit az UML classifier minősítéssel azonosít; Az aktor grafikus szimbóluma egy pálcikaemberke.

105 Aktorok azonosítása A felhasználóval folytatott beszélgetések, a felhasználói célokat összefoglaló dokumentumok alapján körvonalazódik, hogy mik, vagy kik az érdekeltek a rendszer határán kívül, amik/akik közvetlenül kapcsolatba kerülnek, kommunikálnak a szoftverrendszerrel. A követelményspecifikációban meghatározott érdekeltek köre (pl. a Kft. ügyfélszolgálati munkatársai, mint a szoftverrendszer használói) nem feltétlenül, sőt sok esetben abszolút nem egyezik meg az üzleti modellezés során felállított érdekeltek (pl. a Kft. vezetése, aki tendert írt ki a szoftverrendszer fejlesztésére) listájával.

106 Az aktorok megtalálásának módja A felhasználói célokat összefoglaló dokumentumokból kikeressük a főneveket. A kereséskor a releváns szereplők meghatározása érdekében célszerű arra koncentrálni, hogy: –Ki/mi használja a rendszert? –Kik működtetik a rendszert, kik felelnek a rendszer karbantartási és adminisztrációs feladatainak végrehajtásáért? –Kinek a hatáskörébe tartozik a biztonságkezelés, rendszervédelem? –Létezik a rendszerben folyamatfigyelés, monitoring folyamat (monitoring process), amelyik hiba esetén újraindítja a rendszert? –Kommunikál-e az új rendszer más rendszerekkel? –stb.

107 A rendszer szereplőinek specifikálásra vonatkozó előírások A rendszerrel közvetlenül kapcsolatba kerülő, a rendszert használó érdekelteket (személyek, dolgok, más rendszerek, rendszerkomponensek) a feladatkörre, szerepkörre utaló névvel kell ellátni, azonosítani. Az aktorok neve egy tetszőleges jelekből álló karaktersor. Az aktor neve azonosítja a use case-t kezdeményező, vagy a use case megvalósításában részt vevő szereplőt.

108 A rendszer szereplőinek specifikálásra vonatkozó előírások Az UML modellező nyelv szabályai szerint az aktorokat grafikusan egy pálcikaember jelöli. Az aktor nevét a szimbólum alá írjuk. A specifikációban röviden meg kell adni mit vár el az aktor a tervezett szoftverrendszertől, mi a felelőssége.

109 Use case-ek azonosítása A rendszer aktorainak, és azok elvárásainak ismeretében már viszonylag könnyű meghatározni a use case-eket.

110 Use case modell elemei – Use Case-ek

111 Use case Az UML-ben use case-ekkel írható le a fejlesztendő szoftverrendszertől a valós szituációkban a felhasználó által elvárt, megkövetelt viselkedések, a rendszer által nyújtott szolgáltatások.

112 Use case fogalma Feladatok, funkciók kisebb vagy nagyobb egységeinek specifikálására szolgáló grafikus ábrázolási technika – a use case-ek valójában a rendszer funkcionalitását, viselkedését fejezik ki a rendszert kívülről szemlélve. A rendszer egy aspektusának pillanatképe. A rendszerrel kapcsolatos összes use case feltárása a fejlesztendő rendszer külső képét adja. A rendszer kívülről látható funkciói, un. kapcsolódási pontok a szoftverrendszert használók és a szoftverrendszer között.

113 A use case A felhasználó és a számítógépes rendszer közötti interakciót definiálja. Tipikusan a szoftver és a felhasználó (aktor) között lezajló kommunikáció, üzenetváltás lépéseit írja le a felhasználó szemszögéből. Egy use case pontosan azt határozza meg, hogy a felhasználó (aktor) MIT akar a szoftverrel végrehajtani, milyen célt kíván megvalósítani, ugyanakkor nem tér ki a megvalósítás, a HOGYAN részleteire?

114 Use case-ek a követelményspecifikációban A követelményspecifikáció munkaszakaszban definiált use case-eket a szakirodalom fekete doboz use case-eknek (black-box use case) nevezi. A fekete doboz jelző: –azt hangsúlyozza, hogy a fejlesztésnek ebben a szakaszában nem térünk ki a rendszer, a rendszerkomponensek belső működésére. –A cél csak a rendszer viselkedésének specifikálása a rendszert külső szemmel nézve, fontos a külső környezetnek a feltárása, a rendszerhatár meghúzása.

115 Példa Black-box módszer a rendszer (külső) viselkedésének leírására Belső működés specifikálása ÁrajánlatKészít_Weben use case: Végrehajtásakor az Ügyfél megadja az Árajánlat összeállításához szükséges adatokat, majd a rendszer elkészíti az árajánlatot. ÁrajánlatKészít_Weben use case: A rendszer ellenőrzi a megadott adatokat, ha az adatok helyesek a rendszer az adatbázisba, az árajánlat táblába beszúr egy új sort, rekordot.

116 A use case-ekre vonatkozó jellemzők, sajátosságok A fejlesztendő rendszer szempontjából megkülönböztetünk: –architektúrálisan fontos, –egyéb és –rendszeridegen use case-eket; egy use case lehet „kicsi vagy nagy”; egy use case diszkrét célt teljesít, valósít meg a felhasználó számára;

117 A use case-ekre vonatkozó jellemzők, sajátosságok a use case-eket minden esetben az aktorok kezdeményezik;

118 Use case-ek megtalálásának módszerei az adott területre jellemző felhasználóval való folytatott közös beszélgetések, interjúk, kérdőívek használata csoportos felmérés esetén, brainstorming (ötletbörze) módszer alkalmazása. Használata elsősorban új fejlesztések esetén hasznos, vagy nehezen megfogható, leírható problémák megoldásakor. vitakurzusok a korábbi beszélgetések során definiált dolgok (feladatok, funkciók) megvitatására, tisztázására, egyszerű, un. favágó módszer: a célokat megfogalmazó dokumentumokból kigyűjtjük az igéket, stb.

119 A use case-ek specifikálásra vonatkozó szabályok a követelményspecifikáció során feltárt diszkrét dolgokat, feladatokat – a use case-eket a funkciójellegre utaló névvel kell ellátni, azonosítani, a use case-t azonosító név egy tetszőleges jelekből álló karaktersor, a use case neve kettős szerepet tölt be: azonosítja a diszkrét feladatot, amit a rendszernek teljesíteni kell, az megnevezés az adott use case-t meg is különbözteti a többi use case-től.

120 A use case-ek specifikálásra vonatkozó szabályok a use case-eket (diszkrét feladat, funkció) az UML modellező nyelv szabályai szerint grafikusan egy ellipszis szimbólum jelöli, a use case (funkció) nevét az ellipszis alá írva adjuk meg, minden use case-hez tartozni kell egy use case leírásnak

121 Munkafolyamat

122 A rendszer hatáskörének kezelése

123 Kapcsolódó tevékenységek: –Használati esetek kategorizálása Ennek a tevékenységnek a feladata kiválasztani azokat a használati eseteket, amelyeket az adott iterációban meg fogunk valósítani. Ezeket kell majd elemezni és tervezni és ezeket fogjuk először implementálni. –Követelmények közötti összefüggések kezelése –Projekt Vízió kidolgozása

124 Használati esetek kategorizálása Azoknak a használati eseteknek és forgatókönyveknek a kiválasztása, –amelyek elemzését az aktuális iterációban el akarjuk végezni –amelyek szignifikáns, központi funkcionalitást valósítanak meg –amelyek architektúrális szempontból jelentősek A kategorizálás a rendszerépítész (architect) feladata.

125 Használati esetek kategorizálása Azoknak a használati eseteknek vagy forgatókönyveknek a kiválasztása, amelyeket az adott iterációban elemezni és tervezni kell. –A döntési szempont lehet: –A forgatókönyv fontossága: kritikus, fontos, kiegészítő –A megszüntethető kockázat: teljesítmény, felhasználhatóság, megfelelőség –Az architektúrára gyakorolt hatása –Egyéb technikai igények, például demo készítése. A Szoftver Architektúra Dokumentum használati eset nézetének elkészítése –architektúrális szempontból kritikus használati esetek

126 A rendszer definíciójának finomítása

127 Kapcsolódó tevékenységek: –Használati eset részletezése A használati esetekhez korábban elkészített flow of event leírás alapján a működés további részletezése. A részletes működés ábrázolása Activity diagram segítségével. –A szoftver követelmények részletezése Azoknak a dokumentumoknak az összegyűjtése és rendszerezése, amelyek a rendszerrel szembeni követelményeket tartalmazzák. Itt a korábban dokumentált követelményeket kell egységes formában megjeleníteni.

128 A rendszer definíciójának finomítása –A felhasználói felület modellezése A kiválasztott használati esetek végrehajtásához szükséges felhasználói felület megtervezése. A felhasználói felület osztályainak (határosztályok) azonosítása és tervezése. –Felhasználói felület prototípusának elkészítése Amennyiben a projekt során úgy döntöttünk, hogy készítünk prototípust

129 Használati eset részletezése A használati eset folyamatának részletes leírása a step- by-step leírásból kiindulva: –Hogyan kezdődik a használati eset? (Például: A használati eset akkor kezdődik, amikor a felhasználó kiválasztja a Jelentés menüpontot.) –Hogyan ér véget a használati eset? (Például: A használati eset véget ér, ha a felhasználó jóváhagyja a megadott adatokat. ) –Milyen kölcsönhatások történnek az aktor és a használati eset között? (Például: A felhasználó megnyomja az OK gombot, a használati eset megjeleníti a kiválasztható időszakokat…) –Milyen adatok cserélődnek a használati eset és az aktor között? (Például: A felhasználó megadja a nevét és jelszavát…) –Milyen ismétlődő viselkedést hajt végre a használati eset? Ez algoritmikus viselkedésre utal, de ha lehet, akkor nem ciklusokkal kifejezve. (Például: a használati eset mindaddig kéri az időszakot, amíg az aktuális dátumnál kisebbet nem kap…)

130 Használati eset részletezése Folyamatok struktúrálása: Egy használati eset is sokféleképpen hajtódhat végre: –Mit választ a felhasználó (bemenetek)? –A belső objektumok állapota milyen? Az összes opcionális, alternatív esetet le kell írni. Célszerűen külön szekcióba. Különösen, ha –nagyon nagy az opcionális szakasz, –a kivételes, hibás eseteket kezeli a folyamat - így tisztább marad az alapfolyamat, –az alfolyamat több helyről is elindulhat.

131 Használati eset részletezése - Activity diagramok A folyamatok szerkezetét aktivitás (activity) diagramok segítségével szemléltethetjük. Aktivitás-diagram –Több különböző technikát is ötvöz Folyamat ábra Petri háló Állapot diagram –Hasznos munkafolyamatok, illetve párhuzamos folyamatok modellezésére is. –Felfogható egy olyan speciális állapot diagramnak, amelynél az állapot átmenetek nem zéró idő alatt zajlanak le és egyszerre több tevékenységet is lehet végezni az átmenet alatt.

132 Use case leírás A felhasználó szemszögéből rögzítjük a felhasználó és a rendszer között zajló üzenetváltás (párbeszéd) lépéseit: –Normál működés, –Alternatív működés.

133 Use case leírás Normál működés: –a use case-ben definiált szokásos működést a use case normál lefutásának, más szóval alapfolyamatnak hívjuk. Alternatív esetek: –A működésnek lehetnek különleges, alternatív esetei (pl. hibás működés), ezek az alfolyamatok. A fejlesztés során minden use case esetén fel kell tárni az összes alternatív lefutási menetet. A tervezett rendszernek a use case-ekben definiált normál és alternatív működését külön forgatókönyvekben rögzítjük.

134 Forgatókönyv Más szóval szcenárió. A use case-ben definiált működés egy konkrét végrehajtása, lefutása, a use case egy instanciája (példánya). A rendszer use case-ben definiált működésének lépésenkénti, un. step-by-step végrehajtását írja le a felhasználó szemszögéből. Egy use case-hez az alternatív működések miatt több forgatókönyv készülhet, de egy biztosan.

135 Forgatókönyv A forgatókönyv készítésekor a rendszer és a felhasználó között zajló üzenetváltásokat a felhasználó szerepében célszerű megfogalmazni, hiszen a felhasználó fogja az alkalmazást használni. Az üzenetváltások leírásakor a MIT-re koncentráljunk, azt írjuk le, hogy a use case működéskor MI történik, milyen tevékenységek zajlanak, és ne térjünk ki a HOGYAN részleteire, a megvalósítás módjára. A forgatókönyvben elsőként a use case normál működést írjuk le, de el kell készíteni az alternatív esetekhez tartozó forgatókönyveket is.

136 Forgatókönyv készítése A forgatókönyv készítésére nincsenek szigorú formai előírások, megkötések. A forgatókönyvben a use case működését, vagyis az egymás után zajló tevékenységeket szöveges formában, mondatszerűen fogalmazzuk meg.

137 A forgatókönyv tartalma Egy lehetséges alternatíva: –a feladat rövid értelmezése, –alternatív útvonalak meghatározása, –a végrehajtásban résztvevő szereplők meghatározása, –közös feladatok kiválasztása.

138 Forgatókönyv készítése Érdemes megvizsgálni: –Hogyan kezdődik a use case? –Hogyan ér véget a use case? –Milyen kölcsönhatások történnek az aktor és a use case között? –Milyen adatok cserélődnek a use case és az aktor között? –Milyen ismétlődő viselkedést hajt végre a use case?

139 Példa Az ÁrajánlatKészít_Weben use case-hez készített részletes leírásban négy forgatókönyvet kell részletezni: –A use case normál lefutása szokásos működés esetén: a use case sikeresen véget ér, ha az Ügyfél elfogadja az Árajánlatra vonatkozó feltételeket.

140 Példa A szokásostól eltérő működéskor a lehetséges lefutások, alternatív útvonalak: –az Ügyfél a felhasználói név és a jelszó megadásakor a MÉGSEM gombra kattint. –az Ügyfél a felhasználói név és a jelszó megadásakor az OK gombot választja, azonban a rendszer a megadott adatok ellenőrzésekor hibát talál. A megadott adatok vagy azért hibásak, mert az ügyfél azokat rosszul adta meg, vagy azért, mert nem regisztrált felhasználó. Ilyen esetben a use case véget ér. –Az Ügyfél a rendszer által küldött Árajánlat elfogadása üzenet megerősítésekor a MÉGSEM gombot választja.

141 Forgatókönyv normál működés esetén Az Ügyfél a Kft. honlapján aktiválja az "Az Árajánlat készítés" funkciót. A bejelentkezéskor a rendszer megjeleníti a Login dialógusablakot, ahol kéri az Ügyfél felhasználói nevét, és jelszavát. Az Ügyfél megadja a felhasználói nevét, és jelszavát. A rendszer ellenőrzi (validálja) a megadott adatokat. Hibás adatok esetén újra kéri az adatokat.

142 Forgatókönyv normál működés esetén A rendszer megjeleníti az „Árajánlat készítés” lapot. Az Ügyfél megadja a kért adatokat. A rendszer validálja a megadott adatok helyességét, ellenőrzi az adatok konzisztenciáját. Ha az Ügyfélnek nem sikerült érvényesen kitölteni a lapot, a rendszer mindaddig visszatér a laphoz, amíg azt az Ügyfél helyesen ki nem tölti. A rendszer megerősítést kér az Ügyféltől az Árajánlat elfogadására. A rendszer elmenti az Árajánlat adatait, és nyugtázó üzenetet küld a képernyőn keresztül az Ügyfélnek az Árajánlat készítésének sikerességéről.

143 Aktivitási diagram

144

145 Activity diagram / Tevékenység diagram. Tevékenységfolyamatnak tekintjük: az egymás után végrehajtandó feladatokat, amelyeknél egy kiindulási pontot – initial state, avagy kezdő állapotot, és egy vagy több lezárási pontot, más néven vég állapotot – final state értelmezünk. Felhasználás: –egy UC (használati eset) formalizálása, megértése –workflow modellezés (több UC közötti kapcsolat) –metódusok összekapcsolása (többszálú alkalmazás).

146 Aktivitási diagram A forgatókönyvben meghatározott lépéseket az UML-ben tevékenységeknek, aktivitásoknak nevezzük. A forgatókönyvben meghatározott tevékenységek menetének grafikus szemléltetésére az UML diagramok közül az aktivitási (tevékenységi) diagramot használjuk. Egy use case-hez annyi aktivitási diagram készül, ahány alternatív lefutása (forgatókönyvek száma) van.

147 Tevékenységek, akciók, átmenetek tevékenységek, akciók: a rendszer működtetése során végrehajtandó feladatok, műveletek akciók: –a funkció-hierarchia legalsó szintjén elhelyezkedő elemi műveletek un. atomi műveletek –további lépésekre nem bonthatók –pl. számítási műveletek, objektum manipulására vonatkozó kérések stb. tevékenységek: –összetettebbek, további lépésekre bonthatók –megszakítható tevékenységek a végrehajtás folyamatában: az akciók elvégzéséhez meghatározott időre van szükség

148 Tevékenységek, akciók, átmenetek UML igazán nem tesz köztük különbséget, mégis lehet következtetni, hogy elemi műveletről vagy tevékenységről van szó –de a tevékenységekhez pl. hozzájuk kapcsolhatók belépési pontok, kilépési akciók átmenetek –a végrehajtás folyamatában műveletek követik egymást, az egyik művelet végrehajtása után egy másik művelet végrehajtása következik - átmenet

149 Aktivitási diagram Aktivitás, tevékenység (activity) –Valamilyen tevékenység, amit meg kell csinálni. –Valamely osztály művelete lesz belőle. Szekvencia: a tevékenységet egy másik tevékenység követ –Alapértelmezett a szekvenciális végrehajtás.

150 Aktivitási diagram A tevékenységek kezdetét a start szimbólum jelöli A működés félbeszakad: ha a vezérlés eléri az aktivitás diagram egy stop szimbólumát A működés befejeződik: ha minden aktivitás befejeződött és nincs hátra más végrehajtandó tevékenység

151 start Rendelés érkezik Fizetés ellenőrzése Raktárkészlet ellenőrzés Rendelés törlése Áru eladva Utánrendelés Kiszállítás *[ minden egyes árura a rendelésben ] [ nem OK ] [minden elem kész, fizetés OK] [ OK ] [ utánrendelés szükséges ] [ van raktáron ] Start, kezdőpont átmenet műveletek (tevékenységek, akciók)

152 Aktivitási diagram Elemkészlete: –aktivitás –sorrendezés/párhuzamosság –szinkronizáció –őrfeltételek –döntések szinkronizáció (fork/join) Aktivitás1Aktivitás2 [ őrfeltétel ] döntés kezdőpont végpont

153 Példa: Aktivitási diagram Rendelésfelvétel használati eset forgatókönyve: –Amikor egy rendelés beérkezik, minden egyese elemére megnézzük, hogy van-e raktáron. Ha van raktáron, akkor összerendeljük őket Ha egy utánrendelési (minimum) szint alá csökken a raktárban az árukészlet, akkor utánrendelést adunk be –Mialatt az árukészlettel foglalkozunk, megnézzük, hogy a fizetés rendben van-e: rendelés OK, fizetés OK: szállítás fizetés OK, rendelés nem OK: várakoztatás fizetés nem OK: a rendelés törlése

154 start Rendelés érkezik Fizetés ellenőrzése Raktárkészlet ellenőrzés Rendelés törlése Áru eladva Utánrendelés Kiszállítás *[ minden egyes árura a rendelésben ] [ nem OK ] [minden elem kész, fizetés OK] [ OK ] [ utánrendelés szükséges ] [ van raktáron ]

155 Aktivitási diagram a műveletek végrehajtási sorrendje általában szekvenciát, egymásutáni sorrendet mutat, de van amikor dönteni kell a folytatás irányáról – különböző ágak jönnek létre, különböző folyamat alternatívák jönnek létre az elágazási feltételek (branch) valamilyen logikai kifejezés formájában fogalmazhatók meg: –verbálisan a Boole algebra szabályrendszerével egyszerűen írhatók le: then, else az elágazási pontokban a rendszer kiértékeli, és az eredménytől függő ágon folytatja a végrehajtást

156 Aktivitási diagram - szinkronizáció feladatok, amelyek egyidejűleg, egymással párhuzamosan hajthatók végre bizonyos műveletek végrehajtásának a megkezdése előtt más feladatokat kell befejezni szemléltetés: szinkronizációs vonal szinkronizáció (fork/join)

157 Aktivitási diagram - szinkronizáció kétféleképpen értelmezhető: –elágazás – fork: a folyamat olyan pontja, amelyből a végrehajtás egy, vagy több ágban párhuzamosan végzett tevékenységek végrehajtásával folytatódik az elágazási pontban egy bemenő, és kettő vagy több kimenő akció van –csatlakozás – join: a csatlakozási pontban a folyamat különböző ágakban, addig egymással párhuzamosan végrehajtott tevékenységei befejeződnek, és egy újabb tevékenység megkezdésére kerül sor. a csatlakozási pontban kettő vagy több bemenő tevékenység befejezését kell szinkronizálni, a folyamat egy kimenő akcióval folytatódik

158 Use case modell elemei - Kapcsolat

159 Kapcsolatok Kapcsolat alatt klasszikus értelemben: –az aktorok és a use case-ek közötti kapcsolatokat értjük. Az UML-ben a rendszer szereplői és a use case-ek között definiált kapcsolatok modellezésére a use case diagram szolgál.

160 Kapcsolatok A kapcsolatot a diagramban az aktorokat és a use case-eket összekötő vonal szimbolizálja. A vonal lehet irányított.

161 Aktorok és use case-ek között értelmezett kapcsolatok típusa Kezdeményezés Közreműködés, részvétel a végrehajtásban

162 Aktorok és use case-ek között értelmezett kapcsolatok típusa Egy use case-t mindig egy aktor kezdeményezhet, aktivizálhat. A rendszer szereplői és a use case-ek közötti kapcsolatot egy irányított vonal, nyíl jelöli. A nyíl a szereplőtől a use case felé mutat. Az aktor és a számítógépes rendszer között alapértelmezésben kommunikációs jellegű kapcsolat van. –A kommunikatív jelleget a kapcsolatot szimbolizáló nyíl felett a > sztereotípiával jelölhetjük.

163

164 Példa

165 Aktorok és use case-ek között értelmezett kapcsolatok típusa Egy feladat (use case) végrehajtásában több aktor is közreműködhet. A use case megvalósításában részt vevő szereplőket és a use case-t egyszerű vonal (irányítás nélküli) köti össze.

166

167 Speciális kapcsolatok Két aktor közötti kapcsolatot. Definiálhatunk use case-ek közötti speciális viszonyokat is.

168 Speciális kapcsolat két aktor között Öröklődési viszony: –egy use case végrehajtásakor több szereplő is ugyanazt a szerepet tölti be, ugyanabban a szerepkörben van. Az öröklődési viszonyban két aktortípus: –leszármazott, –ős szereplő.

169 Speciális kapcsolat két aktor között A leszármazott minden use case-zel kapcsolatban van, amivel az ős szereplő kezdeményez kapcsolatot. Az ős szereplőnél definiált minden use case végrehajtását kezdeményezheti, de annál akár többet is

170 Speciális kapcsolat két aktor között

171

172 Speciális kapcsolatok use case- ek között Három speciális viszony: –tartalmazás, –kiterjesztés és –öröklődés viszonyokat.

173 Tartalmazás – include viszony A szereplő által kezdeményezett (alap vagy normál) use case-ek végrehajtásában vannak olyan részek, lépések, amelyek mindegyik use case végrehajtásakor bekövetkeznek és azonos módon játszódnak le. Érdemes az azonos viselkedéseket egy külön use case-be kiemelni.

174 Tartalmazás – include viszony A kiemelt viselkedés: –tartalmazott vagy rész use case. –A tartalmazott elnevezés utal arra, hogy a tartalmazott use case az alap use case-nek szerves része. A tartalmazott use case végrehajtása feltétel nélküli, vagyis az alap use case végrehajtáskor mindig bekövetkezik, lejátszódik.

175 Tartalmazás – include viszony Az UML-ben az alap use case-t és a tartalmazott use case-t szaggatott nyíl köti össze. A szaggatott nyíl az alap use case-től a tartalmazott felé mutat. A kapcsolat tartalmazás jellegét a szaggatott nyílon elhelyezett, francia zárójelek közé írt > sztereotípiával jelöljük.

176 Tartalmazás – include viszony

177

178 Kiterjesztés – extend viszony A modellben lehetnek use case-ek, amelyek végrehajtási menetében –bizonyos feltételek bekövetkezésekor a vezérlés egy másik use case-nek adódik át. Ilyenkor a normál use case-nek egy bővített változata játszódik le. Mivel a normál use case viselkedésében a feltétel csak bizonyos esetekben következik be, ezért a normál use case-t bővítő viselkedést érdemes külön use case-ben leírni.

179 Kiterjesztés – extend viszony A feltételt (extention point) a követelmények specifikálásakor kell megadni. A szaggatott nyíl a kiterjesztett use case- ből az alap use case felé mutat.

180 Kiterjesztés – extend viszony

181

182 Öröklődés – generalizáció Az öröklődési viszony: –a leszármazott use case örökli a normál use case viselkedését, kapcsolatait. –A leszármazott az eredeti/normál use case viselkedéséhez hozzáadhat újabb viselkedéseket, sőt az eredeti use case viselkedését felülbírálhatja, felülírhatja.

183 Öröklődés – generalizáció Az öröklődés jele: –az UML-ben egy telt fejű nyíl. –A nyíl a leszármazott use case-től az általánosított normál (ős) use case felé mutat.

184 Öröklődés – generalizáció

185

186 Use case modell Aktorok. Use case-ek. Use case-ek struktúrálása. Kapcsolatok. Ábrázolás: –Use case diagram.

187 Use case diagram

188 Használati eset diagram. A követelményspecifikációban feltárt –use case-eket, –Aktorokat (szereplőket) és –a közöttük értelmezett kapcsolatokat ábrázolja. Segít: –a rendszer viselkedésének megértésében –grafikus modellezésében.

189 Use case diagram Alkalmas: –A tervezett rendszerrel szemben támasztott összes követelmény (use case-ek halmaza) meghatározására, leírására. Eszköz: –A felhasználóval való kommunikációra.

190

191 Ügyfél által kezdeményezett use case-eket összefoglaló use case diagram

192 Use case modell dokumentálása Aktorok azonosítása. Minden aktor esetén meg kell határozni mit vár el a rendszertől. Use case-ek feltárása, use case lista összeállítása. Minden use case-hez részletes leírás készítése: –Alternatív forgatókönyvek készítése a use case működésének leírására. –Aktivitási/tevékenységi diagram készítése.

193 Use case modell dokumentálása Kapcsolatok meghatározása: –Kapcsolatok aktor és use case között. –Speciális kapcsolatok azonosítása. A rendszer funkcionalitásának, viselkedésének grafikus modellezése use case diagramok készítésével. A fejlesztés során menetközben módosult funkciók dokumentálása, módosítások átvezetése a követelménydokumentumba.

194 Követelményjegyzék bejegyzés formalap Funkcionális és nem funkcionális követelmények dokumentálásának eszköze. Követelmények pontosabb, precízebb meghatározása. Nem UML szabvány. Folyamatosan bővül a fejlesztés során.

195

196 Követelmény AZ egyedi azonosító Forrás a követelmény forrása, lehet személy, dokumentum stb. Prioritás a követelmény prioritása, a felhasználó szerint, pl. magas/alacsony, vagy kötelező/ javasolt/ választható Tulajdonos felhasználó vagy felhasználói szervezet, aki a követelménnyel kapcsolatos egyezkedésért felelős Funkcionális követelmény az igényelt lehetőség vagy szolgáltatás leírása Nem funkcionális követelmény leírás, lehetőség szerint cél értékkel, elfogadható tartománnyal (minimum, maximum), minősítő megjegyzéssel Haszon: a követelmény kielégítéséből származó várható hasznok leírása Megjegyzések/ javasolt megoldási módok lehetséges megoldások leírása, általános megjegyzések Kapcsolódó iratok hivatkozás kapcsolódó dokumentumokra, mint például felhasználói dokumentumok, projektalapító okirat, adatfolyam-ábra stb. Kapcsolódó követelmények ha különböző követelmények hatnak egymásra, vagy kizárják egymást, akkor a hivatkozást fel kell jegyezni mindkét oldalon, hogy esetleges változtatás esetén fel lehessen mérni a hatást a mások oldalon Megoldás a követelmény megoldási módjának feljegyzése, például egy konkrét funkcióleírásra való hivatkozással. Ha egy követelményt nem fogunk kielégíteni, akkor itt kell felírni az okait

197 Use case Követelményspecifikáció: –fejlesztendő szoftverrendszertől a felhasználó által elvárt, megkövetelt viselkedés(ek)t, a rendszer által nyújtott szolgáltatásokat írják le. Elemzés/tervezés: –A rendszer belső működésének leírása. –Hogyan lesznek a rendszertől elvárt funkciók, use case-ek megvalósítva, majd implementálva.

198 Követelmények áttekintése Formális ellenőrzés: megegyezik-e az általunk kialakított modell a felhasználó elvárásaival Az összes termék ellenőrzése több menetben –koncepció, –felhasználói igények, –használati eset modell, –szereplők, –használati esetek, –nem-funkcionális követelmények, –fogalomszótár, –követelmény-tulajdonságok

199 Követelményelemzés - tevékenységek

200 Követelményelemzés - termékek

201 Használati eset modell (Diplomáztatás esettanulmány) Használati eset modell Használati eset diagram

202 V.2. Elemzés - tervezés

203 Elemzés - tervezés Az előzőekben összegyűjtött követelményeket kielégítő rendszer tervezése Robosztus architektúra kialakítása A rendszerterv illesztése az implementációs környezethez és a hatékonysági elvárásokhoz

204 Elemzés - tervezés Általános célok, feladatok: Az előzőekben összegyűjtött követelményeket kielégítő rendszer tervezése. Robosztus architektúra kialakítása. A rendszerterv illesztése az implementációs környezethez és a hatékonysági elvárásokhoz.

205 Elemzés-tervezés A kidolgozás fázis kezdeti szakaszában az a cél, hogy a rendszerhez egy kezdeti architektúrát határozzunk meg („architektúra jelölt”). –Ez lesz az elemzési munka kiindulási pontja. Ha az architektúra 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 a cél a meglévő architektúra finomítása.

206 Elemzés/Tervezés - feladatok 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 a rendszer által használt (perzisztens és nem perzisztens) perzisztens adatokat tároló adatbázist.

207 Elemzés - tervezés Az architektúra finomítása (Refine the Architecture) –Az elemzési elemeknek megfelelő tervezési elemek azonosítása –Az elemzési mechanizmusoknak megfelelő tervezési mechanizmusok azonosítása –Az architektúra 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ő komponensek és tervezési elemek újrafelhasználásának maximalizálása a tervezés lehető legkorábbi szakaszában

208 Elemzés - tervezés A viselkedés elemzése (Analyze Behavior) –A használati esetekben leírt viselkedés alapján meg kell határozni azokat az elemeket, amelyek a tervezés alapjául szolgálnak Komponensek tervezése (Design Components) –A tervezési elemek definíciójának finomítása azon részletek kidolgozásával, amelyek az adott tervezési elem elvárt viselkedésének implementálá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 tervezési elemek alapján a komponensek implementálása –Az implementált komponensek unit szintű tesztelése

209 Elemzés - tervezés Adatbázis tervezése (Design the Database) –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

210 Tervezés fázisai Architektúra kialakítása: –Architektúra tervezés strukturális felépítése a rendszernek  minták, specifikáció, részek… –Adat tervezés adat könyvtár, ER  adat struktúrák Részletes tervezés: –Interfész tervezés belső és külső kommunikáció –Komponens tervezés architektúra terv elemei  implementálható program elemek, procedúrák, függvények stb.

211 Egy lehetséges architektúra meghatározása

212 Elemzés - tervezés Egy lehetséges architektúra meghatározása (Define a Candidate Architecture) –A rendszer architektúrájának kezdeti vázának elkészítése –Architektúrális szempontbó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 esetek megvalósításának létrehozása –Az elemzési osztályok meghatározása architektúrális szempontbó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

213 Egy lehetséges architektúra meghatározása Kapcsolódó tevékenységek: Architektúrális elemzés –a rendszer számára egy kezdeti architektúra meghatározása a cél. Használati esetek elemzése –az architektúrális szempontból meghatározó használati esetek elemzése

214 Architektúrális elemzés Pontosan definiálni kell a leendő rendszer felépítését.

215 Architektúra központú A rendszer architektúrája –(egy adott pillanatban) a rendszer alapvető komponenseinek szerveződése, melyek egymással meghatározott felületeken keresztül kommunikálnak, és hierarchikus szervezésű, egyre finomabb, egymással szintén megfelelő, alacsonyabb szintű felületeken keresztül kommunikáló komponensekből épülnek fel.

216 Architektúrális 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ű definíciója (rétegek és partíciók) –Általában két réteg: üzleti és alkalmazás réteg –Az alacsonyabb szintű felbontás az architektúrális tervezés feladata –UML eszköz a modell felbontására: csomag

217 Architektúrális elemzés Egymástól egyértelműen elhatárolt rétegek: –üzleti logika réteg, –alkalmazási réteg, –adatbázis réteg stb.), –és a rétegekbe tartozó objektumokat.

218 Architektúrá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.: >) –Láthatóság Tesztelés egysége is lehet Adattipusok global > Alkalmazas Reteg > UzletiReteg >

219 Architektúrális 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 > UzletiReteg >

220 Architektúrális elemzés Használati esetek megvalósításának létrehozása –A használati esetek további elemzésének, tervezésének előkészítése. –A használati eset modellben szereplő valamennyi használati esethez hozzunk létre egy használati eset megvalósítást ( >) a tervezési modellben (név ugyanaz.)

221 Use case realizáció Use case realization Use case-ek megvalósítása. Alap: –Követelményspecifikációban elkészített use case modell. Use case-ek: –az elemzési, –tervezési modellben tovább elemzzük, részletezzük.

222 Use case realizáció A use case egy lefutása a rendszeren belül. Az eseménykövetési (szekvencia) diagrammal modellezünk. A diagram: –a működéshez szükséges objektumokat –az objektumok közötti üzenetváltásokat, –azok időbeli sorrendjében. –Sequence Diagram.

223 Üzenetek A use case funkciója: –az üzeneteken keresztül teljesül. Az üzenetek: –eljárás vagy –függvény jellegűek, ez utóbbiak visszatérési értékét is megadhatjuk. –Az üzenetek paraméterezhetők.

224 Use case realizáció

225 Példa I.

226 Példa II. Konferencia felvétele Use Case realisation

227 Konferencia felvitele Use Case realisation

228 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, attribútumait és asszociációit.

229 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

230 Használati eset leírásának kiegészítése - Példa 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

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

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

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

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

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

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

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

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

239 Architektúra az alkalmazás jellege alapján Az objektumok csoportosítása az MVC koordináta rendszer alapján –Model-View-Control –Smalltalk vezette be –Sztereotípus –Minden jól tervezett objektum valamelyik koordináta fele húz.

240 MVC koordináta rendszer Koordináták: –Határ, –Entitás, –Control objektumok. Ez a gondolatmenet általánosítható alkalmazásokra, egy-egy alkalmazás olyan mint egy nagy objektum.

241 MVC koordináta rendszer Határ: –Felület dominenciájú alkalmazások: Jellegzetes desktop alkalmazások, szövegszerkesztők, vizuális felhasználói környezetek stb. Entitás: –Klasszikus információrendszerek –Fő feladatuk az adatkezelés Control –Algoritmus dominenciájú alkalmazások –Tudományos, műszaki számításokat végző alkalmazások –Az architektúrát az algoritmusok befolyásolják –Ritka a gyakorlatban.

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

243 Viselkedés szétosztása az osztályok között - 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.

244 Szekvencia diagram

245 Sequence diagram / Eseménykövetési 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.

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

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

248 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 (log állomány  szekvencia diagram).

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

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

251 Együttműködési diagram

252 Collaboration diagram / Kollaborációs 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

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

254 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

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

256 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] konkurensen hajtódik végre

257 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

258 Együttműködési diagram 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)

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

260 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

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

262 Mintapélda - KonfMan

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

264

265

266

267

268

269 Mintapélda – SWE Product

270 Use Case realizáció

271 Aktivitási diagram

272

273 Szekvencia diagram az elemzési szakaszban

274

275 Szekvencia diagram a tervezési szakaszban

276

277 Szekvencia diagram Elemzési modellben: –a use case egy részletes lefutását írja le. Nagyvonalakban definiált szoftverarchitektúra. Alapja: –A tervezési szakaszban: a végleges szoftverarchitektúra.

278 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), az felelősség a részrendszer szempontjából a használati esetek szerepét tölti be

279 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 attribútumait é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

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

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

282 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

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

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

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

286 Használati esetek elemzése / Attribútumok és asszociációk leírása

287 Attribútum 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ű transzformációk végezhetők rajtuk, nincs valódi viselkedésük

288 Attribútum Attribútum-érték az attribútum egy konkrét előfordulása, egy adott pillanatban felvett állapot, az objektumpéldányban tárolt elemi adat. Specifikációja: [láthatóság] név [: típus] [= kezdeti érték] [{jelleg}]

289 Attribútum Az attribútum neve mindig főnév és az attribútum által hordozott információtartalomra utal –Rövid leírás: csak abban az esetben hagyható el, ha az attribútum neve minden kétséget kizár Az attribútum típusa: egyszerű adattípus az elemzés során(összeg  cím)

290 Attribútumok Az UML szintaktikája: láthatóság név: típus = kezdetiÉrték {jellemzők} –az attribútum-név elnevezi a szempontot, –az attribútum típusa megadja a lehetséges értékeket. –a kezdeti érték az objektum készítésekor beállítandó értéket jelenti. –az attribútum-érték megadja, hogy az objektum milyen az adott szempontból Tanfolyam - tematika: string - megnevezes: string - idotartam: integer > a Tanfolyam osztály objektumainak van tematikája, az objektum meg tudja mondani a tematikáját, illetve az beállítható, implementáció: az objektumnak van egy tematika mezője.

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

292 Láthatóság Az objektum különböző tulajdonságai, metódusai mennyire fedhetők fel a külvilág számára. Az UML az osztályjellemzőkhöz (attribútum, művelet) három láthatósági szintet javasol: –a + public –a – private –a # protected

293 Láthatóság +: a jellemző interfészen keresztül tetszőlegesen minden osztály által elérhető, nincs szükség metódusra az eléréséhez, - : csak az osztály látja, csak saját objektumon belül látszik. # : a jellemző csak saját objektumból és az utódokból látszik, csak az adott osztályon érhető el, a gyermek (leszármazott) és a barát (friend) osztályok látják –Egy osztálynak barátja (friend) egy olyan metódus vagy akár teljes osztály, amely hozzáférhet az adott osztály minden – ill. deklarációtól függően néhány – mezőjéhez és metódusához.

294 Attribútum A típus egyszerű adattípusokat jelent. A kezdeti érték az objektum készítésekor beállítandó értéket jelenti.

295 Attribútum Az attribútumok meghatározásakor figyelmesen kell eljárni, mert egyes adatok az elemzés/tervezés későbbi szakaszaiban maguk is objektumoknak minősülhetnek (pl. lakcím vagy dátum). Az ilyen attribútumok számára a modellben külön osztályt kell definiálni.

296 Attribútum Az attribútumok 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 attribútumként felvenni, mivel az a megvalósításhoz kapcsolódik. Az osztály és az attribútum nem áll messze egymástól Az osztály szintű attribútumot aláhúzással jelöli az UML (A Rose-ban $ jel jelöli)

297 Műveletek Az osztály által nyújtott szolgáltatás. Feladat, tevékenység, amit az osztály végre tud hajtani. Az osztályok által nyújtott szolgáltatásokat elsősorban eseménykövetési diagramok üzenetei alapján azonosítjuk.

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

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

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

301 Műveletek A művelet megvalósítása a metódus. Egy osztály minden konkrét objektuma azonos műveletekkel rendelkezik. A metódusok segítségével végzünk műveleteket a tulajdonságokon, ill. módosíthatjuk azokat.

302 Műveletek Minden művelet implicit argumentumként "ismeri" az objektumát, el tudja érni annak attribútumait é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

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

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

305 Osztályok közötti asszociációk

306 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üld - asszociáció Nem az elemzés során kell dönteni, hogy valóban asszociáció lesz-e, de itt azt használjuk!

307 Asszociáció Az osztályok objektumai közötti kapcsolat leírása, absztrakciója. Az asszociációt, mint viszonyt megtestesítő fogalmat az osztályok közötti viszonyokra értjük. A kapcsolat fogalmat az objektumok közötti viszonyra értelmezzük

308 Asszociációk 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 interakciós diagramokhoz (együttműködési diagram) Ha két objektum között kapcsolat van, az azt jelzi, hogy az osztályaik között asszociációnak kell lennie. Az együttműködési diagram még kifejezőbb, hiszen ott az objektum kapcsolat egyből megmutatja az asszociációkat.

309 Asszociációk (association) Általában bináris (a magasabb fokú asszociációk általában felbonthatók binárisokra, bár ekkor részben elveszíti a mondanivalóját) Az asszociáció nagyon sok szabály és megkötés kifejezésére alkalmas, de mindenre nem  OCL

310 Asszociációk (association) Két osztály vagy osztályok közötti kapcsolatot a két osztályt összekötő vonal reprezentálja. Az asszociációhoz név rendelhető: a nevet az osztályokat összekötő vonal fölé, középre helyezve írjuk.

311 Szerep - roles Megadhatjuk az osztályoknak az asszociációban játszott szerepét. Minden kapcsolathoz két szerep rendelhető, melyek az asszociáció két végén levő osztályoknak az adott asszociációban betöltött szerepére vonatkoznak. A szerepek definiálásával párhuzamosan általában megadjuk a kapcsolat (asszociáció) irányát. A szerepeknek az osztályokhoz rendelése az attribútumokhoz hasonló funkciót töltenek be

312 Multiplicitás Hány objektum vehet részt az asszociációban. Multiplicitás –az egyik osztály egy objektumához a másik osztályból hány objektum tartozik, vagyis kifejezi, hogy az osztályok objektumai milyen számosságban kapcsolódnak egymáshoz. Kardinalitás, a számosság fogalma. –Megadja az adott osztályban specifikálható előfordulások minimális, illetve maximális számát.

313 Multiplicitás jelölése UML-ben 1: az adott osztály egy objektumához a másik osztályból pontosan egy objektum kapcsolódik 0..1: 0 vagy 1 objektum kapcsolódik, opcionális kapcsolat 0..*: opcionális többes kapcsolat 1..*: 1 vagy többes kapcsolódás, kötelező többes kapcsolat : egy objektumhoz [22,44] zárt intervallumnak megfelelő számú objektum kapcsolódhat 9: ebben az esetben pontosan 9 objektum kapcsolódik a megjelölt osztály egy objektumához 2 és 13 értékeken kívül bármilyen számosság lehetséges: a számosság akár szövegesen is megadható.

314 Navigálhatóság iránya Az asszociáció bejárhatóságának iránya. A kapcsolatok mentén kommunikáció zajlik, amely lehet egy vagy kétirányú. A kommunikáció irányának jelölésére az osztályokat összekötő vonalra nyilat helyezünk. Megadja, hogy az asszociációval összekötött osztályok közül melyik kezdeményezi a kommunikációt, melyik osztály objektumainak kell ismernie a másik osztály objektumait.

315 Megszorítás Constraint: –korlátozás, ami az egyes modellelemek között definiált asszociációs viszony finomítására szolgál. Klasszikus példa a megszorításra, amikor azt akarjuk hangsúlyozni, hogy az asszociációban az egyik objektummal kapcsolatban levő objektumok rendezve legyenek elérhetőek, láthatóak. A megszorítások a modellben kapcsos zárójelek {} között szerepelnek.

316 Megszorítás Megszorítások megfogalmazására az UML specifikáció részét képező OCL (Object Constraint Language) nyelv ad lehetőséget. Az OCL segítségével további szemantikai értelmezéssel lehet finomítani a modellt.

317

318 A kapcsolatok implementálása

319 A konceptuális modell Csak a lényegi elemekre, az elemek közötti kapcsolatok leírására koncentrál. A diagramban ábrázolhatjuk a kapcsolat fokát, megadhatjuk az asszociáció nevét és különféle asszociációs viszonyokat ábrázolhatunk

320

321 A specifikációs szintű modell Csak felelősségeket definiál, de nem kód szinten: egy Order-nek lesz olyan felelőssége, hogy megmondja melyik Customer-hez tartozik. A modell azt fejezi ki, hogy egy Order-nek az a felelőssége, hogy megmondja pontosan melyik egyedi azonosítójú Customer tartozik hozzá.

322 class Order { public Customer customer(); public Enumeration orderLines(); //Az Order osztálytól lekérdezhetők hozzátartozó orderLine-ok. }

323 Implementációs modell Már a felelősségek pontos megvalósítását is definiáljuk. Az implementációs osztály-diagramban azt írjuk le, hogy minden Order típusú objektum tartalmaz egy pointert, amelyik pontosan egy adott Customer objektumra mutat.

324 Az Order osztály definíciója class Order // Az Order osztály definíciója { public: Order(); virtual ~Order(); longlPrice; longlNumber; Customer* m_pTheCustomerOfTheOrder; Customer* getTheCustomerOfTheOrder(); };

325 A getTheCustomerOfTheOrder() függvény megvalósítása Customer* Order::getTheCustomerOfTheOrder() { return m_pTheCustomerOfTheOrder; };

326 Példa - asszociációkra CégSzemély Alkalmazás munkaadómunkavállaló Asszociáció neve Szerepkör

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

328 Az öröklődés A modellelemek (use case-ek, osztályok) között értelmezett sajátos viszony. A modellelem sajátjaként kezeli a nála általánosabb szinten definiált modellelem jellemzőit (a modellelemek jellemzőihez beállított láthatóság alapján). Az utód osztály (leszármazott) sajátjaként kezeli a nála általánosabb/magasabb szinten levő osztály (ős osztály) attribútumait és műveleteit.

329 Öröklődési viszony UML-ben Az öröklődés jele egy üres háromszögben végződő nyíl, a háromszög csúcsa az ős osztálynál található.

330 Öröklődési viszonyok Öröklődési viszony: –Általánosítás (generalizáció – generalization) –Specializáció (pontosítás – specialization)

331 Általánosítás A különböző objektumok sokszor tartalmaznak közös jellemzőket (adatok, műveletek). Az általánosítás az a folyamat, amikor ezeket a közös jellemzőket kiemeljük egy ős osztályba (alulról-felfelé). Eredményként létrejön: –egy általános/közös sajátosságokat tartalmazó ős vagy szülő osztály, amelyhez tartozik –egy vagy több speciális tulajdonságokkal rendelkező al vagy gyerek osztály. Használatának célja a kód újrafelhasználási fokának emelése a rendszerben.

332 Általánosítás Az ős osztály általában absztrakt osztály. –Osztály, aminek nincsenek példányai. Az ős osztály szerepe: –csak a közös sajátosságok egy helyen történő tárolása, segítségével jelentősen egyszerűsödik a modellünk felépítése.

333 Általánosítás - példa

334

335 Specializáció Meglevő osztályokból származtatott osztályokat képezünk finomítással (fentről- lefelé). A finomítás célja –az osztályok specifikációjának pontosítása, az objektumok egyedi jellegének megerősítése az egyedi jellegre utaló jellemzők definiálásával.

336 Specializáció A származtatott osztályok keresése során feltételezzük, hogy az osztályok általánosak (gyűjtőfogalmat jelenítenek meg). A specializáció során azt vizsgáljuk, hogy újabb attribútumok és műveletek hozzáadásával milyen, a feladat szempontjából értelmes osztályok határozhatók meg. Az attribútumokat és az asszociációkat mindig a legáltalánosabb osztályhoz rendeljük. –A ős osztály nem feltétlenül absztrakt.

337 Specializáció - Példa

338 Öröklődési hierarchia Öröklődési lánc. A hierarchiában azokat az osztályokat, amik nem örökölnek másoktól sajátosságokat – vagyis nincsenek szüleik – gyökér osztály. –a {root} megszorítással jelöljük Az öröklődési lánc legalsó szintjén – vagyis nem örökítenek tovább jellemzőket – levél (leaf) osztályok. –{leaf} megszorítás az osztály neve alá vagy megjegyzésbe kerül.

339 Öröklődési hierarchia

340 Az öröklési viszony egyszeres: egy osztálynak csak egy őse lehet. többszörös: a kapcsolatban egy osztálynak több szülője is lehet. többszintű: egy osztálynak legalább egy őse és több leszármazottja van. Ez az osztály az öröklődési lánc köztes szintjén helyezkedik el.

341 Speciális fogalmak, asszociációs viszonyok Aggregáció – kompozíció Minősített asszociáció

342 Aggregáció Egy objektum több másik objektumból épül fel, vagyis egy objektum egy vagy több másik objektumot tartalmaz. Az UML lehetőséget ad összetett objektumok definiálására és kezelésére, aminek eredményeként az osztályok között ún. rész-egész viszony jön létre. A rész-egész viszony formái: –Aggregáció –kompozíció

343 Aggregáció Más UML szimbólum az aggregáció és a kompozíció jelölésére. Az aggregációt egy rombusz, a kompozíciót egy sötétített rombusz szimbolizálja, a rombuszok a tartalmazó osztály felöli oldalon helyezkednek el.

344 Aggregáció Aggregation: a rész-egész viszony gyengébb formája. A tároló objektum (az egész osztály) és az azt felépítő részobjektumok (részelemek) elkülönülnek. A részoldal nem értelmes az egész nélkül. –Abban az esetben, amikor az osztály a másik oldal nélkül is értelmes, akkor a két modellelem között egyszerű asszociációs viszony van.

345 Aggregáció

346 Kompozíció Composition: a rész-egész viszony erősebb változata. A tároló objektum a részobjektumokat is fizikailag tartalmazza –együtt keletkeznek és szűnnek meg, vagyis az egész megszűntével a rész is megszűnik. –Az egész oldal számossága csak 1 lehet.

347 Kompozíció

348 Minősített asszociáció Két osztály között asszociációs viszony áll fenn és az egyik osztály egy tulajdonságot, attribútumot (minősítő - qualifier) használ fel kulcs gyanánt az asszociáció másik oldalán levő objektumok elérésére, azonosítására. Azt az osztályt, amelyik a másik osztály objektumait akarja a minősítő attribútum felhasználásával elérni, célosztály, a kapcsolatban részt vevő másik osztályelemet forrásosztály.

349 Minősített asszociáció A rendszer működése során a meghatározott minősítő attribútumok (kulcsértékek) alapján kérdezhetők le az egyes elemek. Implementációs szinten a minősített asszociáció rendszerint a célosztály objektumaiból képzett indexelhető tömb, vagy valamilyen más, kulcs szerinti keresésre alkalmas összetett adatstruktúra (pl. hashtábla) megjelenését eredményezi a forrásosztályban.

350 Minősített asszociáció

351 A Product osztály productID attribútuma kulcsjellemzőként, ún. minősítőként szolgál a ProductCatalog számára.

352 Asszociációs osztály Két osztály közötti kapcsolat jellemzésére, ill. annak létrejöttéhez önálló tulajdonságok, esetleg metódusok tartoznak. Alkalmazása: –két osztály elemei között több-több jellegű leképezést akarunk megvalósítani, de az egymáshoz rendelt párokhoz, ill. az asszociációval jelzett kapcsolat létrejöttéhez még további információkat is hozzá akarunk rendelni, amelyek igazából egyik osztályhoz sem tartoznak kizárólagos módon.

353 Asszociációs osztály Az UML-ben az asszociációs osztályt és a kapcsolatot szaggatott vonal köti össze. Főként az elemzési fázisban. A tervezési és az implementációs modellben ezek az osztályok normál osztályokká szerveződnek

354 Asszociációs osztály

355 Származtatott elemek Elemek, amelyek más, már a modellben definiált elemekből származnak, azokból számítódnak. A származtatásra leggyakrabban az attribútumoknál és az asszociációknál lehet szükség. A számított tulajdonságokat a tulajdonság neve előtt megjelenő per (/) jellel jelöljük. A számításhoz használt kifejezést kényszerként (megszorítás) kapcsos zárójelek {} között megadva írhatjuk le.

356 Származtatott elemek

357 Sztereotípia A modellelemek tipizálása, minősítésre szolgál. Sztereotípia megadása: –karaktersorának francia zárójelek közé tételével vagy –szimbólummal, vagy –a kettő egyidejű alkalmazásával.

358 Elemzési osztályok sztereotípiái Az elemzési modellben az osztályok minősítésére: –a >, –a > és –az > sztereotípiákat használhatjuk. A sztereotípusok meghatározását az interakciós diagramok készítésekor, elemzésekor lehet megtenni.

359 Elemzési osztályok sztereotípiái Megkönnyíti: –a diagramok összeállítását, –értelmezését, –elősegíti a szoftverrendszer rétegeinek: felület/prezentációs réteg, alkalmazáslogika, adattárolási logika szétválasztását.

360 Absztrakt osztályok Speciális osztályok, amelyeknek nem hozhatunk létre példányait. Az osztály nevét döntött betűkkel kell írni. Az absztrakt osztályból mindig származtatunk további osztályokat, amelyek öröklik az absztrakt osztály attribútumait, műveleteit és asszociációit.

361 Függőség Két elem egymásra hatását fejezi ki. Az egyik elem definíciójának (specifikációjának) változása a másik elem megváltozását okozhatja, eredményezi.

362 Függőség A kapcsolatban az előbbi a független, az utóbbi a függő elem. A függési kapcsolatot irányított, szaggatott vonallal modellezzük. A nyíl iránya egyben meghatározza a függőség irányát. –A nyíl a függő elemtől indul, és a felé az elem felé mutat, amitől az elem függ

363 Függőség Gyakran adatcsere jellegű kapcsolatok leírására használjuk. Ilyen kapcsolat lehet például a felhasználói felület egy ablaka, mely adatokat kér be a felhasználótól (átmenetileg létező objektum) és az adatokat egy szakterületi, perzisztens módon eltároló objektum között. Az ablak esetében ahhoz, hogy teljesíteni tudja funkcióját, szüksége van a tároló objektumra.

364 Osztály-attribútum, osztály- művelet Az osztályok attribútumait és műveleteit különleges szereppel és jelleggel ruházhatjuk fel, ún. scope specifikációt rendelhetünk hozzájuk: –A classifier típusú attribútumok –A classifier típusú műveletek.

365 Osztály-attribútum, osztály- művelet A classifier típusú attribútumok (class-scope attibute) –az osztály minden objektumában, vagyis instanciájában ugyanazt az értéket veszik fel. A classifier típusú műveletek –minden objektumra, vagyis instanciára azonos módon lejátszódó műveletek. Aláhúzással jelöljük.

366 Osztály-attribútum, osztály- művelet

367 Osztálynak önmagával való asszociációja (self-association) Személy házasság +feleség +férj 0..1 hierarchia +főnök +beosztott 0..1 * Szerepkör Fonök > Beosztott > 0..n n Személy Megvalósít

368 Asszociációs osztály CégSzemély **** +munkavállaló+munkaadó Alkalmazás fizetés : double Részleg 1*1* Asszociációs osztály Asszociáció attribútumai Asszociáció vagy attribútum?

369 Osztálydiagram a leíráshoz Class diagram. Az osztály diagram a legismertebb objektumorientált (OO) technika: –A rendszer objektumait leíró osztályokat és –a közöttük levő kapcsolatokat modellezi.

370 Osztály diagram

371 Osztálydiagram a leíráshoz Class diagram. Az osztály diagram a legismertebb objektumorientált (OO) technika: –A rendszer objektumait leíró osztályokat és –a közöttük levő kapcsolatokat modellezi.

372 Osztály A közös tulajdonságokkal (attribútumok), viselkedéssel (metódusok) és kapcsolatokkal rendelkező objektumok csoportjának, halmazának leírására szolgálnak

373 Osztály Az objektum: –az osztály konkrét megjelenési formája, egyedi példánya (instancia). –Az osztályok attribútumok és metódusok (függvények, eljárások) gyűjteménye.

374 Osztály Az osztályt az UML-ben egy három részre osztott téglalap modellez: –az osztály megnevezését a felső részben adjuk meg, –a középső részben találhatók az attribútumok (tulajdonságok), –az alsó rész a műveleteket tartalmazza.

375 Osztálydiagramok a fejlesztési modellben A fejlesztés különböző munkaszakaszaiban készülnek. Ez nem újabb és újabb modellek, a fejlesztés teljes ideje alatt egy alapmodellt vizsgálunk. Ezt az egy modellt fokozatosan bővítjük a megfelelő részekkel a fejlesztés menetében előrehaladva. A modell aktuális állapotát, érettségét az egyes szakaszokban készített osztálydiagramokkal ábrázoljuk.

376 Osztálydiagramok a fejlesztési modellben Üzleti modellezés –Szakterületi osztálydiagram elemei: Üzleti aktorok Üzleti entitások –üzleti objektum modell Elemzési szakasz: –Elemzési osztályok leírása Tervezési modell: –Az elemzési modell részletezése –Implementáció alapja

377 Osztálydiagramok a fejlesztési modellben Módszertanok: –Az osztálydiagramot három alapvető perspektíva szerint értelmezik. –Ez nem része az UML definíciójának. –Hasznos, hogy mindig csak az aktuális probléma megoldására engedi a fejlesztésben résztvevő szakembereket koncentrálni

378 Osztálydiagramok a fejlesztési modellben - perspektíva Konceptuális perspektíva Specifikációs perspektíva Implementációs perspektíva

379 Osztálydiagramok a fejlesztési modellben - perspektíva Konceptuális perspektíva: –a kapcsolat foka, –az asszociáció neve, –a különféle asszociációs viszonyok: öröklődés, aggregáció, kompozíció

380 Osztálydiagramok a fejlesztési modellben - perspektíva Specifikációs perspektíva –Átmenet a konceptuális és az implementációs megközelítés között. –A use case-ek fizikai megvalósításának módját írja le, a megvalósítás vázát adja. –A modellelemekhez felelősségeket határoz meg, de ezt nem kód szinten teszi. –Az alkalmazás struktúrájára, felépítésére összpontosít.

381 Osztálydiagramok a fejlesztési modellben - perspektíva Implementációs perspektíva –Valódi osztályok konkrét programnyelvi környezetben.

382 CRC kártya Class – Responsibility – Collaboration Osztály – Felelősség – Együttműködés CRC kártya használatának elve: –Ward Cunningham és Kent Beck.

383 CRC kártya Osztályok meghatározása nem diagramok alapján, hanem táblázatos lapok segítségével. A leírásban nem metódusokat és attribútumok, hanem az osztályokhoz rendelhető felelősségek vannak.

384 Felelősség Annak a magas szintű leírása, hogy mi a fő célja az illető osztálynak. Cél: –Minél egyértelműbben meghatározni egy osztály működésének a célját, egy rövid, tömör leírás formájában.

385 CRC kártya

386 Ixtlan Software

387 Elemzési osztályok egységesítése Az elemzési osztály neve: –fejezze ki azt a szerepet, amit az adott osztály a rendszerben játszik –legyen egyedi, szinonimák sem megengedettek Vonjuk össze: –a hasonló viselkedésű, azonos szerepű osztályokat –azokat az entitásokat ( > osztályokat), amelyeknek azonosak az attribútumaik, 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)

388 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 –implementációs 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

389 Tervezési elemek azonosítása Tervezési osztályok: az egyszerű elemzési osztályokból egy-egy tervezési osztály keletkezik –Tipikusan az > osztályok ilyenek Tervezési alrendszerek: az összetett elemzési osztályokból keletkezik. Az elemzési osztály által definiált viselkedés túl komplex ahhoz, hogy egyetlen osztály szolgáltatásaival megvalósítható legyen. –Implementáció: komponensek –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)

390 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, a típus 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 a típus 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

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

392 A futás idejű architektúra leírása A konkurenciára vonatkozó követelmények elemzése, a processzek azonosítása, a processzek közötti kommunikációs mechanizmusok azonosítása, a processzek közötti szinkronizálást végző erőforrások allokálása, a processzek életciklusának azonosítása a modell elemeinek szétosztása a processzek között.

393 Funkciók 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ó specifikálása A processzek elosztása a csomópontokba

394 Az architektúra 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. Az architektúrális tervezés 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 architektúra közötti ellentmondásokat. –Ilyenek lehetnek például a hiányzó, vagy nem reális követelmények vagy a túlzott bonyolultságú architektúra. Az architektúra 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…

395 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 az implementációhoz Annak ellenőrzése, hogy a tervezési modell megfelel-e a tervezési útmutató alapelveinek

396 Komponensek tervezése

397 Komponensek tervezése - Cél A tervezési elemek definíciójának finomítása azon részletek kidolgozásával, amelyek az adott tervezési elem elvárt viselkedésének implementálá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 a komponensek implementálása Az implementált komponensek tesztelése annak ellenőrzésére, hogy megfelelnek-e a unit szintű követelményeknek

398 Komponensek 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 implementálá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

399 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űveleivel kapcsolatos követelmények finomítása A részrendszerek és azok interfészeinek műveleihez kapcsolódó követelmények finomítása

400 Részrendszerek tervezése Az alrendszer szolgáltatásait az interfészei biztosítják a külvilágnak –Egy interfész-osztály metódusával: ennek végrehajtásában közreműködhetnek más osztályok –Az interfészt megvalósító alrendszer interfészével Az alrendszeren belüli elemek együttműködését szekvencia illetve aktivitás 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)

401 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

402 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, metódusok –Állapotok –Attribútumok –Függések –Asszociációk –Öröklődés –Az osztályhoz kapcsolódó nem-funkcionális követelmények kezelése

403 Osztályok tervezése A lépések nem szekvenciálisan 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 implementálhatónak kell lennie, tehát a tervezés során használt modell szorosan összefügg az implementációs környezettel

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

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

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

407 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 az architektúrális tervezés szakaszában kell kialakítani! tblTanfolyam > név : String > tematika : Long String > doubleClick() > tlbTanfolyamIdopont > tanfolyam kezdete : Date > tanfolyam vége : Date > oktatók : String > doubleClick() > frmJelentkezo > név : String > cím : Long String > telefonszám : String > cégnév : String > regisztráció()

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

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

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

411 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

412 Osztályok tervezése / Műveletek tervezése A használati eset megvalósítások alapján definiálhatókon kívül műveletekre is szükség lehet: –Létre lehet-e hozni, lehet-e inicializálni 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 attribútumaik és kapcsolataik megegyeznek-e, elosztott rendszerben nehéz ügy)? –Le kell-e másolni egy objektumot? –Szükség van-e egyéb műveletekre a mechanizmusok megvalósításához? (Például szemét-gyűjtési mecha-nizmus megköveteli, hogy egy objektum törölni tudja az összes egyéb objektumra vonatkozó referenciáit)

413 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) Az implementációs nyelv szintaxisa 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 opcionális, default értéke, érvényes értékek Kevesebb paraméter  könnyebben használható fel újra, könnyebben érthető ( OO előny! )

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

415 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 implementálni? –Milyen attribútumok 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 aktivitás diagram alkalmazható az algoritmus leírásra.

416 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 diagramokkal!

417 Állapot-átmeneti diagram

418 Az állapot-átmeneti diagram State/State transition diagram tágabb értelemben: –a rendszer dinamikus nézetét jellemző technika –az állapot diagramokkal leírható egy rendszer viselkedése szűkebb megközelítésben: –egyetlen osztályhoz kapcsolódó fogalom, amely bemutatja az osztály konkrét objektumának élettartama (a rendszerben levő) alatt mutatott viselkedését, vagyis azokat a lehetséges állapotokat, amelyekbe az objektum kerül, jut, és ahogy az objektum állapota változik (állapotátmenet) az őt érő események hatására

419 Állapot-átmeneti diagram Az objektumok dinamikus viselkedésének leírására szolgáló eszköz. Egy-egy objektum elemezésére szolgál: –az objektum az események hatására hogyan változtatja meg a belső állapotát, –az események hatására milyen üzeneteket küld a többi objektum számára.

420 Állapot-átmeneti diagram A fejlesztés során csak az intenzíven dinamikus (változó) viselkedésű objektumok állapot-átmeneteit érdemes modellezni. A gyakorlatban a legtöbb osztályhoz nem készül állapot-átmeneti diagram, mert azok a rendszerben csak kisegítő ún. utility osztályok.

421 Állapot-átmeneti diagram Ábrázolásukra különböző megoldások vannak. Az egyes megoldások némileg szemantikájukban különböznek egymástól. Az UML szerinti állapot diagram: David Harel által kidolgozott megoldás, javasolt állapot diagram: –elsőként az OO módszertanok közül az OMT alkalmazta – Booch is beépítette módszertanába - second edition

422 Az objektumok állapota az objektumok a valós dolgokat leíró elemek a valós dolgokhoz hasonlóan az objektumoknak is van létük, mindegyik valamikor, valaminek a hatására létrejön, egy ideig létezik, majd megszűnik életük során más más állapotokat vesznek fel, különböző módon viselkednek a felvett állapotokat csak véges ideig tartják, ez alatt az idő alatt az objektum az adott állapotban van

423 Az állapot egy konkrét objektum adott időpontban vett attribútum-értékei és kapcsolatai együttesen az állapot két esemény közötti időtartamot határoz meg az a nem nulla hosszú időszak, amíg az objektum valamely esemény bekövetkezését várja jelölés:

424 Állapotok leírása Eseménykövetési diagramok is segítenek. Az állapotok feltérképezéséhez ki kell gyűjteni: –az adott osztály objektumait reprezentáló függőleges vonalakat (életvonal – lifeline), –a kapott és küldött üzeneteket jelölő nyilakkal együtt. A kapott üzenetek forrása és a küldött üzenetek célja az állapotmodell szempontjából lényegtelen. Egyetlen eseménykövetési diagramrészletből kell kiindulni. Végig kell nézni az objektumhoz érkező, és az objektumot elhagyó üzeneteket.

425 Az állapotok két esemény között írják le az objektumot. –Ha két egymást követő állapot között az objektum kívülről kap üzenetet, akkor ezt az eseményt kell megadni az állapot-átmenet eseményeként. –Amennyiben a két állapot között az objektum küld üzenetet, az üzenet elküldését az átmenet során elvégzendő akcióként kell megadni. –Ha eseménykövetési diagram ciklusokat tartalmaz, a bejárt állapotokat csak egyszer kell létrehozni, és az állapot-átmeneteket úgy kell kialakítani, hogy a ciklus végén az objektum újra a ciklus elején lévő állapotba kerüljön. Állapotok leírása

426 Az order különböző állapotait bemutató állapotdiagram start self-transition transition activity state

427 Az order különböző állapotait bemutató állapotdiagram kiindulási/kezdő pont (start point): a diagram egy kiindulási ponttal indul (az objektum automatikusan a kezdő állapotba lép), és megmutatja a kiindulási/kezdő átmenetet: „/ get first item” a checking állapotba

428 Átmenet az átmenetet egy esemény váltja ki, vagyis az átmenet az objektum válasza egy külső eseményre, az átmenet során az objektum egy másik állapotba kerülhet általában eljáráshívással jár együtt, vagyis valamilyen tevékenység végrehajtásával az átmenet szintaxisa – három része van: –esemény –feltétel –akció –szintaxisa: esemény [feltétel] / akció - Event [guard] / action –megadásuk opcionális

429 Állapot-átmenet típusai Külső állapot-átmenet: –Az objektum állapotai között értelmezzük, az állapotokat összekötő nyíllal jelöljük. –Az aktuális állapotból másik állapotba vezet. –Eljáráshívás vagy történik, vagy nem. Belső állapot-átmenet: –Az objektum egy adott állapotában értelmezzük. –Eljáráshívással jár együtt anélkül, hogy az objektum állapota megváltozna. A belső átmenetet az állapot alsó rekeszében adjuk meg.

430 A rendelési rendszer példában az átmenet szintaxisa: esemény [feltétel] / akció - Event [guard] / action a példában az átmenet megadása: –csak egy akció van: „/ get first item”, ez az átmenet esetén végrehajtandó akció –elsőként ezt az akciót kell végrehajtani a checking állapotba való belépéshez

431 Esemény esemény vagy üzenet: egy objektumnak egy másik objektumra történő hatása: az objektum az állapotából adott esemény hatására más állapotba kerülhet az átmenetet kiváltó események az esemény egyetlen időpillanathoz kapcsolódik - (az állapot két esemény közötti időtartamot határoz meg) ha egy átmenethez nincs esemény megadva - az esemény nélküli állapotváltás esetén: az objektum az állapothoz rendelt tevékenységet végrehajtva automatikusan a következő állapotba kerül

432 A példa folytatása a checking állapotból három átmenet látható mindhárom átmenethez feltétel, őrszem kapcsolható guard transition

433 Feltétel az átmenet feltétele más néven: őrszem – guard a feltétel maga is az objektum állapotára utal, de ezt nem jelöljük külön névvel a feltétel megadása: szögletes zárójelek [feltétel] között az esemény neve után az objektum egy adott állapotából vagy egy esemény hatására vagy automatikus átmenettel csak akkor vált át az átmenet által meghatározott állapotba, ha teljesíti az őrszemként megadott feltételt, vagyis ha az átmenet feltételhez van kötve, az állapotváltás csak az esemény bekövetkezése ÉS a feltétel igaz értékének bekövetkezése esetén történik meg a feltétel hamis értéke esetén az állapot nem változik

434 Feltétel – példa folytatása egy adott állapotból csak egy átmenet vehető ki, következhet a példában a checking állapotból három átmenet látható –ha nincs minden tétel ellenőrizve, megkapva/elérve a következő tételt visszatérünk a checking állapotba, hogy azt ellenőrizzük –ha minden tételt ellenőriztünk és azok mindegyike raktáron is az objektum a dispatching (a rendelés feladása) állapotba kerül –ha minden tételt ellenőriztünk, de nem mindegyik van raktáron az objektum a waiting állapotba kerül

435

436 Az order különböző állapotait bemutató állapotdiagram a példában csak egy akció van: „/ get first item”, elsőként ezt az akciót kell végrehajtani a checking állapotba való belépéshez a checking állapotban az objektum „check item” tevékenységet végez az állapottal kapcsolatban levő tevékenység szintaxisa: –do/activity – „do/check item”

437 Tevékenységek/activities az állapotokhoz megadhatók végrehajtandó tevékenységek - az objektumok meghatározott ideig vannak egy adott állapotban, eközben különböző tevékenységeket végezhetnek a tevékenységek végrehajtása időt vesz igénybe, tehát a tevékenységekhez időtartam tartozik a tevékenyek végrehajtása alatt az állapot nem változik

438 Tevékenységek, akciók „akció” – az átmenettel kapcsolatban –az objektum által végzett elemi műveletek „tevékenység/activity” – az állapottal kapcsolatban –elemi műveletekből álló tevékenységek mindkettő eljárás, művelet, amelyek az objektum metódusaként implementálhatók, a példában tipikusan néhány metódussal lesznek implementálva az order-on

439 tevékenységek, akciók: a rendszer működtetése során végrehajtandó feladatok, műveletek tevékenységek olyan műveletek: –összetettebbek, további lépésekre bonthatók –események által megszakítható tevékenységek a végrehajtás folyamatában –az elemi műveletekből (akciók) álló tevékenységek elvégzéséhez meghatározott időre van szükség – ezért az állapotokhoz kapcsolhatók akciók olyan pillanatnyi műveletek: –a funkció-hierarchia legalsó szintjén elhelyezkedő elemi műveletek un. atomi műveletek - további lépésekre nem bonthatók –nem szakíthatók meg, nem rendelünk hozzájuk időtartamot – ezért az átmenethez kapcsolhatók –pl. számítási műveletek, objektum manipulálására vonatkozó kérések stb. Tevékenységek, akciók

440 Akciók az állapotokkal kapcsolatban többféle akció különböztethető meg, az állapothoz rendelhető: –bemeneti akció – entry action: –kimeneti akció – exit action –belső akció – internal action

441 Bemeneti akció – entry action entry/ jelölés után adható meg az állapotba történő átváltás (és így a tevékenység) előtt hajtódik végre azt az esetet rövidíti, amikor az állapotba vezető minden átmenet esetén azonos tevékenységet akarunk végrehajtani

442 Kimeneti akció – exit action exit/ jelölés után adható meg az állapotból történő kilépés után hajtódik végre azt az esetet rövidíti, amikor az állapotból kivezető minden átmenet esetén azonos tevékenységet akarunk végrehajtani

443 Belső akció – internal action esemény/művelet jelöléssel adható meg – az esemény nevét követő perjel után adjuk meg a végrehajtandó akció nevét egy adott esemény egy akciót vált ki anélkül, hogy az állapot megváltozna olyan átmenetek rövidítése, amikor az állapotból kiinduló, az eseménnyel címkézett él ugyanabba az állapotba tér vissza, de ekkor nem hajtódik végre sem kimeneti, sem bemeneti akció, mivel az objektum ugyanabban az állapotban maradt

444 Tevékenységek, akciók UML igazán nem tesz köztük különbséget, mégis lehet következtetni, hogy elemi műveletről vagy tevékenységről van szó –de a tevékenységekhez pl. hozzájuk kapcsolhatók belépési pontok, kilépési akciók –az állapothoz tartozó tevékenységet félbeszakíthatja egy külső esemény, azonban a kimeneti tevékenység ekkor is végrehajtódik – akció nem szakítható félbe, mert nem rendelkezik időtartammal

445 Az order különböző állapotait bemutató állapotdiagram start self-transition transition activity state

446 Példa folytatása waiting állapothoz nincsenek megadva végrehajtandó tevékenységek az adott order objektum a waiting állapotban tartózkodik egy esemény bekövetkezésére várva a waiting állapotból két kimenő tranzakció mindegyikéhez a item received esemény tartozik, ami azt jelenti, hogy az order addig vár, amíg nem észleli az eseményt, vagyis az esemény bekövetkezésére vár az order kiértékeli az átmeneten levő feltételeket, majd végrehajtja a megfelelő tranzakciót –vagy visszamegy a waiting állapotba –vagy az order a feltételek kiértékelésének eredményeként a dispatching állapotba kerül

447 A waiting állapot

448 A dispatching – foglalás állapot az állapotban meg van adva egy végrehajtandó tevékenység: –do/initiate delivery – szállítás elindítása létezik továbbá egy feltétel nélküli átmenet – a delivered eseménnyel triggerelve ez azt jelzi, hogy az átmenet mindig bekövetkezik, amikor ez az esemény bekövetkezik azonban, az átmenet nem következik be, ha a tevékenység befejeződött ha egyszer initiate delivery tevékenység kész, befejezett, az adott order egészen addig marad a dispatching állapotban, amíg a delivered esemény be nem következik

449

450 A cancelled átmenet a rendszernek lehetőséget kell adni arra, hogy a rendelési folyamat bármely pontjában töröljük a megadott rendelést, mielőtt az szállításra kerülne megoldás: mindegyik állapotból: –checking, waiting, dispatching biztosítunk egymástól elkülönített átmeneteket

451

452 Szuperállapot az állapotok finomíthatók alállapotokkal – a logikailag összetartozó állapotokat érdemes egy nagyobb egységbe összefogni és ebben az egységben kezelni a példában hasznosabb lehet létrehozni a három állapotnak egy szuperállapotát, majd ebből megrajzolni egyetlen cancelled átmenetet egyfajta öröklődési hierarchia, az alállapotok öröklik a szuperállapot átmeneteit (a példában a cancelled átmenetet), ha azt nem definiálják át egy szuperállapotban levő objektum lehet a szubállapotok bármelyikében

453

454 Szubállapotok a szubállapotok egy meghatározott szuperállapoton belül: –szekvenciálisan követik egymást: diszjunkt állapotok a szuperállapotot egy adott időpontban az alállapotok közül mindig csak egy határozza meg, vagy –párhuzamos kapcsolatban lehetnek egymással – konkurens szub-állapotok

455

456 Konkurens állapot diagram műveletsorok, amelyek párhuzamosan végezhetők egymással a párhuzamos állapotfolyamok mindegyikének külön állapota van - az egy szuperállapotba zárt, konkurens állapotgépeknek saját induló és végállapotaik vannak a szuperállapot akkor következik be, amikor a benne levő összes párhuzamos folyam befejeződik, vagyis eléri a végállapotot – ha valamelyik előbb fejeződik be, az vár hasznos: ha egy objektumnak vannak egymástól független viselkedéscsoportjai

457 Konkurens állapot diagram törekedjünk minél kevesebb konkurens szubállapot kialakítására ha túl bonyolult egy objektumhoz tartozó konkurens állapot diagram, érdemes az objektumot további objektumokra szétszedni, szétválasztani példában az order állapotai: –egyrészt a rendelési tételek elérhetőségén alapulnak, –másrészt léteznek olyan állapotok is, amelyek viszont a fizetés engedélyezésén alapulnak

458 Példa az authorzing állapotban végrehajtásra kerül a check payment tevékenység a tevékenység egy signal-lal fejeződik be, hogy a payment az helyes ha a payment OK, a feltétel igaz értékkel fejeződik be, akkor az adott order objektum addig vár az authorized állapotban, amíg a delivered esemény be nem következik ha a feltétel nem igaz az order bekerül a rejected állapotba

459 Payment authorizing - fizetésengedélyezés

460 Konkurens állapot diagram hasznos: ha egy objektumnak vannak egymástól független viselkedéscsoportjai példában az order állapotai: –egyrészt a rendelési tételek elérhetőségén alapulnak, –másrészt léteznek olyan állapotok is, amelyek viszont a fizetés engedélyezésén alapulnak –ha az authorizing állapot check payment tevékenysége sikeresen befejeződött, az adott order a checking és az authorized állapotba kerül –ha a cancel esemény bármikor bekövetkezik, az order csak a cancelled állapotban lesz –a párhuzamos folyamatok mindegyikének befejeződése után a műveletsor kilép a szuperállapotból és a végrehajtás ismét egy ágban fog folytatódni

461

462 Az állapot diagram alkalmazása egyetlen objektum viselkedését akarjuk leírni több use case-en keresztül a gyakorlatban legtöbb osztálynak nincs állapot diagramja, mert például egyszerű kisegítő un. utility osztályok csak a markánsan dinamikus osztályokhoz készítünk állapot diagramokat – gyakorlatban a UI és control osztályokhoz érdemes

463 Állapottérképek elemei Állapot (Állapotátmenet) Emlékező állapot (history) Feltétel Kezdőállapot Végállapot Állapotcsonk StateName H s1s2 H* s1

464 Emlékező állapot olyan állapot, amelyik emlékszik arra, hogy melyik alállapotból terminált, és képes arra, hogy az állapotba való újabb belépéskor ugyanabba az állapotba kerüljön megszakitas újrakezdés

465 Állapot-átmenet diagram 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

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

467 Ö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 absztrakciós 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)

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

469 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 állapot-specifikus információkkal - az egyes állapotokban hogyan kell a műveletnek viselkednie Az állapotokat gyakran attribútumok reprezentálják –Az állapot-diagram jó segítség az attribútumok definiálásához