UML-alapú fejlesztés

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.

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.

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

Szoftverfejlesztési folyamat 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) A szoftverfejlesztési folyamat jól definiált, különálló lépésekre, un. fázisokra bontja a végrehajtás menetét. A fejlesztési lépések végrehajtási sorrendjét különböző szoftverfejlesztési modellek írják le. A szoftverfejlesztési modellek egyik legismertebb, korai modellje a vízesés modell, amely a szoftverfolyamat fázisainak szekvenciális végrehajtását javasolja

Vízesés modell

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. Rendszerfejlesztés – System Eng. Software eng.

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

Eljárások 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.

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. Mutassuk meg a munkatársakat!

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.

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. Mutassuk meg a termékeket!

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. Unified Process: Elmélet, a tevékenységek, termékek leírása Rational Unified Process Termék, a Unified Process egyik megvalósítása Hatalmas tudásbázis kézreálló (HTML) formában Kiegészítő munkafolyamatokkal, sablonokkal, eszköz-támogatásokkal

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.

A RUP szerkezete idő (mikor, milyen sorrendben?) tartalom (mit kell végrehajtani?) A fejlesztés két dimenzióval írható le: Idő alapján, a dinamika szempontjából a fejlesztés minden ciklusa fázisokra bomlik, minden fázis egy vagy több iterációból áll. Az eljárás elemei, statikus szempontból az elkészítendő dokumentumok illetve kódok alapján oszthatjuk fel munkafolyamatokra, amelyek meghatározzák az egyes termékek előállításához szükséges tevékenységeket. Minden fázis minden iterációjában mindenféle tevékenységet végzünk, csak ezek mennyisége változik a fázisoktól függően. (Az elején sok követelményelemzés és kevés - de van - az implementáció.

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. + Alkalmazás vázlatos modellje, amelyet egymás utáni lépésekkel finomítunk Alternatíva: a programrészletek teljes számítógépes megvalósítása, majd a részletek egybeépítése Objektumorientált modellezés: az összes lépés az objektumorientált fogalomvilág segítségével A MIT (követelményrendszer) és NEM A HOGYAN (kód, függvény, utasítás) a lényeges Előnyök: Áttekinthetőbb Főleg a diagramokat használó grafikus modellek A modell az alkalmazás elkészítése előtt tesztelhető Megrendelővel való egyeztetésre használható - nem igényel informatikai ismereteket a megértése Könnyebben módosítható - magasabb absztrakciós szint 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.

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. OMG: iparági támogatás

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

A RUP szerkezete idő (mikor, milyen sorrendben?) tartalom (mit kell végrehajtani?) A fejlesztés két dimenzióval írható le: Idő alapján, a dinamika szempontjából a fejlesztés minden ciklusa fázisokra bomlik, minden fázis egy vagy több iterációból áll. Az eljárás elemei, statikus szempontból az elkészítendő dokumentumok illetve kódok alapján oszthatjuk fel munkafolyamatokra, amelyek meghatározzák az egyes termékek előállításához szükséges tevékenységeket. Minden fázis minden iterációjában mindenféle tevékenységet végzünk, csak ezek mennyisége változik a fázisoktól függően. (Az elején sok követelményelemzés és kevés - de van - az implementáció.

Munkafolyamatok

Mérnöki munkafolyamatok Támogató munkafo-lyamatok 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

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. NÉZZÜK MEG A RUP-BAN! Induljunk ki az előző ábrából, mutassuk meg a browsert és nézzünk bele valamelyik workflow-ba.

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.

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.

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.

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.

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. Mutassuk meg a munkatársakat!

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. Mutassuk meg a termékeket!

Fázisok és iterációk

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

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

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

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

Á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

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.

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.

Iterációk Vízesés Iteratív - 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”

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

Az iterációk tervezése kritikus feladat a projekt tervezése során. 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.

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

A RUP szerkezete idő (mikor, milyen sorrendben?) tartalom (mit kell végrehajtani?) A fejlesztés két dimenzióval írható le: Idő alapján, a dinamika szempontjából a fejlesztés minden ciklusa fázisokra bomlik, minden fázis egy vagy több iterációból áll. Az eljárás elemei, statikus szempontból az elkészítendő dokumentumok illetve kódok alapján oszthatjuk fel munkafolyamatokra, amelyek meghatározzák az egyes termékek előállításához szükséges tevékenységeket. Minden fázis minden iterációjában mindenféle tevékenységet végzünk, csak ezek mennyisége változik a fázisoktól függően. (Az elején sok követelményelemzés és kevés - de van - az implementáció.

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

Ü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

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

Üzleti modellezés

Üzleti modellezés 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.

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

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

Üzleti modellezés - tevékenységek

Üzleti modellezés - termékek

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

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

A szakterület folyamatai (üzleti folyamat diagram) (Diplomáztatás esettanulmány) Az üzleti folyamat diagram (vagy aktivitás diagram) a szakterület folyamatait, az azokhoz kapcsolódó eseményeket, input és output termékeket, információkat mutatja. A fenti ábra a Diplomáztatás esettanulmány átfogó folyamatmodellje, a kiemelt rész a második nagy tevékenység-csoportot mutatja be.

Szakterületi modell (Diplomáztatás esettanulmány) A szakterületi modell már a fejlesztés kezdeti szakaszában elkészíthetjük. Célja a szakterület megismerése során feltárt meghatározó elemek fogalmi szintre emelése, és kapcsolataik, szerepeik megfogalmazása. A meghatározó elemek az aktor és az entitás jellegű objektumok, melyek döntő szerepet játszanak a szakterület működésében. A modell lényeges jellemzője, hogy programozási elemet nem tartalmaz, kizárólag a vizsgált terület valós elemeit ábrázolja. Mint látható, az egyes elemekkel kapcsolatban célszerű azok fontos jellemzőit is megjelölni – ez segít a modell megértésében, olvasásában. Részletesebben: 3. előadás A fenti diagram olvasata: A szerző elkészíti és beadja diplomatervét. Ha saját maga választott konzulenst, az már ebben a szakaszban is közreműködik. A tanszéki felelős a tervet elbírálja, és ha megfelelőnek tartja, nyilvántartásba veszi, konzulenst jelöl ki (ha nem volt). Az elfogadott terv alapján a szerző a konzulens segítségével kidolgozza a diplomamunkát. A diplomamunkához a szerző valamilyen fejlesztő eszközt használ. A szerző a kész munkát beadja a tanszékre, ezt a tanszéki felelős regisztrálja, majd kiadja a diplomamunkát bírálatra egy általa kijelölt bírálónak. A bírálat elkészültét szintén regisztrálja.

Követelmény (elemzés)

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

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

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.

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.

Követelményelemzés

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.

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.

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.

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.

Követelmények feltárását, összegyűjtését segítő technikák 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 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.

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 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. Felhasználói és rendszerkövetelmények 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. A felhasználói követelményeknek a rendszer funkcionális és nem funkcionális követelményeit kell úgy leírniuk, hogy bárki megértse azokat. Célszerűen a rendszer külső viselkedését írják le, és nem térnek ki a belső működés jellemzőire. A felhasználói követelmények leírásánál a kulcsfontosságú igényekre kell koncentrálni. A megfogalmazott követelményeket rövid magyarázó szöveggel látjuk el. Rendszerkövetelmények Rendszerkövetelmények (a felhasználói követelmények részletezése és lebontása). A rendszerszolgáltatások és megszorítások részletes, a felhasználói követelményekhez (is) kapcsolódó leírása – funkcióspecifikáció. Az egész rendszer teljes meghatározását tartalmazza, a rendszerterv kiindulási pontja lesz. Tartalmazhat objektummodelleket, adatfolyam modelleket, stb. Funkcionális és nem funkcionális követelmények A követelményeket sokszor célszerű abból a szempontból is vizsgálni, hogy a rendszer működésére vagy a működést befolyásoló egyéb követelményekre vonatkoznak-e. Ebből a szempontból megkülönböztetünk: funkcionális követelményeket: 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. nem funkcionális követelményeket: A rendszer funkcióival és szolgáltatásaival kapcsolatos megszorítások (időbeli korlátozások, szabványok, hardver és szoftverkörnyezeti előírások, teljesítménykövetelmények, stb.). 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. 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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

Tesztelés követelmények alapján

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.

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

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.

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.

Szoftvertesztelés alapsémája

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.

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

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.

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.

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

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.

Ú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

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.

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

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.

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.

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.

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

Use case modell elemei - Aktorok

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Use case modell elemei – Use Case-ek

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.

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.

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?

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.

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

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;

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

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.

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.

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

Munkafolyamat

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

A rendszer hatáskörének kezelése 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

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.

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

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

A rendszer definíciójának finomítása 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.

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

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

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. Például: ATM, Pénzfelvét használati eset: „Az ügyfél által felvenni kívánt összeget összehasonlítjuk a számlaegyenleggel. Ha az egyenleg kisebb ennél az összegnél, akkor erről informáljuk az ügyfelet és a használati eset véget ér. Egyébként …”

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. Nincs előzménye a 3 amigo munkásságában Jim Odell - eseménydiagram SDL Petri hálók Rose-ban is új.

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.

Use case leírás Normál működés: Alternatív esetek: 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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

Aktivitási diagram

Aktivitási diagram

Aktivitási diagram 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).

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.

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

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

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. Valamilyen tevékenység, amit meg kell csinálni Koncepcionális szinten (most ott tartunk) Valamilyen osztály egy művelete lesz belőle Specifikációs, implementációs szinten

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

műveletek (tevékenységek, akciók) Start, kezdőpont átmenet start Rendelés érkezik Fizetés ellenőrzése Raktárkészlet ellenőrzé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 ] műveletek (tevékenységek, akciók)

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

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

[ utánrendelés szükséges ] start Rendelés érkezik Fizetés ellenőrzése Raktárkészlet ellenőrzé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 ]

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

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)

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

Use case modell elemei - Kapcsolat

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.

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

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

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 <<communicate>> sztereotípiával jelölhetjük.

Példa

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.

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

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

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

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

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

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

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.

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.

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 <<include>> sztereotípiával jelöljük.

Tartalmazás – include viszony

Tartalmazás – include viszony

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.

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.

Kiterjesztés – extend viszony

Kiterjesztés – extend viszony

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

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

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

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

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

Use case diagram

Use case diagram 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.

Use case diagram Alkalmas: Eszköz: 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.

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

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.

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.

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.

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

Use case Követelményspecifikáció: Elemzés/tervezés: 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.

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

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

Követelményelemzés - termékek

Használati eset modell Használati eset diagram (Diplomáztatás esettanulmány) Használati eset modell A használati eset modell használati eset diagramok és definícióik halmaza. Közepes vagy nagyobb rendszerek esetében célszerű az alrendszerek szerinti modularizálás alkalmazása, melyet az UML csomag-technikája támogat. A használati eset a rendszer és a felhasználó egy jól elkülöníthető, önálló, szakterületi célt megvalósító interakciója. Másként fogalmazva, a használati eset egy olyan felhasználói funkcionális követelmény, amelyet a rendszernek teljesítenie kell. Az elemzés-tervezés folyamán a rendszervízió szintjén megfogalmazott alapvető, kezdeti használati eseteket rendszer-használati esetté fejlesztjük. Ez azt jelenti, hogy a használati esetek pontosabbá, dokumentálttá válnak. Megjelennek új használati esetek, és köztük kapcsolatok tárulnak fel. Pontosan leírjuk céljukat, működésüket és az ehhez szükséges belső, illetve felhasználói felület objektumokat. A használati esetek elemzéséhez felhasználhatunk objektumdiagramokat, szekvencia diagramokat és aktivitás diagramokat. A használati eset modellel megvalósítható a rendszer alapvető modularizálása, és egyben megadja a rendszer határait is: vagyis mi az, amit a fejlesztés során meg kell valósítanunk, és mi az, amit nem. A használati esetek legfontosabb kapcsolatai az aktorral szemben állnak fenn. Aktor az a személy vagy szoftver, amely a rendszerrel szemben kezdeményezőleg lép fel, szolgáltatást vár el attól. A használati esetek között is értelmezünk kapcsolatokat, melyek lehetnek: extend, include és specializációs kapcsolatok. Ezek a kapcsolatok a használati esetek összefüggéseit, együttműködését írják le.

V.2. Elemzés - tervezés

Robosztus architektúra kialakítása 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

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.

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.

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.

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

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

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

Tervezés fázisai Architektúra kialakítása: Részletes tervezés: 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.

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

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

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

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

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. 317 es dia

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

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.

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.: <<system>>) Láthatóság Tesztelés egysége is lehet Adattipusok global <<rendszer>> Alkalmazas Reteg <<modell>> UzletiReteg Nagyméretű rendszerek esetén nélkülözhetetlen

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

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 (<<use case realization>>) a tervezési modellben (név ugyanaz.)

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.

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.

Üzenetek A use case funkciója: Az üzenetek: 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.

Use case realizáció

Példa I.

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

Konferencia felvitele Use Case realisation

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.

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

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

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.

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

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

<<boundary>> osztályok A rendszer és környezete közötti kommunikációért felelősek, gyakorlatilag valamilyen protokollt valósítanak meg. Típusok: Felhasználói felület osztályai - rendszer és ember Kommunikációs osztályok - rendszer és rendszer Eszközök reprezentánsai - rendszer és külső eszköz (pl.: szenzor)

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

<<entity>> osztályok Információ-tárolás és kezelés Alapfogalmak, amivel a rendszer foglalkozik Az objektumok általában passzívak (nem kezdeményeznek) és perzisztensek (a példányaik tárolásra kerülnek) Nézzük a fogalomszótárt az entitások keresésekor Példa:

<<control>> osztályok A rendszer viselkedését koordinálják. Egyes használati esetekhez felesleges - ha nagyon egyszerű manipulációról van szó, akkor a boundary és az entity osztályok ezt önállóan elvégezhetik. Általában azonban egy vagy több vezérlő osztály tartozik egy használati esethez tranzakció-kezelés erőforrás-kiosztás Hibakezelés.

<<control>> osztályok A vezérlő osztályok hatékonyan választják el az interfészeket és az entitásokat  jobb változás-tűrés, újrafelhasználhatóság Vannak olyan feladat, amely nem lehet egyetlen entitás példány feladat sem, ezért ott a vezérlő osztályok létrehozása szükséges (példányok darabszámának meghatározása) Példa: Vezérlő osztályok biztosította viselkedés: Környezet-független (nem változik, amikor a környezet változik) A vezérlési logikát (események sorrendjét) és a tranzakciókat definiálja Csak kissé változik, ha az entitások belső szerkezete vagy viselkedése megváltozik Egyszerre több entitással is foglalkozhat, azokat ilyenkor koordinálni kell Nem mindig ugyanúgy működik, hanem a használati esetben definiált alternatíváknak megfelelően

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.

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.

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.

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.

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.

Szekvencia diagram

Szekvencia diagram 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.

Szekvencia diagram Az objektumokat (nem osztályokat) függőleges vonalak reprezentálják. A vonal akkor kezdődik, amikor az objektum létrejön és akkor fejeződik be, amikor az objektum megszűnik. Az események, üzenetek vízszintes címkézett nyilak az objektumok között. Az idő fentről lefelé halad.

Példa - hívjuk fel a tudakozót 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 tárcsahang vége csöngetés vége csöngetés Idő

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

Szekvencia diagram Időpont megjelölés: Jelezni lehet azt az időpontot, amikor egy üzenet elindul vagy megérkezik Az időpontot jelölő szimbólumokat időzítési feltételekben lehet használni (A szabvány szerint az üzenetnek lehet rövid nevet adni és ezt lehet meghivatkozni az időzítésre vonatkozó megszorításokban, például msg.sendTime(), msg.receiveTime() stb... )

Szekvencia diagram - Időzítés Hívó 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

Együttműködési diagram

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

Együttműködési diagram elemei I. Az együttműködésben objektumok vesznek részt. Objektum speciális előfordulási formái a diagramon: Multiple instance Egy-több kapcsolat több oldalán álló objektumokat jelképezi Active object Az objektum saját szállal rendelkezik és önállóan képes a működésre Az objektumba írható szöveg: „objektum neve” / „minősítő szerepkör” : „minősítő” [‘.’ „minősítő”]*

Együttműködési diagram elemei II. Üzenetek: címkézett vonal, a szöveghez rendelt nyíl jelzi az üzenet irányát több üzenet is tartozhat ugyanahhoz a kapcsolathoz. A nyilak alakja fontos jelentéssel bír (UML 1.3): Eljárás hívás, beágyazott hívás Egyszerű szekvencia, általában aszinkron Aszinkron végrehajtás Eljárás visszatérése

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

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

Együttműködési diagram Egyéb elemek az üzenet-címkén Sorszám az iterációt *-gal jelöljük (*[feltétel]). Jelentése: ugyanolyan formájú üzenet többször megy el feltétel is megfogalmazható ( [feltétel]) Az üzeneteknek lehet paraméterlistája A visszatérési érték a speciális üzenet neve

Együttműködési diagram Az egymástól vesszővel elválasztott sorszámok listája ([sorszám, sorszám]) azt jelzi, hogy párhuzamos végrehajtás esetén az üzenet mely üzenetek után következhet. (Szálak szinkronizálása)

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

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

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

Mintapélda - KonfMan

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 (<<use case realization>>) a tervezési modellben (név ugyanaz.)

Mintapélda – SWE Product

Use Case realizáció

Aktivitási diagram

Szekvencia diagram az elemzési szakaszban

Szekvencia diagram a tervezési szakaszban

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.

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

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

Műveletek csoportosítása Lekérdezés (query): mindössze értékeket kér le nem változtatja a megfigyelhető állapotot (observable state) tetszőleges sorrendben végrehajthatók Módosító (modifier) Végrehajtása után van olyan művelet, amelynek a végrehajtása nem ugyan azzal az eredménnyel jár, mint előtte. Ez tehát a megfigyelhető állapotot módosítja. Ezek végrehajtási sorrendje nem közömbös és ha tranzakció kezelésre kerül a sor, akkor ezekre kell figyelni.

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

Elemzési osztályok felelősségei Szolgáltatások felfedezése: Az interakciós diagramok üzeneteiből. Vizsgáljuk meg az üzeneteket, és döntsük el, hogy a címzettnek van-e már olyan szolgáltatása, ami ehhez az üzenethez kell. Nem-funkcionális követelményeket figyelembe kell venni! (Bővítsük a leírást a nem-funkcionális követelményben előírtaknak megfelelően, vagy definiáljunk új szolgáltatást, ami segíti a kielégítését.) Dokumentálás: Rövid név Rövid leírás: mit csinál az objektum a szolgáltatás végrehajtása érdekében, és mit ad vissza Példa nem-funkcionálisra: - 5 másodpercen belül meg kell jelennie - simán leírjuk, hogy majd az algoritmus tervezésekor figyeljünk rá - nem lehetnek duplikált ügyfelek - csinálunk egy új szolgáltatást, ami mindig ellenőrzi, hogy van-e már ilyen ügyfél

Példa - IQTAR Tanfolyami jelentkezés : DlgLogin : Ugyfel : Frm Jelentkezes : Tanfolyam UML : Tanfolyam UML19990301 : TanfolyamiIdopont Regisztracio : Regisztracio : Jelentkezes Vezerles Beír "név", "jelszó" Megnyomja "OK" Kiválaszt "UML" Kiválaszt "1999.03.01" Jóváhagy megjelenít( ) "Regisztráció" ugyfelKereses("név", "jelszó") tanfolyamLista( ) idopontLista( ) letrehoz( ) kiirTanfolyamLista( ) kiirIdopontLista( ) Van ilyen ügyfél vanSzabadhely( ) Logical View/Design Model/Use Case Realizations/Jelentkezés tanfolyamra/Jelentkezés tanfolyamra/

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

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

Használati esetek elemzése / Attribútumok és asszociációk leírása Másik oldalról: Ha az információnak komplex viselkedése van, ha az információn két vagy több osztály osztozik, esetleg referenciaként közlekedik két vagy több osztály között, akkor ÖNÁLLÓ osztályként kell modellezni.

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

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

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

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

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

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

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.

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.

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.

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)

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

Példa - Tanfolyami jelentkezés : DlgLogin : Ugyfel : Frm Jelentkezes : Tanfolyam UML : Tanfolyam UML19990301 : TanfolyamiIdopont Regisztracio : Regisztracio : Jelentkezes Vezerles Beír "név", "jelszó" Megnyomja "OK" Kiválaszt "UML" Kiválaszt "1999.03.01" Jóváhagy megjelenít( ) "Regisztráció" ugyfelKereses("név", "jelszó") tanfolyamLista( ) idopontLista( ) letrehoz( ) kiirTanfolyamLista( ) kiirIdopontLista( ) Van ilyen ügyfél vanSzabadhely( ) Logical View/Design Model/Use Case Realizations/Jelentkezés tanfolyamra/Jelentkezés tanfolyamra/

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

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

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

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

Műveletek csoportosítása Lekérdezés (query): mindössze értékeket kér le nem változtatja a megfigyelhető állapotot (observable state) tetszőleges sorrendben végrehajthatók Módosító (modifier) Végrehajtása után van olyan művelet, amelynek a végrehajtása nem ugyan azzal az eredménnyel jár, mint előtte. Ez tehát a megfigyelhető állapotot módosítja. Ezek végrehajtási sorrendje nem közömbös és ha tranzakció kezelésre kerül a sor, akkor ezekre kell figyelni.

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

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

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

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

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.

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

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.

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

Multiplicitás Hány objektum vehet részt az asszociációban. 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.

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 22.. 44: 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ó.

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.

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.

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.

A kapcsolatok implementálása

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

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

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

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.

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

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

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

Példa - asszociációkra Cég Személy Alkalmazás munkaadó munkavállaló * {ordered} Csúcspont Poligon 0..n 0..n 1 1

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.

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

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

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

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

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

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

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.

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.

Specializáció - Példa

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

Öröklődési hierarchia

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.

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

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ó

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.

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.

Aggregáció

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.

Kompozíció

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.

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.

Minősített asszociáció

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

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.

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

Asszociációs osztály

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.

Származtatott elemek

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.

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

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.

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.

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.

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

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.

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.

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.

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

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 * Szerepkör Fonök <<Interface>> Beosztott 0..n Megvalósít

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

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.

Osztály diagram

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.

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

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.

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.

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.

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

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

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

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ó

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.

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

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.

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.

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.

CRC kártya

CRC kártya Ixtlan Software

Elemzési osztályok egységesítése Az elemzési osztály neve: fejezze ki azt a szerepet, amit az adott osztály a rendszerben játszik legyen egyedi, szinonimák sem megengedettek Vonjuk össze: a hasonló viselkedésű, azonos szerepű osztályokat azokat az entitásokat (<<entity>> osztályokat), amelyeknek azonosak 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) Cél: Minden elemzési osztály egyetlen jól-definiált fogalmat takarjon anélkül, hogy a szolgáltatások átfednék egymást. Ne maradjon felfedezetlen osztály

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

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

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

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

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.

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

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…

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

Komponensek tervezése

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

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

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

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

Részrendszerek tervezése Dokumentáljuk az alrendszerek közti függéseket: Amikor az alrendszerünk egy eleme egy másik alrendszerben lévő elemet használ, akkor függ attól a másiktól Fizetési Ütemezés Számlázás Elvileg: A függés kifejezhető az alrendszerek közötti függés ábrázolásával A függést kifejezhetjük az az interfészek közti függéssel is A tervezőnek teljes szabadsága marad az alrendszer belső szerkezetének tervezésekor, mindaddig, amíg a külső viselkedést (amit az interfész ír le) biztosítja. De nem fejezhetjük ki az elemek közötti kapcsolatokkal Rose-ban nem lehet csomagos interfészt rajzolni!

Osztályok tervezése - lépések Tervezési osztályok kialakítása típusonként, perzisztens osztályok azonosítása Részletes tervezés Az osztályok láthatóságának meghatározása Műveletek, 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

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

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

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

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

Felhasználói felület modellje A tervezés során a modellezési konvenciónak a megvalósító környezet fogalmai szerint kell megjeleníteni a szerkezetet. Ezt az architektúrális tervezés szakaszában kell kialakítani! tblTanfolyam <<column>> név : String <<column>> tematika : Long String <<event>> doubleClick() <<tablewindow>> tlbTanfolyamIdopont <<column>> tanfolyam kezdete : Date <<column>> tanfolyam vége : Date <<column>> oktatók : String frmJelentkezo <<datafield>> név : String <<datafield>> cím : Long String <<datafield>> telefonszám : String <<datafield>> cégnév : String <<button>> regisztráció()

Osztályok tervezése / <<Entity>> osztályok Általában passzívak és perzisztensek Perzisztens: képes az állapotát tárolni valamilyen háttértáron Lehetnek perzisztens és tranziens példányai a perzisztensnek jelölt osztályoknak is Az adatbázis tervezés során kell őket figyelembe venni Perzisztens osztályok nemcsak <<Entity>> osztályokból keletkeznek, hanem például folyamat- vagy tranzakció-vezérlő osztályokból is (nem-funkcionális követelmények) A perzisztens elemzési mechanizmust megvalósító tervezési mechanizmus lehet: In-memory tárolás Flash card Bináris állomány DBMS Attól függően, hogy az osztálynak mire van szüksége

Osztályok tervezése / <<Control>> osztályok A használati esetek végrehajtásáért felelősek, azt a logikát tartalmazzák, ami nem a <<Boundary>> és nem az <<Entity>> osztályokhoz tartozik  alkalmazási logika vagy üzleti logika A tervezésük során figyelembeveendő szempontok: 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

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á

Osztályok tervezése / Műveletek definiálása Vegyük sorra az elemzési osztályok szolgáltatásait, és mindegyikhez definiáljunk egy műveletet A szolgáltatás leírása alapján készítsük el a művelet első leírását Nézzük meg azon használati eset megvalósításokat, amelyekben az osztály részt vesz, így pontosíthatjuk a művelet definícióját, paramétereit, visszatérési értékét, leírását A használati esetben megfogalmazott nem-funkcionális követelményeket is vegyük figyelembe

Osztályok tervezése / Műveletek tervezése A használati eset megvalósítá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) A szimpla get/set műveleteket majd a generátorok létrehozzák, nem kell a modellt bonyolítani velük.

Osztályok tervezése / Műveletek tervezése Minden művelethez meg kell adni: A művelet neve: rövid, de kifejező név (mit fog a művelet eredményezni) 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! )

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

Osztályok tervezése / Műveletek tervezése A művelet algoritmusa (method): hogyan hajtódik végre a művelet (nemcsak mit csinál) Hogyan kell a műveletet 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.

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!

Állapot-átmeneti diagram

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

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

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

Á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 1994 - Booch is beépítette módszertanába - second edition

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

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:

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

Állapotok leírása 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.

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

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

Á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

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

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

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

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

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

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

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”

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

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

Tevékenységek, akciók 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.

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

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

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

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

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

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

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

A waiting állapot

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

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

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

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

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

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

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

Payment authorizing - fizetésengedélyezés

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

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

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

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

Á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

Állapot-átmenet diagram - Példa 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 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 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

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

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

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

Példa - Tanfolyami időpont Törölve Inicializálás alatt Nyitott do: Jelentkezõ regisztrálása entry: jelentkezõk számának növelése Jelentkezés / jelentkezõk száma=0 Jelentkezés Megtelt [ jelentkezõk száma=15 ] törlés

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

Osztályok tervezése / Attribútumok Minden attribútumhoz meg kell adni: nevét - az implementációs nyelv szabályai szerint típusát - az implementációs nyelv alaptípusai közül alapértelmezett vagy kezdeti értékét - ezzel az értékkel inicializálódik az attribútum az objektum létrehozásakor láthatóságát: public implementation protected private a perzisztens osztályoknál azt is, hogy az attribútum perzisztens (default) vagy tranziens Ellenőrizzük, hogy minden attribútumra tényleg szükség van e Attribútumok szükségessége: Már az elemzés korai fázisában definiáljuk őket, így könnyen előfordulhat, hogy mellékhatásként bennmaradnak a modellben, holott valójában nincs már rájuk szükség. Az extra attribútumok objektumok ezreiben vagy millióiban jelentősen növelhetik a tárigényét és ronthatják a hatékonyságot

Osztályok tervezése / Függőségek definiálása Minden egyes esetben, amikor két objektum kommunikál, a küldő és a címzett között függőségi kapcsolatot kell használni, ha: Paraméterként jut el a címzetthez a referencia. Az együttműködési diagramon jelöljük meg, hogy a kapcsolat láthatósága a paraméter A címzett globális objektum. Az együttműködési diagramon jelöljük meg, hogy globális a kapcsolat A címzettet a művelet hozza létre és szünteti meg. Az együttműködési diagramon jelöljük meg, hogy lokális a kapcsolat)

Osztályok tervezése / Asszociációk, aggregációk Szorosabb kapcsolat, mint a függőség (Az együtt-működési diagramon a láthatóság mező (field)) Ellenőrizni kell az asszociáció irányítottságát. Alapértelmezésben mindkét osztály objektumai látják a másikat. Ahol erre nincs szükség ott egyirányúvá kell tenni az asszociációt Határozzuk meg, hogy az asszociáció valamelyik oldalán rendezettek-e az elemek ({ordered}) Ha egy osztállyal csak az adott osztálynak van kapcsolata, akkor érdemes megfontolni a beágyazását Beágyazás előnyei: gyorsabb üzenetküldés egyszerűbb modell Hátrányai: Statikusan allokált hely a beágyazott osztályoknak akkor is, ha épp nincs példányuk A beágyazott osztálynak nincs önálló identitása, csak a beágyazott osztályon keresztül érhető el

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

Aggregáció vagy kompozíció Kompozíció: szoros kapcsolat a rész és az egész között, a rész és az egész élettartama szorosan összetartozik az egész megszűntével a rész is megszűnik az egész nem teljes a részek nélkül ha egyszer egy kapcsolat létrejött, nem változtatható meg az egész oldal számossága csak 1 lehet Kompozícióval modellezhetjük az összetett attribútumokat is Attribútum vagy kompozíció Kompozíció, ha Önálló, független létezése is van a tulajdonságnak, sok más objektum is hivatkozhat rá Sok osztálynak vannak ilyen tulajdonságai A tulajdonság maga is összetett, bonyolult SzámlaTétel Számla

Aggregáció vagy asszociáció Aggregáció csak akkor, ha tényleg rész-egész kapcsolatról van szó ha a rész nem értelmes az egész nélkül Asszociáció, ha az osztály a másik oldal nélkül is értelmes, független, önálló létezése van Kétségek esetén asszociációt használjunk!

Real-Time komponensek tervezése

Adatbázis tervezése

Adatbázis tervezése - Cél Tervezés során a perzisztens osztályok meghatározása A perzisztens osztályok tárolására megfelelő adatbázis szerkezet meghatározása A teljesítmény elvárásoknak megfelelő mechanizmusok és stratégiák kidolgozása az adatok tárolására és visszakeresésére

Adatbázis tervezése Kapcsolódó tevékenységek: Osztályok tervezése finomítani kell a tervezési osztályokat a perzisztens adatok kezelésére vonatkozó követelmények, jellemzők megadásával és modellbe integrálásával Adatbázis tervezése a tervezési modell perzisztens adatainak tárolását és visszakeresését reprezentáló adatmodell létrehozása A tervezés szemlézése az elkészített adatmodell megfelelőségének vizsgálata

Adatbázis tervezése A perzisztens tervezési osztályok leképezése adatmodellre Konzisztens és hatékony tárolási struktúra kialakítása Adatelérés optimalizálása Jelenlegi fejlesztéseknél elsődleges fontosságú, mert az adatbázis hordozza magán az üzleti logika jelentős részét Későbbiekben fontos lenne az adatbázis tervezést minél inkább szeparálni

Struktúramodellezés Komponensdiagram (component diagram): Megadja a szoftver fizikai felépítését, vagyis azt, hogy a tervezési elemek szoftver elemekre való leképezését.

Komponens diagram

Struktúramodellezés Telepítési diagram (deployment diagram): Megadja, hogy milyen szoftver elemeket milyen hardverre telepítünk.

Telepítési diagram

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

Elemzés - tervezés - termékek

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

Elemzés - tervezés - termékek

Az üzleti folyamat modell kapcsolata a többi modellel Kapcsolat a használati eset modellel Kapcsolat az elemzési osztálymodellel Kapcsolat a használati eset modellel Az üzleti folyamat modellben feltárjuk a szakterület munkafolyamatait. A modell a teljes szakterület működését feltérképezi, annak összes részfolyamatával együtt. A tervezett alkalmazás ezen folyamatok, vagy a folyamatok egy részének támogatására készül, tehát a szoftverben meg kell jelennie azoknak a funkcióknak, amelyek kapcsolódnak a folyamatokhoz. Másképpen szólva, a szoftverrel szemben funkcionális követelményként jelentkeznek a munkafolyamatokhoz kapcsolódó szoftverfunkciók. Korábban a funkcionális követelményeket használatio eset modellben ábrázoltuk – kézenfekvő tehát, hogy a használati eset modell az üzleti folyamat modellben feltárt folyamatokra, műveletekre épül. Kapcsolat az elemzési osztálymodellel Az üzleti folyamat modell nemcsak folyamatokat, hanem a folyamatokhoz kapcsolódó erőforrásokat és termékeket is tartalmazza. A szakterület ezen objektumai majd a szakterületi, majd az elemzési osztálymodelljeinkben jelennek meg. Az üzleti folyamat modell tehát ezekhez is szolgáltat információkat. Egyéb Azon kívül, hogy az üzleti folyamat modell a fent említett modellek számára input információkat nyújt, jó szolgálatot tehet a rendszerhatárok folyamatos felülvizsgálatánál. A fejlesztés során a rendszer határait folyamatosan ellenőriznünk kell: nem történtek-e olyan követelmény-változások, amelyek módosítják azt, illetve nem tévedtünk-e el a munka során. Kölcsönhatás a modellek között Említettük, hogy az üzleti folyamat modell a használati eset és más elemzési modellek egyik inputja. Ez fordítva is igaz: előfordulhat, hogy az elemzési modellek készítésekor olyan információkhoz jutunk, amelyek a korábbi folyamatmodell módosításához vezetnek.

Diplomaterv elbírálása - részletezés

Elemzési osztálymodell

Elemzési osztálymodell (Diplomáztatás esettanulmány, diagram-részlet) Az elemzési szakaszban az osztálymodellek célja kezdeti elképzeléseink, koncepciónk ábrázolása. A kezdeti modellekben rögzítjük az elemzés során a problémával kapcsolatban szerzett ismereteinket. A tervezési fázisban majd ezen modelljeinket fejlesztjük tovább a megoldás irányába. Az elemzési osztálymodell alapja a szakterületi modell, mellyet itt további részletekkel és újabb elemekkel látunk el. Ebben a modellben már fokozatosan megjelennek a programozási osztályok is, például a felhasználói felület ablakai. Az ablakosztályok esetében a részletek feltüntetését a felhasználói felület terveire hagytuk.

V.3. Implementáció

Implementáció A kód szerkezetének meghatározása az implementációs részrendszerek, rétegek szempontjából Az osztályok, objektumok implementálása A implementált komponensek unit tesztjeinek elvégzése A különálló fejlesztők vagy fejlesztő csoportok eredményeinek integrálása egy végrehajtható rendszerbe

Implementáció Az implementációs modell strukturálása (Structure the Implementation Model) Az implementációs modell szerkezetét úgy kialakítani, hogy a komponensek fejlesztését és a build építés folyamatát a lehető legkisebb konfliktusokkal lehessen végrehajtani. Egy jól szervezett modell megelőzi a konfiguráció kezelési problémákat és megkönnyíti az egyes részek integrációját. Az integráció tervezése (Plan the Integracion) Annak megtervezése, hogy az aktuális iterációban mely részrendszerek kerülnek implementálásra és milyen sorrendben lesznek az implementált részrendszerek integrálva.

Implementáció Komponensek implementálása (Implement Components) Az osztályok implementálása a tervezési modellben meghatározott módon. A forráskódot elkészítése, a meglévő komponenseket alkalmazása, a fordítás, szerkesztés és unit tesztelés elvégzése. A felderített kód hibák kijavítása és újabb unit tesztek elvégzése a változtatások ellenőrzésére. A forráskód minőségének ellenőrzése a kód szemlézése során. A részrendszerek integrálása (Integrate each Subsystem) Az új vagy módosított komponensek integrálása.

Implementáció A rendszer integrálása (Integrate the System) Az integrációs terv alapján a rendszer integrálása. Ennek során az átadott implementációs részrendszereket hozzáadják a rendszer integrációs munkaterülethez és felépítik a build-et. Minden build ezek után integrációs teszten és rendszerteszten megy keresztül.

Implementáció - tevékenységek

Implementáció - termékek

V.4. Tesztelés

Tesztelés Az objektumok közötti kölcsönhatások ellenőrzése Ellenőrizni a rendszer valamennyi komponensének integrációját Ellenőrizni, hogy valamennyi követelmény megfelelően implementálva lett-e A szoftver telepítését megelőzően megkeresni és kijavítani a hibákat

Tesztelés Tesztelési stratégia kidolgozása (Plan Test) A tesztelési stratégia meghatározása, amely később implementálásra és végrehajtásra kerül. A tesztelési stratégia tartalmazza a teszteléssel kapcsolatos követelményeket, tesztelési típusokat, dokumentálási előírásokat és erőforrásokat. A teszttervek elkészítése (Design Test) A tesztelési eljárások és tesz esetek leírása A tesztelés implementálása (Implement Test) A teszttervekben leírt tesztelési eljárások implementálása (rögzítése, generálása vagy programozása), a teszt scriptek elkészítése.

Tesztelés Integrációs teszt végrehajtása (Execute tests in Integration Test Stage) Annak biztosítása, hogy a rendszer komponenseinek együttműködése megfeleljen az elvárásoknak, valamint a rendszer új funkciói a megfelelő módon működjenek. Az újonnan beépített szolgáltatásokat nemcsak funkcionálisan tesztelik, hanem azt is megvizsgálják, hogy a rendszer előző verziójának szolgáltatásai nem romlottak-e el (regressziós teszt). Egy iteráción belül több integrációs teszt végrehajtása, míg a teljes rendszer (amit az adott iterációban célul tűztek ki) össze nem áll. Az iteráció végén a teljes rendszer tesztelése. Itt elsősorban a rendszer és az aktorok közötti kommunikációt vizsgálják.

Tesztelés Rendszerteszt végrehajtása (Execute Tests in System Test Stage) A rendszerteszt célja annak biztosítása, hogy a teljes rendszer az elvárásoknak megfelelően működik. A tesztelés értékelése (Evaluate Test) A tesztelés eredményeinek értékelése, a felhasználói igények változásainak azonosítása és naplózása, a tesztelés mérőszámainak meghatározása. Ezek a tesztelt alkalmazás minőségén túl a tesztelés folyamatát is minősítik.

Tesztelés - tevékenységek

Tesztelés - termékek

V.5. Telepítés

A munkafolyamat a szoftver telepítésének többféle módját fedi le Azoknak a tevékenységeknek a leírása, amelyek ahhoz szükségesek, hogy a szoftver termék elérhető legyen a végfelhasználók számára A munkafolyamat a szoftver telepítésének többféle módját fedi le

Telepítés Telepítés tervezése (Plan Deployment) A telepítési terv elkészítése, amely meghatározza, hogy mikor és milyen módon lesz elérhető a szoftver termék a végfelhasználók számára. Az ügyfelekkel való együttműködés kialakítása, hiszen a telepítési terv elkészítéséhez szükségesek az ügyfelek előkészületei is. Gyakran a szoftver fejlesztésétől független tényezők hátráltatják egy szoftver termék bevezetését, például a hardver infrastruktúra hiánya, vagy a nem megfelelően képzett felhasználók. A rendszer supportjára, a felhasználók képzésére vonatkozó tevékenységek beépítése a telepítési tervbe.

Telepítés A rendszer használatához szükséges eszközök, dokumentációk elkészítése (Develop Support Material) Minden olyan információ biztosítása, amely szükséges a végfelhasználóknak a rendszer telepítéséhez, használatához és karbantartásához. Ide sorolhatjuk a különböző oktatási anyagokat is. Átvételi teszt végrehajtása (Manage Acceptance Test) Annak biztosítása, hogy a fejlesztett szoftver megfelel az átvételi követelményeknek. Ezt a tesztelést a fejlesztés helyén, a fejlesztési környezetben is végre kell hajtani, valamint a telepített terméket tesztelni kell az ügyfél telephelyén is, a cél környezetben.

Telepítés Telepítési csomag kidolgozása (Produce Deployment Unit) A telepítési csomag elkészítése, amely a szoftver mellett azokat a termékeket tartalmazza, amelyek az installáláshoz és a használathoz szükségesek. A telepítési csomag több célból is létrejöhet. Létrehozhatjuk béta tesztelés, vagy végső telepítés céljából. A termék csomagolása (Package Product) A dobozos termék telepítéséhez szükségesek tevékenységek meghatározása. A munkafolyamat során el kell készíteni a telepítési csomagot, az installáló scriptet, a felhasználói kézikönyvet, majd mindezekből elő kell állítani a kész terméket.

Telepítés A termék interneten keresztül történő letöltésének lehetővé tétele (Provide Access to Download Site) A termék megrendelésének és letöltésének lehetővé tétele az interneten keresztül. A termék béta tesztelése (Beta Test Product) Egy béta program előkészítése, amely lehetővé teszi, hogy a fejlesztés alatt álló termékkel kapcsolatban hozzájussunk a potenciális felhasználók visszajelzéseihez. A béta program létrehozása lehet felhasználói igény is.

Telepítés - tevékenységek

Telepítés - termékek

Telepítési modell A telepítési modell bemutatja, hogy a rendszer egyes futási idejű komponenseit milyen hardver-eszközökre kell telepíteni. A telepítési modellnek akkor van jelentősége, ha a rendszer egyes komponenseit más és más hardver-eszközökre (csomópontok) kell telepíteni. Ilyen eset például a hálózat, internet. A telepítési modell megmondja, hogy a rendszer egyes komponenseit mely csomópontokra kell telepíteni, és az egyes csomópontok között milyen típusú kommunikáció folyik.

A modellek kapcsolatai Az elemzési tevékenység célja a szakterület megismerése és a feltárt információk rendszerezett rögzítése. Az elemzés során szerzett ismereteink alapján – a tervezési folyamatban – készítjük el a probléma megoldását. A tervezés során célunk egy olyan logikai modell (osztálymodell) létrehozása, melynek alapján az implementáció elvégezhető. Lényeges vonása azonban a logikai modellnek, hogy nem tartalmaz implementációs döntéseket: Nem határozzuk meg benne a hardver- és szoftverkörnyezeti (pl. op.rendszer) feltételeket. Nem írjuk elő a programozási eszközt, nyelvet. Nem (vagy csak általánosítva) használtunk programozási nyelv függő terminológiát. Nem döntöttünk adatbázis-típusról, tárolási mechanizmusokról. Sok esetben előfordul, hogy a fenti tényezők közül egy vagy több már adott a fejlesztés megkezdése előtt (felhasználói kikötések). Figyeljünk arra, hogy ezek az esetleges előírások, adottságok elemzési-tervezési munkánkat, megoldásainkat ne befolyásolják. A probléma megoldása ugyanis független a fentiektől. A tervekben testet öltött megoldásunkat persze programozható formába kell öntenünk. A logikai modellt kiegészítve, pontosítva a fenti típusú információkkal, létrehozzuk az adott környezethez, fejlesztési eszközhöz idomuló implementációs modellt.

UML diagramok – rövid összefoglaló

Diagramok UML 1.x-ben - 9 diagram - Statikus nézet use case diagram objektum diagram osztály diagram komponens diagram működési/telepítési diagram Dinamikus nézet eseménykövetési diagram együttműködési diagram állapot diagram tevékenység/aktivitás diagram

UML diagramok használati eset diagramok : (követelmények) bemutatja a valós rendszer szereplőit, a szereplők kapcsolatát a szereplők által végzett tevékenységeket, a rendszert statikus aspektusból közelítve a fenti összefüggésben ábrázolja. osztály/objektum diagramok (statikus architektúra): leírja az objektumok típusát a rendszerben, és az ezek között fennálló különböző változatú, fajta statikus kapcsolatokat, viszonyrendszert

UML dinamikus viselkedés-leírás interakciós diagramok eseménykövetési diagramok együttműködési diagramok tevékenység/aktivitás diagramok állapot diagramok  kódgenerálás

Az UML dinamikája interakciós diagramok: aktivitás diagramok: tipikus alkalmazás: egy use case viselkedésének leírása, ahol a diagramok segítségével az adott use case-ben megnyilvánuló objektumok és azok együttműködésének (objektumok közötti üzenetváltás) vizsgálata aktivitás diagramok: egy UC (használati eset) formalizálása, megértése az általános működés követése több use case-en keresztül - workflow modellezés (több UC közötti kapcsolat) a párhuzamos működés tervezése - metódusok összekapcsolása (többszálú alkalmazás)

A dinamikus viselkedés elemei Esemény (event) Művelet (operation) - osztályok által nyújtott szolgáltatás (metódus) Üzenet (message) Esemény vagy művelet

A dinamikus viselkedés elemei Állapot (state): egy objektum állapota meghatározza: - attribútumok értékei (pl. x<3) - feltételek teljesülnek (pl. művelet végrehajtható) Állapotátmenet: állapot változása bejövő üzenet hatására (triggerelt) vagy önállóan (null trigger) Akció: az objektum által végzett műveletek

UML konceptuális modellje

Az UML konceptuális modellje Elemek. Elemek egymáshoz való viszonya. Szabályrendszer a nyelv használatára. Négy komponensből áll: architektúra, építőelemek, szabályrendszer, általános nyelvi mechanizmus.

Konceptuális modell - Architektúra Modellnézetek képezik: A modellnézetek szoros kapcsolatban vannak egymással. A rendszer különböző aspektusainak absztrakcióit tükrözik. Az UML öt nézetet javasol.

Konceptuális modell - architektúra Az UML öt nézetet javasol: use case nézet, logikai nézet, komponens nézet, folyamat nézet, telepítési/működési nézet.

Az UML öt nézete folyamat nézet logikai nézet use case nézet komponens telepítési nézet

Architektúra – Use Case nézet a rendszer funkcionalitását írja le, definiálja a szerepköröket és funkciókat.

Architektúra – Logikai nézet tervezési nézet (design view), tervezők, programfejlesztők számára fontos, a rendszer belső struktúráját írja le, a rendszer statikus elemeit és struktúráját, valamint az objektumok együttműködésének a formáját írja le.

Architektúra – Folyamat nézet a rendszert folyamataira és a végrehajtó elemekre tagoljuk, párhuzamosan végezhető műveletek feltárása, a programfejlesztők és rendszerintegrátorok számára fontos feladatok.

Architektúra – Komponens nézet a rendszer megvalósítása, programkomponensek és állományok specifikációja és függőségi viszonyai kerülnek meghatározásra, leírás komponens diagramokkal, főleg a programfejlesztők feladatvégrehajtása.

Architektúra – Telepítési nézet a rendszer fizikai működésének megvalósítása, a fizikai architektúra, hardver topológia: számítógépegységek (node - csomópontok) és elemek leírása, programfejlesztők, rendszerintegrátorok, tesztelők feladatai.

Építőelemek Az építőelemek az egyes modellnézeteket reprezentáló diagramokba rendezhetők. Csoportjai: elemek, relációk, kapcsolatok, diagramok.

Elemek Az elemek három további csoportba sorolhatók: strukturális elemek, viselkedési elemek, csoportosítási elemek.

Strukturális elemek use case-ek, osztályok, aktív osztályok, interfészek, komponensek, együttműködés, csomópontok.

Viselkedési elemek interakciók, állapot-gépek.

Csoportosítási elemek csomagok, modellek, alrendszerek, keretrendszer.

Relációk, kapcsolatok függőség, asszociációk, generalizáció.

Diagramok use case diagram, osztály diagram, objektum diagram, szekvencia diagram, együttműködési diagram, állapot átmenet diagram komponens diagram, telepítési diagram.

Nyelvi szabályrendszer A szabályok olyan szemantikai előírások, amelyek azt határozzák meg, hogy hogyan kell a nyelvi elemeket használni, értelmezni a rendszer különböző nézeteiben és a nézetek során létrehozott modellekben.

Nyelvi szabályrendszer A modell-elemek tervezésénél figyelembe veendő sajátosságok: azonosításra szolgáló Név (megkülönböztető képességgel kell, hogy rendelkezzenek), értelmezés (az adott névvel azonosított rendszerelemeket egyértelműsíti), láthatóság, integritás (az elemek egymáshoz való kapcsolódásának a módját és következetes alkalmazását kifejezi az integritás foka), végrehajtási szabályok – megvalósítás feltételei.

Általános nyelvi mechanizmus Megjegyzések kezelésére, a modell elemek sajátosságainak pontosítására vonatkozik. Lehetőség van a nyelvi elemek bővítésére, ezáltal mód van az UML nyelvet speciális alkalmazásokhoz, feladatokhoz, felhasználókhoz, módszerekhez illeszteni.

Általános nyelvi mechanizmus Az UML nyelv mechanizmusok: specifikációk: az adott építőelem szintaktikai és szemantikai szabványos leírása, szimbólumrendszer és kiegészítő információk, megosztottság, kiterjesztési mechanizmus: sztereotípiák, megszorítások, hozzárendelt érték (pl. az elem verziószáma, vagy a létrehozó személye).

A RUP modelljei üzleti és domén modell, use case modell, elemzési modell, tervezési modell, implementációs modell, fizikai megvalósítási modell, tesztmodell.