uml-alapú fejlesztés
DESCRIPTION
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… - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/1.jpg)
UML-alapú fejlesztés
![Page 2: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/2.jpg)
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.
![Page 3: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/3.jpg)
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.
![Page 4: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/4.jpg)
Rendszerfejlesztés
• Rendszerfejlesztés alapkérdései– Általános értelemben vett rendszer
fejlesztés– Rendszerfejlesztés lehet:
• Business Process Engineeringha vállalat (működésének) (át)szervezésével foglalkozunk
• Product Engineeringha egy termék előállítása a célpl.: mobil telefon, repülőgép vezérlő rsz.
• Szoftverfejlesztési folyamat
![Page 5: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/5.jpg)
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)
![Page 6: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/6.jpg)
Vízesés modell
![Page 7: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/7.jpg)
A fejlesztés életciklusa• System engineering – Rendszerfejlesztés
– Business process eng. – Üzleti modellezés• üzleti folyamatok tervezése, szervezése• az üzleti környezet modellezése
– Product eng. – Termék modellezés• termékek tervezés• termék modellezése, annak használata
• Requirements – Követelménykezelés• Analysis – Elemzés• Design – Tervezés• Implementation – Implementáció• Testing – Tesztelés, Telepítés• Karbantartás, Rendszerkövetés, Továbbfejl.
Software eng.
Rend
szer
fejle
szté
s –
Syst
em E
ng.
![Page 8: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/8.jpg)
Módszertan
Módszertan
Modellező nyelv
Eljárások
![Page 9: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/9.jpg)
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.
![Page 10: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/10.jpg)
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égelehet.
![Page 11: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/11.jpg)
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.
![Page 12: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/12.jpg)
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.
![Page 13: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/13.jpg)
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.
![Page 14: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/14.jpg)
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.
![Page 15: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/15.jpg)
A RUP szerkezeteta
rtalo
m (m
it ke
ll vé
greh
ajta
ni?)
idő (mikor, milyen sorrendben?)
![Page 16: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/16.jpg)
RUP módszertan• A Rational Unified Process egy UML-t, mint modellező
nyelvet használó szoftver fejlesztési módszertan:– UML modellező nyelv jelölésrendszerét használja.– Eljárásaiban megadja, hogy milyen lépéseket kell végrehajtani,
milyen sorrendben.– A feladatok elvégzéséért ki a felelős.– Milyen termékeket kell előállítani a feladat végrehajtása során.
– Eszközökkel támogatja a fejlesztés egyes szakaszait.– Tool-mentorok segítik az eszközök használatát.– Sablonokat, útmutatókat ad az egyes feladatokhoz.
+
![Page 17: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/17.jpg)
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.
![Page 18: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/18.jpg)
UML diagramok
1. Use Case (használati eset) diagram2. Tevékenységi/Aktivitási (Activity) diagram3. Eseménykövetési/Szekvencia (Sequence)
diagram4. Együttműködési/Kollaborációs (Collaboration)
diagram5. Osztály (Class) diagram6. Objektum (Object) diagram7. Állapot-átmeneti (Statechart) diagram8. Komponens (Component) diagram9. Telepítési (Deployment) diagram
![Page 19: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/19.jpg)
A RUP szerkezeteta
rtalo
m (m
it ke
ll vé
greh
ajta
ni?)
idő (mikor, milyen sorrendben?)
![Page 20: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/20.jpg)
Munkafolyamatok
![Page 21: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/21.jpg)
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
![Page 22: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/22.jpg)
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.
![Page 23: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/23.jpg)
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.
![Page 24: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/24.jpg)
Támogató munkafolyamatokAzok 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.
![Page 25: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/25.jpg)
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.
![Page 26: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/26.jpg)
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.
![Page 27: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/27.jpg)
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égelehet.
![Page 28: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/28.jpg)
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.
![Page 29: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/29.jpg)
Fázisok és iterációk
![Page 30: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/30.jpg)
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).
![Page 31: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/31.jpg)
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
![Page 32: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/32.jpg)
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
![Page 33: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/33.jpg)
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
![Page 34: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/34.jpg)
Á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
![Page 35: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/35.jpg)
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.
![Page 36: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/36.jpg)
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.
![Page 37: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/37.jpg)
Iterációk• A RUP szerint a fejlesztés egyes fázisai tovább bonthatóak
iterációkra. • Az iteráció egy olyan fejlesztési ciklus, amely során minden
alapvető munkafolyamatot egyszer elvégzünk.
Vízesés
Iteratív -
“sok kis vízesés”
![Page 38: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/38.jpg)
Iterációk
Az iterációk során egyre több termék
áll elő, és a termékek
érettsége egyre nő.
![Page 39: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/39.jpg)
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.
![Page 40: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/40.jpg)
V. A fejlesztés menete a RUP ajánlásával
![Page 41: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/41.jpg)
A RUP szerkezeteta
rtalo
m (m
it ke
ll vé
greh
ajta
ni?)
idő (mikor, milyen sorrendben?)
![Page 42: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/42.jpg)
V.1. Üzleti modellezés – Business Modeling
![Page 43: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/43.jpg)
Ü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égeitBiztosítani, hogy az ügyfelek, végfelhasználók és fejlesztők egységes képet kapjanak az
adott szervezetrőlA szervezetet támogató
rendszerrel szemben felmerülő követelmények felderítése
![Page 44: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/44.jpg)
Ü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.
![Page 45: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/45.jpg)
Üzleti modellezés
![Page 46: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/46.jpg)
Ü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.
![Page 47: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/47.jpg)
Ü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.
![Page 48: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/48.jpg)
Üzleti modellezés
• Az üzleti folyamatok azonosítása (Identify Business Processes)
![Page 49: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/49.jpg)
Üzleti modellezés - tevékenységek
![Page 50: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/50.jpg)
Üzleti modellezés - termékek
![Page 51: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/51.jpg)
Ü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.
![Page 52: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/52.jpg)
Ü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.
![Page 53: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/53.jpg)
A szakterület folyamatai (üzleti folyamat diagram)
od A diplomamunka kezelésének folyamata
Diplomaterv beérkezése a Tanszékre
Diplomaterv
- szerző adatai: - konzulens adatai: - téma bemutatása: - elfogadás kelte:
Diplomamunka beérkezése a Tanszékre
Diplomamunka beérkeztetése, elbírálása
Diplomamunka
- diplomaterv: - konzulensi lap: - kidolgozott téma:
Bírálat
- bíráló véleménye: - osztályzat:
Diplomaterv ek nyilv ántartásaA két esemény között
meghatározatlan hosszúságú idő telik el
Elbírált terv visszaküldése
Elbírált diplomamunka
visszaküldése D.O-ra
Bírálat dokumentum
Diploma-terv dokumentum
Részletesző diagram
Részletező diagram
engedélyezésvagyelutasítás
bíráló és bírálatbejegyzése
Diplomatervfelvétele[elfogadás esetén]
(Diplomáztatás esettanulmány) od A diplomamunka kezelésének folyamata
Diplomaterv beérkezése a Tanszékre
Diplomaterv elbírálása
Diplomaterv
- szerző adatai: - konzulens adatai : - téma bemutatása: - elfogadás kelte:
Diplomamunka beérkezése a T anszékre
Diplomamunka beérkeztetése, elbírálása
Diplomamunka
- diplomaterv: - konzulensi lap: - kidolgozott téma:
Bírálat
- bíráló véleménye: - osztályzat:
Diplomaterv ek nyilv ántartása
A két esemény között meghatározatlan hosszúságú idő tel ik el
Elbírált terv visszaküldése
Elbírált diplomamunka
visszaküldése D.O-ra
Bírálat dokumentum
Diploma-terv dokumentum
Részletesző diagram
Részletező d iagram
engedélyezésvagyelutasítás
bíráló és bírálatbejegyzése
Diplomatervfelvétele[elfogadás esetén]
![Page 54: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/54.jpg)
Szakterületi modell(Diplomáztatás esettanulmány)
cd Szakterületi osztálydiagram
Tanszéki felelős
DiplomaTerv
- szerző neve: - fejlesztőeszköz: - konzulens: - tanszék: - cím: - témavázlat:
Diplomamunka
- diplomaterv: - konzulensi vélemyény: - kidolgozás:
Bírálat
- bíráló neve: - osztályzat: - szöveg:
Fej lesztőeszköz
- megnevezés:
Tanszék
- megnevezés:
Szerző
- név:
Konzulens
- név:
Bíráló
- név:
+elkészíti
+elbírálja
+közreműködik
+közreműködik
+bírálatra kiadja
+jóváhagyja
+képviseli
+elkészíti+használja
+kijelöli
+elkészíti
+kijelöli
![Page 55: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/55.jpg)
Követelmény (elemzés)
![Page 56: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/56.jpg)
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
![Page 57: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/57.jpg)
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
![Page 58: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/58.jpg)
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.
![Page 59: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/59.jpg)
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.
![Page 60: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/60.jpg)
Követelményelemzés
![Page 61: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/61.jpg)
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.
![Page 62: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/62.jpg)
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.
![Page 63: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/63.jpg)
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.
![Page 64: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/64.jpg)
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.
![Page 65: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/65.jpg)
Tipikus módszerek: megbeszélés, interjúGaus&Weinberg által javasolt 3 kérdéscsoport módszer:
– szövegkörnyezet független kérdések• Ki fogja majd használni az alkalmazást? Ki lesz az
alkalmazás felhasználója?• Milyen gazdasági előnyökkel jár egy sikeres
alkalmazás?• Kinek az érdekeit szolgálja a fejlesztés?
– a fejlesztés specifikus kérdések• Le tudná írni azt a környezetet, amelyben a megoldást
alkalmazzák?• Létezik bármilyen dolog vagy megszorítás, amely
hatással lehet az alkalmazás megvalósítására?– meta-kérdések: amelyek a megbeszélés eredményességére
fókuszálnak - • A témához kapcsolódó kérdésekkel találkozott?• Nem volt sok a feltett kérdések száma?
Követelmények feltárását, összegyűjtését segítő technikák
![Page 66: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/66.jpg)
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.
![Page 67: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/67.jpg)
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
![Page 68: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/68.jpg)
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.
![Page 69: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/69.jpg)
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.
![Page 70: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/70.jpg)
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).
![Page 71: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/71.jpg)
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.
![Page 72: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/72.jpg)
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.
![Page 73: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/73.jpg)
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.
![Page 74: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/74.jpg)
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.
![Page 75: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/75.jpg)
Funkcionális követelmények
• Funkcionális követelmények:– azokat a követelményeket értjük,
amelyek a szoftverrendszert kívülről nézve, a felhasználó szemszögéből írják le.
![Page 76: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/76.jpg)
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.
![Page 77: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/77.jpg)
Fejlesztendő szoftver- rendszer
Szervezet, vállalati belső környezet
SW alkalmazásokFelhasználók, akik fejlesztendő alkalmazást
működtetik
Külső szereplők, akik
fejlesztendő alkalmazás szolgáltatásait igénybe veszik
Külső rendszerek
![Page 78: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/78.jpg)
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.
![Page 79: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/79.jpg)
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.
![Page 80: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/80.jpg)
Tesztelés követelmények alapján
![Page 81: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/81.jpg)
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.
![Page 82: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/82.jpg)
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).
![Page 83: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/83.jpg)
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.
![Page 84: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/84.jpg)
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.
![Page 85: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/85.jpg)
bemeneti sorozat
Tesztelt szoftver software under test,
SUT
Értékelés (viselkedés, kimenetek
összehasonlítása)
Referencia (követelmény specifikáció, prototípus, rendszermodell
stb.)
SUT kimenet
viselkedés, állapot megfigyelése
referencia kimenet
eredmény
Szoftvertesztelés alapsémája
![Page 86: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/86.jpg)
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.
![Page 87: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/87.jpg)
Követelmények megvalósításának ábrázolása EA-ban
ud Köv etelményekMegv alósítása
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version
ÁrajánlatKészít_Weben
ÁrajánlatKészítés ÁrajánlatMódosítás
ÁrajánlatbólRendelés
ÁrajánlatKészítés
ÁrajánlatMódosít_WebenÁrajánlatLekérdez_Weben
![Page 88: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/88.jpg)
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.
![Page 89: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/89.jpg)
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.
![Page 90: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/90.jpg)
Ú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.
![Page 91: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/91.jpg)
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.
![Page 92: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/92.jpg)
Ú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
![Page 93: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/93.jpg)
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.
![Page 94: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/94.jpg)
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).
![Page 95: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/95.jpg)
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.
![Page 96: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/96.jpg)
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.
![Page 97: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/97.jpg)
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.
![Page 98: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/98.jpg)
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
![Page 99: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/99.jpg)
Use case modell elemei - Aktorok
![Page 100: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/100.jpg)
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.
![Page 101: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/101.jpg)
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.
![Page 102: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/102.jpg)
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.
![Page 103: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/103.jpg)
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.
![Page 104: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/104.jpg)
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.
szereplő/aktor
![Page 105: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/105.jpg)
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.
![Page 106: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/106.jpg)
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.
![Page 107: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/107.jpg)
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.
![Page 108: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/108.jpg)
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.
![Page 109: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/109.jpg)
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.
![Page 110: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/110.jpg)
Use case modell elemei – Use Case-ek
![Page 111: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/111.jpg)
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.
![Page 112: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/112.jpg)
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.
![Page 113: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/113.jpg)
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?
![Page 114: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/114.jpg)
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.
![Page 115: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/115.jpg)
Példa
Black-box módszer a rendszer (külső) viselkedésének leírására
Belső működés specifikálása
ÁrajánlatKészít_Weben use case:Végrehajtásakor az Ügyfél
megadja az Árajánlat összeállításához szükséges adatokat, majd a rendszer elkészíti az árajánlatot.
ÁrajánlatKészít_Weben use case:A rendszer ellenőrzi a megadott
adatokat, ha az adatok helyesek a rendszer az adatbázisba, az árajánlat táblába beszúr egy új sort, rekordot.
![Page 116: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/116.jpg)
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;
![Page 117: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/117.jpg)
A use case-ekre vonatkozó jellemzők, sajátosságok
• a use case-eket minden esetben az aktorok kezdeményezik;
![Page 118: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/118.jpg)
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.
![Page 119: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/119.jpg)
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.
![Page 120: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/120.jpg)
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
use case/funkció
![Page 121: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/121.jpg)
Munkafolyamat
![Page 122: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/122.jpg)
A rendszer hatáskörének kezelése
![Page 123: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/123.jpg)
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
![Page 124: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/124.jpg)
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.
![Page 125: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/125.jpg)
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
![Page 126: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/126.jpg)
A rendszer definíciójának finomítása
![Page 127: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/127.jpg)
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.
![Page 128: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/128.jpg)
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
![Page 129: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/129.jpg)
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…)
![Page 130: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/130.jpg)
Használati eset részletezéseFolyamatok 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.
![Page 131: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/131.jpg)
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.
![Page 132: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/132.jpg)
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.
![Page 133: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/133.jpg)
Use case leírás• Normál működés:
– a use case-ben definiált szokásos működést a use case normál lefutásának, más szóval alapfolyamatnak hívjuk.
• Alternatív esetek:– A működésnek lehetnek különleges, alternatív
esetei (pl. hibás működés), ezek az alfolyamatok. • A fejlesztés során minden use case esetén fel
kell tárni az összes alternatív lefutási menetet. • A tervezett rendszernek a use case-ekben
definiált normál és alternatív működését külön forgatókönyvekben rögzítjük.
![Page 134: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/134.jpg)
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.
![Page 135: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/135.jpg)
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.
![Page 136: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/136.jpg)
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.
![Page 137: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/137.jpg)
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.
![Page 138: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/138.jpg)
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?
![Page 139: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/139.jpg)
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.
![Page 140: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/140.jpg)
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.
![Page 141: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/141.jpg)
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.
![Page 142: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/142.jpg)
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.
![Page 143: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/143.jpg)
Aktivitási diagram
Az Ügyfél a Kft. honlapján aktiválja az "Az Árajánlat készítés" funkciót.
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.
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.
A rendszer elmenti az Árajánlat adatait.
A rendszer nyugtázó üzenetet küld az Ügyfélnek a képernyőn az Árajánlat készítésének sikerességéről.
A rendszer megerősítést kér az Ügyféltől az Árajánlat elfogadására.
[ Árajánlat Elutasítva! ]
[ Hibás adatok! ]
![Page 144: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/144.jpg)
Aktivitási diagram
![Page 145: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/145.jpg)
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).
![Page 146: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/146.jpg)
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.
![Page 147: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/147.jpg)
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
![Page 148: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/148.jpg)
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
![Page 149: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/149.jpg)
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.
![Page 150: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/150.jpg)
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
![Page 151: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/151.jpg)
start Rendelés érkezik
Fizetés ellenőrzése
Raktárkészlet ellenőrzés
Rendelés törlése
Áru eladva
UtánrendelésKiszállítás
*[ minden egyes árura a rendelésben ]
[ nem OK ]
[minden elem kész, fizetés OK]
[ OK ]
[ utánrendelés szükséges ]
[ van raktáron ]
Start, kezdőpont átmenet
műveletek (tevékenységek,
akciók)
![Page 152: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/152.jpg)
Aktivitási diagram
• Elemkészlete:– aktivitás– sorrendezés/párhuzamosság– szinkronizáció– őrfeltételek– döntések
szinkronizáció (fork/join)
Aktivitás1 Aktivitás2[ őrfeltétel ]
döntés
kezdőpont végpont
![Page 153: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/153.jpg)
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
![Page 154: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/154.jpg)
start Rendelés érkezik
Fizetés ellenőrzése
Raktárkészlet ellenőrzés
Rendelés törlése
Áru eladva
UtánrendelésKiszá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 ]
![Page 155: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/155.jpg)
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
![Page 156: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/156.jpg)
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 vonalszinkronizáció (fork/join)
![Page 157: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/157.jpg)
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
![Page 158: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/158.jpg)
Use case modell elemei - Kapcsolat
![Page 159: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/159.jpg)
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.
![Page 160: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/160.jpg)
Kapcsolatok
• A kapcsolatot a diagramban az aktorokat és a use case-eket összekötő vonal szimbolizálja.
• A vonal lehet irányított.
![Page 161: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/161.jpg)
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
![Page 162: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/162.jpg)
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.
![Page 163: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/163.jpg)
Kezdemenyező szereplő use case
![Page 164: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/164.jpg)
Példa
ÁrajánlatKészít_Weben
ÁrajánlatLekérdez_Weben
(from use case view)
ÁrajánlatMódosít_Weben
(from use case view)
Regisztrál
Ügyfél
(from aktorok)
ÁrajánlatNyomtat_Weben
(from use case view)
![Page 165: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/165.jpg)
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.
![Page 166: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/166.jpg)
Kezdemenyező szereplő
Résztvevő szereplő1
use case
Résztvevő szereplő2
![Page 167: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/167.jpg)
Speciális kapcsolatok
• Két aktor közötti kapcsolatot.• Definiálhatunk use case-ek közötti
speciális viszonyokat is.
![Page 168: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/168.jpg)
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ő.
![Page 169: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/169.jpg)
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
![Page 170: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/170.jpg)
Speciális kapcsolat két aktor között
Leszármazott szereplő1
Leszármazott szereplő2
Ős szereplő use case/funkció
![Page 171: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/171.jpg)
Speciális kapcsolat két aktor között
Kereskedő Kereskedelmi Menedzser
![Page 172: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/172.jpg)
Speciális kapcsolatok use case-ek között
• Három speciális viszony:– tartalmazás, – kiterjesztés és – öröklődés viszonyokat.
![Page 173: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/173.jpg)
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.
![Page 174: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/174.jpg)
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.
![Page 175: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/175.jpg)
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.
![Page 176: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/176.jpg)
Tartalmazás – include viszony
tartalmazott (included) use case
alap/normál use case1
szereplő/aktor
alap/normál use case2
<<include>>
<<include>>
![Page 177: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/177.jpg)
Tartalmazás – include viszony
ÁrajánlatKészít_Weben
ÁrajánlatLekérdez_Weben
(from use case view)
ÁrajánlatMódosít_Weben
(from use case view)
Ügyfél
(from aktorok)
ÜgyfélAzonosítás_ felhasználói név&Jelszó
(from use case view)
<<include>>
<<include>>
<<include>>
![Page 178: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/178.jpg)
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.
![Page 179: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/179.jpg)
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.
![Page 180: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/180.jpg)
Kiterjesztés – extend viszony
szereplő/aktor alap/normál use case kiterjesztett (extended) use case
<<extend>>
![Page 181: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/181.jpg)
Kiterjesztés – extend viszony
MegrendelésKészít
(from Kereskedő use case-ei)
Kereskedő
(from aktorok)
Kedvezményzárolás
<<extend>>
![Page 182: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/182.jpg)
Ö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.
![Page 183: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/183.jpg)
Ö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.
![Page 184: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/184.jpg)
Öröklődés – generalizáció
leszármazott use caseszereplő/aktor use case
![Page 185: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/185.jpg)
Öröklődés – generalizáció
ÜgyfélTörzsadatKarbantartás
Kereskedő
(from aktorok)
ÜgyfélTörzsadatFelvitel
<<generalization>>
![Page 186: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/186.jpg)
Use case modell
• Aktorok.• Use case-ek.• Use case-ek struktúrálása.• Kapcsolatok.
• Ábrázolás:– Use case diagram.
![Page 187: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/187.jpg)
Use case diagram
![Page 188: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/188.jpg)
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.
![Page 189: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/189.jpg)
Use case diagram
• Alkalmas:– A tervezett rendszerrel szemben támasztott
összes követelmény (use case-ek halmaza) meghatározására, leírására.
• Eszköz:– A felhasználóval való kommunikációra.
![Page 190: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/190.jpg)
KedvezményJóváhagyása
(from use case view)
Kereskedelmi Menedzser(from aktorok)
KedvezményTörlése
(from use case view)
MegrendelésKészítés
(from Kereskedő use case-ei)
ÜgyfélTörzsadatKarbantartás
(from ÜgyféltörzsKezelés)
ÁrajánlatMódosítás
(from ÁrajánlatKezelés)
ÁrajánlatbólRendelés
(from ÁrajánlatKezelés)
ÁrajánlatKészítés
(from ÁrajánlatKezelés)
Kedvezmény zárolása
(from use case view)
<<extend>>
Kereskedő
(from aktorok)
ÜgyfélTörzsadatFelvitel
(from ÜgyféltörzsKezelés)<<generalization>>
![Page 191: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/191.jpg)
Ügyfél által kezdeményezett use case-eket összefoglaló use case diagram
ÁrajánlatotLekérdez _Weben
Regisztrál
ÁrajánlatotNyomtat _Weben
Ügyfél
ÁrajánlatotKészít _Weben
ÜgyfeletAzonosít_ felhasználóinév&Jelszó
<<include>>
<<include>>
![Page 192: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/192.jpg)
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.
![Page 193: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/193.jpg)
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.
![Page 194: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/194.jpg)
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.
![Page 195: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/195.jpg)
![Page 196: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/196.jpg)
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ényekha 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ása 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
![Page 197: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/197.jpg)
Use case
• Követelményspecifikáció:– fejlesztendő szoftverrendszertől a felhasználó
által elvárt, megkövetelt viselkedés(ek)t, a rendszer által nyújtott szolgáltatásokat írják le.
• Elemzés/tervezés:– A rendszer belső működésének leírása.– Hogyan lesznek a rendszertől elvárt funkciók,
use case-ek megvalósítva, majd implementálva.
![Page 198: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/198.jpg)
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
![Page 199: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/199.jpg)
Követelményelemzés - tevékenységek
![Page 200: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/200.jpg)
Követelményelemzés - termékek
![Page 201: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/201.jpg)
Használati eset modell
Tanszéki felelős
Napi feladatok elv égzése
Karbantartási feladatok elv égzése
Kimutatások készítése
(Diplomáztatás esettanulmány)ud Napi feladatok elv égzése
Új diplomaterv
nyitása
A kész diplomamunka beérkeztetése
Bírálat beérkeztetése
Diplomamunka kiadása bírálatra
Tanszéki felelős
Diplomaterv kiv álasztása
E-mail küldése «include»
«include»
«include»
«extend»
Használati eset modell
Használati eset diagram
![Page 202: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/202.jpg)
V.2. Elemzés - tervezés
![Page 203: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/203.jpg)
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
![Page 204: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/204.jpg)
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.
![Page 205: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/205.jpg)
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.
![Page 206: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/206.jpg)
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.
![Page 207: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/207.jpg)
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
![Page 208: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/208.jpg)
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
![Page 209: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/209.jpg)
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
![Page 210: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/210.jpg)
Tervezés fázisai
• Architektúra kialakítása:– Architektúra tervezés
• strukturális felépítése a rendszernek minták, specifikáció, részek…
– Adat tervezés• adat könyvtár, ER adat struktúrák
• Részletes tervezés:– Interfész tervezés
• belső és külső kommunikáció– Komponens tervezés
• architektúra terv elemei implementálható program elemek, procedúrák, függvények stb.
![Page 211: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/211.jpg)
Egy lehetséges architektúra meghatározása
![Page 212: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/212.jpg)
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
![Page 213: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/213.jpg)
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
![Page 214: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/214.jpg)
Architektúrális elemzés
• Pontosan definiálni kell a leendő rendszer felépítését.
![Page 215: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/215.jpg)
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.
![Page 216: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/216.jpg)
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
![Page 217: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/217.jpg)
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.
![Page 218: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/218.jpg)
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<<modell>>
![Page 219: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/219.jpg)
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
AlkalmazasReteg
<<modell>>UzletiReteg<<modell>>
![Page 220: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/220.jpg)
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.)
![Page 221: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/221.jpg)
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.
![Page 222: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/222.jpg)
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.
![Page 223: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/223.jpg)
Üzenetek
• A use case funkciója:– az üzeneteken keresztül teljesül.
• Az üzenetek:– eljárás vagy– függvény jellegűek, ez utóbbiak visszatérési
értékét is megadhatjuk. – Az üzenetek paraméterezhetők.
![Page 224: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/224.jpg)
Use case realizáció
use case realization
use case use case realization
<<trace>>
![Page 225: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/225.jpg)
Példa I.
ÁrajánlatKészít_Weben ÁrajánlatKészít_Weben realization
<<trace>>
![Page 226: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/226.jpg)
Példa II.
• Konferencia felvétele Use Case realisation
Konferencia felvétele
Konferencia felvétele
(from Vezető-szervező use case-i)
![Page 227: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/227.jpg)
Konferencia felvitele
Use Case realisation
A f elhasználó kiv álasztja a "Konf erencia f elv étele" f unkciót.
Rendszer ellenőrzi a f elhasználó jogosultságát.
Felhasználó megadja az új konf erencia adatait.
A rendszer elmenti az új konf erencia adatait.
Felhasználó bef ejezi az adatf elv ételt.
Rendszer ellenőrzi az adatokat és megerősítést kér a létrehozásra.
Szükséges adatok:- Cím, téma- Konf erencia röv id azonosítója - Főszerv ező nev eKiegészítő adatok:- Időpont,- Hely ,- Előadások, előadók-...
![Page 228: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/228.jpg)
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.
![Page 229: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/229.jpg)
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
![Page 230: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/230.jpg)
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
![Page 231: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/231.jpg)
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.
![Page 232: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/232.jpg)
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ő
![Page 233: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/233.jpg)
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.
![Page 234: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/234.jpg)
<<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)
DialogLoginDialogLogin<<boundary>>
![Page 235: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/235.jpg)
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.
![Page 236: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/236.jpg)
<<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:
Customer
Customer<<entity>>
![Page 237: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/237.jpg)
<<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.
![Page 238: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/238.jpg)
<<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:
TransactionHand
ler
![Page 239: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/239.jpg)
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.
![Page 240: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/240.jpg)
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.
![Page 241: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/241.jpg)
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.
![Page 242: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/242.jpg)
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.
![Page 243: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/243.jpg)
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.
![Page 244: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/244.jpg)
Szekvencia diagram
![Page 245: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/245.jpg)
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.
![Page 246: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/246.jpg)
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.
![Page 247: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/247.jpg)
Hívókagyló felemelése
HívottTelefonvonal
1 tárcsázása
8 tárcsázása9 tárcsázása
tárcsahang
csöngetési hang
csöngetési hang végekagyló felemelése
tárcsahang vége
csöngetés vége
csöngetés
Idő
Példa - hívjuk fel a tudakozót
![Page 248: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/248.jpg)
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).
![Page 249: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/249.jpg)
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... )
![Page 250: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/250.jpg)
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
![Page 251: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/251.jpg)
Együttműködési diagram
![Page 252: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/252.jpg)
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
![Page 253: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/253.jpg)
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ő”]*
![Page 254: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/254.jpg)
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
![Page 255: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/255.jpg)
Együttműködési diagram
Hívó Telefonvonal
Hívott
5: 9 tárcsázása1: kagyló felemelése3: 1 tárcsázása6: 8 tárcsázása
9: kagyló felemelése
2: tárcsahang4: tárcsahang vége7: csöngetési hang10: csöngetési hang vége
8: csöngetés
11: csöngetés vége
![Page 256: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/256.jpg)
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
![Page 257: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/257.jpg)
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
![Page 258: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/258.jpg)
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)
![Page 259: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/259.jpg)
Hívó Telefonvonal
Hívott
5*[i:=9..8]: tárcsáz(i)1: kagyló felemelése3: 1 tárcsázása
7: kagyló felemelése
2: tárcsahang4: tárcsahang vége6a: csöngetési hang8a: csöngetési hang vége
6b: csöngetés
8b: csöngetés vége
Együttműködési diagram
![Page 260: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/260.jpg)
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
![Page 261: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/261.jpg)
Példa - IQTAR Tanfolyami jelentkezés
: Jelentkezõ
: DlgLogin : Ugyfel : FrmJelentkezes
: Tanfolyam UML : Tanfolyam UML19990301 : Tanfolyami
Regisztracio : JelentkezesVezerles
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
Megjelenít
TanfolyamLista
IdõpontLista
Létrehoz
Tanfolyam-lista megjelenítése
Idõpont lista megjelenítése
Van szabad hely?
![Page 262: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/262.jpg)
Mintapélda - KonfMan
![Page 263: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/263.jpg)
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.)
Konferencia felvétele
Konferencia felvétele
(from Vezető-szervező use case-i)
![Page 264: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/264.jpg)
Béla : Vezető-szerv ező
: Fablak : AlkalmazsVezrl : FelhasználóKezelő
: Konf erenciaFelv itel
: Konf erenciaKezelő
: Konf erencia
1: "Konf erencia f elv étele" opció v álasztása
2: "Béla" f elhasználó jogosultság lekérdezése
3: "Béla"-hoz tartozó jogosultságok lekérdezése( )
4: Béla jogosultságai
5: jogosultság összev etése
6: létrehozás
7: adatok megadása
8: bev itel bef ejezése
9: adatok ellenőrzése
10: rendben!
11: Létrehozhatom?
12: Igen!
13: Hozz létre egy új konf erenciát a megadott adatokkal
15: OK
16: Minden OK, a konf erenciát léterehoztam!
14: létrehozás
Kötelező:- Konf erencia címe- Főszerv ező- Konf erencia témája
Opcionális:- Hely e- Ideje- ...
![Page 265: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/265.jpg)
Béla : Vezető-szervező
: KonferenciaFelvitel
: AlkalmazsVezrl
: FelhasználóKezelő
: KonferenciaKezelő
: Konferencia
5: jogosultság összevetése
: Fablak
1: "Konferencia felvétele" opció választása
7: adatok megadása8: bevitel befejezése
12: Igen!
11: Létrehozhatom?16: Minden OK, a konferenciát léterehoztam!
9: adatok ellenőrzése
13: Hozz létre egy új konferenciát a megadott adatok...10: rendben!
15: OK
2: "Béla" felhasználó jogosultság lekérdezése
3: "Béla"-hoz tartozó jogosultságok lekérdezése( )
4: Béla jogosultságai
6: létrehozás
14: létrehozás
![Page 266: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/266.jpg)
FelhasználóKezelő
"Béla"-hoz tartozó jogosultságok lekérdezése()
(from Alkalmazás Réteg)
Fablak
aktuálisFelhasználóAzonosítója(from Üzleti Réteg)
AlkalmazsVezrl
(from Üzleti Réteg)1
1
Konferencia
CímFőszervezőRövid_név
(from Alkalmazás Réteg)
KonferenciaKezelő
(from Alkalmazás Réteg)
0..*
1
0..*
KonferenciaFelvitel
FőszervezőCím
Rövid_név
(from Üzleti Réteg)
1
1
0..1
1
0..1
1 1
1
1
1
1
![Page 267: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/267.jpg)
Béla : Vezető-szervező
: KonferenciaFelvitel
: AlkalmazsVezrl
: FelhasználóKezelő
: KonferenciaKezelő
: Konferencia
5: jogosultság összevetése
: Fablak
1: "Konferencia felvétele" opció választása
7: adatok megadása8: bevitel befejezése
12: Igen!
11: Létrehozhatom?16: Minden OK, a konferenciát léterehoztam!
9: adatok ellenőrzése
13: Hozz létre egy új konferenciát a megadott adatok...10: rendben!
15: OK
2: "Béla" felhasználó jogosultság lekérdezése
3: "Béla"-hoz tartozó jogosultságok lekérdezése( )
4: Béla jogosultságai
6: létrehozás
14: létrehozás
![Page 268: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/268.jpg)
FelhasználóKezelő
"Béla"-hoz tartozó jogosultságok lekérdezése()
(from Alkalmazás Réteg)
Fablak
aktuálisFelhasználóAzonosítója(from Üzleti Réteg)
AlkalmazsVezrl
(from Üzleti Réteg)1
1
Konferencia
CímFőszervezőRövid_név
(from Alkalmazás Réteg)
KonferenciaKezelő
(from Alkalmazás Réteg)
0..*
1
0..*
KonferenciaFelvitel
FőszervezőCím
Rövid_név
(from Üzleti Réteg)
1
1
0..1
1
0..1
1 1
1
1
1
1
![Page 269: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/269.jpg)
Mintapélda – SWE Product
![Page 270: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/270.jpg)
Use Case realizáció
ÁrajánlatKészít_Weben ÁrajánlatKészít_Weben realization
<<trace>>
![Page 271: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/271.jpg)
Aktivitási diagram
![Page 272: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/272.jpg)
Az Ügyfél a Kft. honlapján aktiválja az "Árajánlat készítés" funkciót.
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.
A rendszer megjeleníti az "Árajánlat készítés" felületet.
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.
A rendszer elmenti az Árajánlat adatait.
A rendszer nyugtázó üzenetet küld az Ügyfélnek a képernyőn az Árajánlat készítésének sikerességéről.
A rendszer megerősítést kér az Ügyféltől az Árajánlat elfogadására.
[ Árajánlat rendben! ]
[ Árajánlat Elutasítva! ]
[ Hibás adatok! ][ Adatok rendben! ]
[ Adatok rendben! ][ Hibás adatok! ]
![Page 273: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/273.jpg)
Szekvencia diagram az elemzési szakaszban
![Page 274: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/274.jpg)
: ÜgyfélFőablak AlkalmazásVezérlő LoginDialog Ablak ÜgyfélTörzsadat
Árajánlat Készítés Ablak
ÁrajánlatKezelő
Árajánlat
"Az Árajánlat készítés" funkció választása
JogosultsagLekerdezes( )
megjelenít( )
"Felhasználói név" és "Jelszó" beírása
OK gomb megnyomása
ügyfelKereses( )
megjelenit( )
Adatok megadása
OK gomb megnyomása
adatokEllenorzese( )
Elfogadja az Árajánlatot?
Elfogad gomb megnyomása
Létrehozás
create( )
Az Ön által készített Árajánlat létrehozva!
![Page 275: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/275.jpg)
Szekvencia diagram a tervezési szakaszban
![Page 276: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/276.jpg)
![Page 277: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/277.jpg)
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.
![Page 278: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/278.jpg)
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
![Page 279: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/279.jpg)
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
![Page 280: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/280.jpg)
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.
![Page 281: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/281.jpg)
Láthatóság
• Láthatóság– + (public) nyilvános– - (private) saját– # (protected) védett– Az implementation és a protected is nyelvfüggő
módon értelmezett• Jellemzőként is megadható, pl.: {public}. • Nyelvfüggő módon értelmezik, azonban a
nyilvános felelősségek a teljes alkalmazásból elérhetők, ha az osztály is elérhető
![Page 282: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/282.jpg)
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
![Page 283: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/283.jpg)
Példa - IQTAR Tanfolyami jelentkezés
: Jelentkezõ
: DlgLogin : Ugyfel : FrmJelentkezes
: Tanfolyam UML : Tanfolyam UML19990301 : TanfolyamiIdopont
Regisztracio : Regisztracio
: JelentkezesVezerles
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ó")
megjelenít( )
tanfolyamLista( )
idopontLista( )
letrehoz( )
kiirTanfolyamLista( )
kiirIdopontLista( )
Van ilyen ügyfél
vanSzabadhely( )
![Page 284: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/284.jpg)
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>>
![Page 285: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/285.jpg)
Példa - IQTAR Tanfolyami jelentkezés
: Jelentkezõ
: DlgLogin : Ugyfel
: FrmJelentkezes
: Tanfolyam
UML : Tanfolyam
UML19990301 : TanfolyamiIdopont
: JelentkezesVezerles
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( )
![Page 286: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/286.jpg)
Használati esetek elemzése / Attribútumok és asszociációk leírása
![Page 287: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/287.jpg)
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
![Page 288: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/288.jpg)
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}]
![Page 289: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/289.jpg)
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)
![Page 290: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/290.jpg)
Attribútumok• Az UML szintaktikája:
láthatóság név: típus = kezdetiÉrték {jellemzők}– az attribútum-név elnevezi a szempontot, – az attribútum típusa megadja a lehetséges értékeket.– a kezdeti érték az objektum készítésekor beállítandó értéket jelenti.– az attribútum-érték megadja, hogy az objektum milyen az adott
szempontból
Tanfolyam- tematika: string- megnevezes: string- idotartam: integer
<<entity>> 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.
![Page 291: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/291.jpg)
Példa
Ugyfel- nev : string- lakcim : cim- felhasznaloiNev : string- jelszo : kodoltString
+ ugyfelKereses()
<<entity>>TanfolyamiIdopont
- kezdet : date- veg : date- hely : string
+ vanSzabadhely()
<<entity>>Tanfolyam
- megnevezes : string- idotartam : integer- tematika : string
+ tanfolyamLista()+ idopontLista()
<<entity>>
![Page 292: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/292.jpg)
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
![Page 293: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/293.jpg)
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.
![Page 294: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/294.jpg)
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.
![Page 295: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/295.jpg)
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.
![Page 296: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/296.jpg)
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)
![Page 297: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/297.jpg)
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.
![Page 298: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/298.jpg)
Példa - Tanfolyami jelentkezés
: Jelentkezõ
: DlgLogin : Ugyfel : FrmJelentkezes
: Tanfolyam UML : Tanfolyam UML19990301 : TanfolyamiIdopont
Regisztracio : Regisztracio
: JelentkezesVezerles
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ó")
megjelenít( )
tanfolyamLista( )
idopontLista( )
letrehoz( )
kiirTanfolyamLista( )
kiirIdopontLista( )
Van ilyen ügyfél
vanSzabadhely( )
![Page 299: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/299.jpg)
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>>
![Page 300: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/300.jpg)
Példa
Ugyfel- nev : string- lakcim : cim- felhasznaloiNev : string- jelszo : kodoltString
+ ugyfelKereses()
<<entity>>TanfolyamiIdopont
- kezdet : date- veg : date- hely : string
+ vanSzabadhely()
<<entity>>Tanfolyam
- megnevezes : string- idotartam : integer- tematika : string
+ tanfolyamLista()+ idopontLista()
<<entity>>
![Page 301: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/301.jpg)
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.
![Page 302: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/302.jpg)
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
![Page 303: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/303.jpg)
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.
![Page 304: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/304.jpg)
Láthatóság
• Láthatóság– + (public) nyilvános– - (private) saját– # (protected) védett– Az implementation és a protected is nyelvfüggő
módon értelmezett• Jellemzőként is megadható, pl.: {public}. • Nyelvfüggő módon értelmezik, azonban a
nyilvános felelősségek a teljes alkalmazásból elérhetők, ha az osztály is elérhető
![Page 305: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/305.jpg)
Osztályok közötti asszociációk
![Page 306: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/306.jpg)
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!
![Page 307: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/307.jpg)
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
![Page 308: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/308.jpg)
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.
![Page 309: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/309.jpg)
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
![Page 310: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/310.jpg)
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.
![Page 311: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/311.jpg)
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
![Page 312: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/312.jpg)
Multiplicitás
• Hány objektum vehet részt az asszociációban.• Multiplicitás
– az egyik osztály egy objektumához a másik osztályból hány objektum tartozik, vagyis kifejezi, hogy az osztályok objektumai milyen számosságban kapcsolódnak egymáshoz.
• Kardinalitás, a számosság fogalma. – Megadja az adott osztályban specifikálható
előfordulások minimális, illetve maximális számát.
![Page 313: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/313.jpg)
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ó.
![Page 314: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/314.jpg)
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.
![Page 315: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/315.jpg)
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.
![Page 316: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/316.jpg)
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.
![Page 317: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/317.jpg)
OrdinaryCustomerdateOfLastPurchase
KeyAccountCustomerpercentOfDiscountcontactName
Customername : Stringaddress : String
Order/ totaldateReceived
close()
StoragestoragePlacestoredQuantity
OrderLinequantity : Integer/ subtotal
11..* 1
+line items
1..*ProductCatalog
ProductsumValuenamepriceproductId
create()
0..*
1
0..*
1
productId1
1
1productId
1
contains
Store 0..*1..* 0..*1..* stores
{ordered}
![Page 318: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/318.jpg)
A kapcsolatok implementálása
![Page 319: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/319.jpg)
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
![Page 320: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/320.jpg)
OrdinaryCustomerdateOfLastPurchase
KeyAccountCustomerpercentOfDiscountcontactName
Customername : Stringaddress : String
ProductsumValuenamepriceproductId
create()
{ordered}
Order/ totaldateReceived
close()
1
0..*
1
0..*
OrderLinequantity : Integer/ subtotal
0..*
1
0..*
1
1..* 11..* 1+line items
![Page 321: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/321.jpg)
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á.
![Page 322: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/322.jpg)
class Order{
public Customer customer(); public Enumeration orderLines(); //Az
Order osztálytól lekérdezhetők hozzátartozó orderLine-ok.
}
![Page 323: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/323.jpg)
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.
![Page 324: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/324.jpg)
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();
};
![Page 325: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/325.jpg)
A getTheCustomerOfTheOrder() függvény megvalósítása
Customer* Order::getTheCustomerOfTheOrder()
{return m_pTheCustomerOfTheOrder;
};
![Page 326: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/326.jpg)
Példa - asszociációkra
Cég SzemélyAlkalmazás
munkaadó munkavállaló
Asszociáció neve
Szerepkör Szerepkör
![Page 327: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/327.jpg)
Példa - asszociációkra
Cég SzemélyAlkalmazás
munkaadó munkavállaló* *
Csúcspont Poligon
10..n0..n 1
{ordered}
![Page 328: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/328.jpg)
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.
![Page 329: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/329.jpg)
Ö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ó.
ŐsOsztály
LeszármazottOsztály2LeszármazottOsztály1
![Page 330: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/330.jpg)
Öröklődési viszonyok
• Öröklődési viszony:– Általánosítás (generalizáció – generalization)– Specializáció (pontosítás – specialization)
![Page 331: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/331.jpg)
Á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.
![Page 332: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/332.jpg)
Á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.
![Page 333: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/333.jpg)
Általánosítás - példa
KeyAccountCustomerpercentOfDiscountaddressnamecontactName
OrdinaryCustomernameaddressdateOfLastPurchase
![Page 334: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/334.jpg)
Általánosítás - példa
KeyAccountCustomerpercentOfDiscountcontactName
OrdinaryCustomerdateOfLastPurchase
Customernameaddress
Absztrakt
![Page 335: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/335.jpg)
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.
![Page 336: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/336.jpg)
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.
![Page 337: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/337.jpg)
Specializáció - Példa
PaymentpaymentDatetotal
CashPaymentcashVoucher
WireTransferindexNumberOfMoneyCirculation
![Page 338: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/338.jpg)
Ö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.
![Page 339: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/339.jpg)
Öröklődési hierarchia
GyökérOsztály
LeszármazottKöztesOsztály
LevélOsztály
{root} megszorítás
{leaf} megszorítás
![Page 340: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/340.jpg)
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.
![Page 341: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/341.jpg)
Speciális fogalmak, asszociációs viszonyok
• Aggregáció – kompozíció• Minősített asszociáció
![Page 342: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/342.jpg)
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ó
![Page 343: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/343.jpg)
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.
![Page 344: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/344.jpg)
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.
![Page 345: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/345.jpg)
Aggregáció
Customernameaddress
Addresscountycitydistrictstreetfloordoor
![Page 346: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/346.jpg)
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.
![Page 347: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/347.jpg)
Kompozíció
![Page 348: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/348.jpg)
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.
![Page 349: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/349.jpg)
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.
![Page 350: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/350.jpg)
Minősített asszociáció
ProductsumValuenamepriceproductId
ProductCatalog11..* 11..* contains
![Page 351: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/351.jpg)
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.
Product ProductCatalogproductId11 11 contains
productId
![Page 352: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/352.jpg)
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.
![Page 353: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/353.jpg)
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
![Page 354: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/354.jpg)
Asszociációs osztály
Store
StoragestoragePlacestoredQuantity
Product 1..*0..* 1..*0..* stores
![Page 355: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/355.jpg)
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.
![Page 356: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/356.jpg)
Származtatott elemek
![Page 357: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/357.jpg)
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.
![Page 358: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/358.jpg)
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.
![Page 359: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/359.jpg)
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.
![Page 360: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/360.jpg)
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.
![Page 361: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/361.jpg)
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.
![Page 362: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/362.jpg)
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
![Page 363: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/363.jpg)
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.
![Page 364: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/364.jpg)
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.
![Page 365: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/365.jpg)
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.
![Page 366: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/366.jpg)
Osztály-attribútum, osztály-művelet
ProductsumValuenamepriceproductId
create()
![Page 367: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/367.jpg)
Osztálynak önmagával való asszociációja (self-association)
Személy
házasság+feleség
+férj
0..10..1
hierarchia
+főnök
+beosztott0..1
*
Szerepkör
Fonök<<Interface>>
Beosztott<<Interface>>
0..n0..10..1 0..n
Személy
Megvalósít
![Page 368: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/368.jpg)
Asszociációs osztály
Cég Személy** **
+munkavállaló+munkaadó
Alkalmazásfizetés : double Részleg
1* 1*Asszociációs osztály
Asszociáció attribútumai
Asszociáció vagy
attribútum?
![Page 369: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/369.jpg)
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.
![Page 370: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/370.jpg)
Osztály diagram
![Page 371: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/371.jpg)
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.
![Page 372: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/372.jpg)
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
![Page 373: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/373.jpg)
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.
![Page 374: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/374.jpg)
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álynévattribútumNév
műveletNév()
![Page 375: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/375.jpg)
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.
![Page 376: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/376.jpg)
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
![Page 377: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/377.jpg)
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
![Page 378: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/378.jpg)
Osztálydiagramok a fejlesztési modellben - perspektíva
• Konceptuális perspektíva• Specifikációs perspektíva• Implementációs perspektíva
![Page 379: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/379.jpg)
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ó
![Page 380: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/380.jpg)
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.
![Page 381: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/381.jpg)
Osztálydiagramok a fejlesztési modellben - perspektíva
• Implementációs perspektíva– Valódi osztályok konkrét programnyelvi
környezetben.
![Page 382: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/382.jpg)
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.
![Page 383: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/383.jpg)
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.
![Page 384: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/384.jpg)
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.
![Page 385: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/385.jpg)
CRC kártya
Order
A tételek raktáron való meglétének ellenőrzése Order Line
Az ár meghatározása
A kifizetés érvényességének ellenőrzése
Áruk elküldése a megrendelő címére
Order Line
Customer
<Osztály neve>
<Együttműködés><Felelősség>
![Page 386: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/386.jpg)
CRC kártya
• Ixtlan Software
![Page 387: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/387.jpg)
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)
![Page 388: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/388.jpg)
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
![Page 389: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/389.jpg)
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)
![Page 390: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/390.jpg)
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
![Page 391: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/391.jpg)
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
![Page 392: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/392.jpg)
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.
![Page 393: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/393.jpg)
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
![Page 394: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/394.jpg)
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…
![Page 395: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/395.jpg)
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
![Page 396: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/396.jpg)
Komponensek tervezése
![Page 397: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/397.jpg)
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
![Page 398: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/398.jpg)
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
![Page 399: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/399.jpg)
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
![Page 400: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/400.jpg)
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)
![Page 401: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/401.jpg)
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
![Page 402: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/402.jpg)
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
![Page 403: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/403.jpg)
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
![Page 404: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/404.jpg)
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
![Page 405: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/405.jpg)
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>>
![Page 406: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/406.jpg)
Felhasználói felület megvalósítva
![Page 407: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/407.jpg)
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
<<event>> doubleClick()
<<tablewindow>> frmJelentkezo<<datafield>> név : String<<datafield>> cím : Long String<<datafield>> telefonszám : String<<datafield>> cégnév : String
<<button>> regisztráció()
![Page 408: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/408.jpg)
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)
![Page 409: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/409.jpg)
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
![Page 410: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/410.jpg)
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á
![Page 411: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/411.jpg)
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
![Page 412: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/412.jpg)
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)
![Page 413: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/413.jpg)
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! )
![Page 414: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/414.jpg)
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
![Page 415: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/415.jpg)
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.
![Page 416: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/416.jpg)
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!
![Page 417: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/417.jpg)
Állapot-átmeneti diagram
![Page 418: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/418.jpg)
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
![Page 419: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/419.jpg)
Á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.
![Page 420: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/420.jpg)
Á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.
![Page 421: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/421.jpg)
Á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
![Page 422: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/422.jpg)
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
![Page 423: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/423.jpg)
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:stateName
![Page 424: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/424.jpg)
Á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.
![Page 425: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/425.jpg)
• Az állapotok két esemény között írják le az objektumot. – Ha két egymást követő állapot között az objektum
kívülről kap üzenetet, akkor ezt az eseményt kell megadni az állapot-átmenet eseményeként.
– Amennyiben a két állapot között az objektum küld üzenetet, az üzenet elküldését az átmenet során elvégzendő akcióként kell megadni.
– Ha eseménykövetési diagram ciklusokat tartalmaz, a bejárt állapotokat csak egyszer kell létrehozni, és az állapot-átmeneteket úgy kell kialakítani, hogy a ciklus végén az objektum újra a ciklus elején lévő állapotba kerüljön.
Állapotok leírása
![Page 426: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/426.jpg)
Az order különböző állapotait bemutató állapotdiagram
checkingdo: check item
waiting
dispatchingdo: initiate delivery
delivered
/ get first item
[ not all items checked ] / get next item
item received[ some items not in stock ]
[ all items checked&&all items available ]
item received[ all items available ]
delivered[ all items checked&&some items not in stock ]
start
self-transition transition
activity
state
![Page 427: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/427.jpg)
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
checkingdo: check item
/ get first item
![Page 428: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/428.jpg)
Á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
![Page 429: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/429.jpg)
Á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.
![Page 430: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/430.jpg)
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
checkingdo: check item
/ get first item
![Page 431: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/431.jpg)
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
![Page 432: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/432.jpg)
A példa folytatása• a checking állapotból három átmenet látható • mindhárom átmenethez feltétel, őrszem
kapcsolható
checkingdo: check item
[ all items checked&&all items available ]
[ all items checked&&some items not in stock ]
[ not all items checked ] / get next item
guard
transition
![Page 433: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/433.jpg)
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
![Page 434: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/434.jpg)
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
![Page 435: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/435.jpg)
[ not all items checked ] / get next item
[ all items checked&&some items not in stock ]
waiting
item received[ some items not in stock ]
[ all items checked&&all items available ]
dispatchingdo: initiate delivery
checkingdo: check item
![Page 436: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/436.jpg)
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”
checkingdo: check item
![Page 437: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/437.jpg)
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
![Page 438: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/438.jpg)
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
![Page 439: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/439.jpg)
• tevékenységek, akciók: a rendszer működtetése során végrehajtandó feladatok, műveletek
• tevékenységek olyan műveletek:– összetettebbek, további lépésekre bonthatók– események által megszakítható tevékenységek a végrehajtás
folyamatában– az elemi műveletekből (akciók) álló tevékenységek elvégzéséhez
meghatározott időre van szükség – ezért az állapotokhoz kapcsolhatók
• akciók olyan pillanatnyi műveletek: – a funkció-hierarchia legalsó szintjén elhelyezkedő elemi műveletek
un. atomi műveletek - további lépésekre nem bonthatók– nem szakíthatók meg, nem rendelünk hozzájuk időtartamot – ezért az
átmenethez kapcsolhatók– pl. számítási műveletek, objektum manipulálására vonatkozó kérések
stb.
Tevékenységek, akciók
![Page 440: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/440.jpg)
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
![Page 441: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/441.jpg)
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
![Page 442: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/442.jpg)
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
![Page 443: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/443.jpg)
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
![Page 444: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/444.jpg)
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
![Page 445: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/445.jpg)
checkingdo: check item
waiting
dispatchingdo: initiate delivery
delivered
/ get first item
[ not all items checked ] / get next item
item received[ some items not in stock ]
[ all items checked&&all items available ]
item received[ all items available ]
delivered[ all items checked&&some items not in stock ]
Az order különböző állapotait bemutató állapotdiagram
start
self-transition transition
activity
state
![Page 446: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/446.jpg)
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
![Page 447: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/447.jpg)
A waiting állapot
waiting
item received[ some items not in stock ]
item received[ all items available ]
dispatchingdo: initiate delivery
![Page 448: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/448.jpg)
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
![Page 449: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/449.jpg)
dispatchingdo: initiate delivery
delivered
delivered
![Page 450: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/450.jpg)
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
![Page 451: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/451.jpg)
checkingdo: check item
waiting
dispatchingdo: initiate delivery
delivered
/ get first item
[ not all items checked ] / get next item
item received[ some items not in stock ]
delivered
cancelled
[ all items checked&&some items not in stock ]
[ all items checked&&all items available ]
item received[ all items available ]
cancelled
cancelledcancelled
![Page 452: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/452.jpg)
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
![Page 453: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/453.jpg)
checkingdo: check item
dispatchingdo: initiate delivery
delivered
/ get first item
[ not all items checked ] / get next item
delivered
cancelled
waiting
active
[ all items checked&&all items available ]
![Page 454: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/454.jpg)
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
![Page 455: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/455.jpg)
checkingdo: check item
dispatchingdo: initiate delivery
delivered
/ get first item
[ not all items checked ] / get next item
delivered
cancelled
waiting
active
[ all items checked&&all items available ]
![Page 456: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/456.jpg)
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
![Page 457: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/457.jpg)
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
![Page 458: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/458.jpg)
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
![Page 459: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/459.jpg)
Payment authorizing - fizetésengedélyezés
authorizingdo: check payment
authorized
delivered
rejected[ payment not OK ]
[ payment OK ]
![Page 460: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/460.jpg)
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
![Page 461: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/461.jpg)
checking dispatching
waiting
authorizing authorized
cancelled
delivered
rejected
![Page 462: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/462.jpg)
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
![Page 463: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/463.jpg)
Állapottérképek elemei
• Állapot
• (Állapotátmenet)
• Emlékező állapot (history)
• Feltétel
• Kezdőállapot
• Végállapot
• Állapotcsonk
StateName
H
s1 s2
H*
s1
s1
![Page 464: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/464.jpg)
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
HH
megszakitas
újrakezdés
![Page 465: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/465.jpg)
Á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
![Page 466: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/466.jpg)
Várakozó
Aktív
Idõ lejárt
Csöngetésdo: csöngetõ hang
Tárcsázás
Idő lejártdo: Szaggatott hang
Érvénytelendo: sípoló hang Kapcsolás
Csöngetésdo: csöngetõ hang
Foglaltdo: foglalt hang
Beszélgetés
[ 15 mp lejárt ]
tárcsáz( n )[ nem teljes a szám
tárcsáz( n )[ érvénytelen a szám ]
tárcsáz( n )[ érvényes a szám ] / kapcsol
[ foglalt a vonal ]
[ szabad a vonal ]
hívott felveszi / beszélgetés engedélyezése
[ 15 mp lejárt ]
tárcsáz( n )
hívó leteszi a kagylót / bontja a vonalat
felveszi a hallgatót / tárcsahang Tárcsahangdo: búgó hang
Állapot-átmenet diagram - Példa
![Page 467: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/467.jpg)
Ö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)
![Page 468: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/468.jpg)
Példa
Tárcsázó
Startentry: búgó hang kezdeteexit: búgó hang vége
Tárcsázás folyamatbanentry: number.append(n)
Startentry: búgó hang kezdeteexit: búgó hang vége
Tárcsázás folyamatbanentry: number.append(n)
tárcsáz( n )
[ number.isValid() ]tárcsáz( n )
Várakozó Tárcsázó Kapcsoló[ number.isValid() ]hallgató felvétele
Kezdőállapot Végállapot
![Page 469: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/469.jpg)
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
![Page 470: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/470.jpg)
Példa - Tanfolyami időpont
Törölve
Inicializálás alatt Nyitottdo: 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
törléstörlés
![Page 471: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/471.jpg)
Példa
Újraélesztés
Törölve
Inicializálás alatt Nyitottdo: Jelentkezõ regisztrálásaexit: jelentkezõk számának növelése
Megtelt
H
Inicializálás alatt Nyitottdo: Jelentkezõ regisztrálása
entry: jelentkezõk számának növelése
Jelentkezés / jelentkezõk száma=1
Jelentkezés
Megtelt
[ jelentkezõk száma=15 ]
H
Törlés
![Page 472: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/472.jpg)
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
![Page 473: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/473.jpg)
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)
![Page 474: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/474.jpg)
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
![Page 475: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/475.jpg)
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
11
SzemélyCím
- város- utca- házszám- irányítószám
1..*1..*
Cég11
![Page 476: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/476.jpg)
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
SzámlaTételSzámla
![Page 477: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/477.jpg)
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!
![Page 478: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/478.jpg)
Real-Time komponensek tervezése
![Page 479: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/479.jpg)
Adatbázis tervezése
![Page 480: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/480.jpg)
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
![Page 481: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/481.jpg)
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
![Page 482: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/482.jpg)
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
![Page 483: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/483.jpg)
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.
![Page 484: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/484.jpg)
Komponens diagram
konfmanDesktop
MFC 6.0
DB
konfmanPages
<<HTML>>
![Page 485: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/485.jpg)
Struktúramodellezés
• Telepítési diagram (deployment diagram): Megadja, hogy milyen szoftver elemeket milyen hardverre telepítünk.
![Page 486: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/486.jpg)
Telepítési diagram
WEB_SERVER DB_SERVER
KONFMAN_LOCAL_MACHINE
KONFMAN_LOCAL_MACHINE
KONFMAN_LOCAL_MACHINE
KONFMAN_REMOTE_CLIENT
KONFMAN_REMOTE_CLIENT
KONFMAN_REMOTE_CLIENT
![Page 487: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/487.jpg)
Elemzés - tervezés - tevékenységek
![Page 488: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/488.jpg)
Elemzés - tervezés - termékek
![Page 489: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/489.jpg)
Elemzés - tervezés - tevékenységek
![Page 490: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/490.jpg)
Elemzés - tervezés - termékek
![Page 491: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/491.jpg)
Az üzleti folyamat modell kapcsolata a többi modellel
• Kapcsolat a használati eset modellel• Kapcsolat az elemzési osztálymodellel
od A diplomamunka kezelésének folyamata
Diplomaterv beérkezése a Tanszékre
Diplomaterv elbírálása
Diplomaterv
- szerző adatai : - konzulens adatai: - téma bemutatása: - elfogadás kel te:
Diplomamunka beérkezése a Tanszékre
Diplomamunka beérkeztetése, elbírálása
Diplomamunka
- diplomaterv: - konzulensi lap: - kidolgozott téma:
Bírálat
- bíráló véleménye: - osztályzat:
Diplomatervek nyilvántartásaA két esemény között
meghatározatlan hosszúságú idő tel i k el
Elbírált terv visszaküldése
Elbírált diplomamunka
visszaküldése D.O-ra
Bírálat dokumentum
Diploma-terv dokumentum
Részletesző diagram
Részletező diagram
engedélyezésvagyelutasítás
bíráló és bírálatbejegyzése
Diplomatervfelvétele[elfogadás esetén]
od Diplomaterv elbírálása - részletezés
Diplomaterv értékelése
Diplomaterv
- szerző adatai: - konzulens adatai: - téma bemutatása: - elfogadás kelte:
Diplomaterv beérkezése a
Tanszékre
Új diplomaterv nyitása Diplomaterv visszaküldése
Diplomatervek nyilvántartása
elfogadás
od Folyamatok és kapcsolódó használati esetek
Új diplomaterv nyitása
cd Elemzési osztálymodell
Diplomaterv
- cím: String- készBeérkezés: Date- tanszék: LongInt- szerző1: String- szerző2: String- fejlesztőeszköz: LongInt- tervBeérkezés: Date
![Page 492: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/492.jpg)
od A diplomamunka kezelésének folyamata
Diplomaterv beérkezése a Tanszékre
Diplomaterv elbírálása
Diplomaterv
- szerző adatai: - konzulens adatai: - téma bemutatása: - elfogadás kelte:
Diplomamunka beérkezése a Tanszékre
Diplomamunka beérkeztetése, elbírálása
Diplomamunka
- diplomaterv: - konzulensi lap: - kidolgozott téma:
Bírálat
- bíráló véleménye: - osztályzat:
Diplomaterv ek nyilv ántartásaA két esemény között
meghatározatlan hosszúságú idő telik el
Elbírált terv visszaküldése
Elbírált diplomamunka
visszaküldése D.O-ra
Bírálat dokumentum
Diploma-terv dokumentum
Részletesző diagram
Részletező diagram
engedélyezésvagyelutasítás
bíráló és bírálatbejegyzése
Diplomatervfelvétele[elfogadás esetén]
![Page 493: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/493.jpg)
Diplomaterv elbírálása - részletezés
od Diplomaterv elbírálása - részletezés
Diplomaterv értékelése
Diplomaterv
- szerző adatai: - konzulens adatai: - téma bemutatása: - elfogadás kelte:
Diplomaterv beérkezése a
Tanszékre
Új diplomaterv nyitása Diplomaterv visszaküldése
Diplomaterv ek nyilv ántartása
elfogadás
![Page 494: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/494.jpg)
Elemzési osztálymodell
cd Elemzési osztálymodell
Diplomaterv
- cím: String- készBeérkezés: Date- tanszék: LongInt- szerző1: String- szerző2: String- fejlesztőeszköz: LongInt- tervBeérkezés: Date
![Page 495: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/495.jpg)
Elemzési osztálymodell(Diplomáztatás esettanulmány, diagram-részlet)
cd Elemzési osztálymodell
Diplomaterv
- cím: String- készBeérkezés: Date- tanszék: LongInt- szerző1: String- szerző2: String- fejlesztőeszköz: LongInt- tervBeérkezés: Date
+ Tárol() : void+ Töröl() : void+ Adatvizsgálat() : Boolean
Diplomaterv Ablak
- entitás: Entitás
Bírálat
- kiadás: Date- kész: Date- bíráló: Integer- jegy: Integer- bírálatFile: String
+ Tárol() : void+ Töröl() : void+ Adatvizsgálat() : Boolean
BírálatAblak
- entitás: Entitás
bírálatFile
Diplomaterv ablak
Bírálat ablak
![Page 496: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/496.jpg)
V.3. Implementáció
![Page 497: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/497.jpg)
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
![Page 498: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/498.jpg)
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.
![Page 499: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/499.jpg)
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.
![Page 500: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/500.jpg)
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.
![Page 501: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/501.jpg)
Implementáció - tevékenységek
![Page 502: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/502.jpg)
Implementáció - termékek
![Page 503: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/503.jpg)
V.4. Tesztelés
![Page 504: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/504.jpg)
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
![Page 505: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/505.jpg)
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.
![Page 506: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/506.jpg)
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.
![Page 507: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/507.jpg)
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.
![Page 508: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/508.jpg)
Tesztelés - tevékenységek
![Page 509: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/509.jpg)
Tesztelés - termékek
![Page 510: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/510.jpg)
V.5. Telepítés
![Page 511: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/511.jpg)
Telepítés
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
![Page 512: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/512.jpg)
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.
![Page 513: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/513.jpg)
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.
![Page 514: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/514.jpg)
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.
![Page 515: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/515.jpg)
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.
![Page 516: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/516.jpg)
Telepítés - tevékenységek
![Page 517: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/517.jpg)
Telepítés - termékek
![Page 518: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/518.jpg)
Telepítési modell
dd Telepítési Modell
Kliens gép
Szerv er gép
«executable»Program
Adatbázis szerver
Adatbázis
«protokoll»
![Page 519: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/519.jpg)
A modellek kapcsolatai
od A modellek és a fej lesztés folyamata
Elemzés
Terv ezés
«modell»Üzleti folyamat
modell
«modell»Használati eset
modell
«modell»
Domain modell«modell»
Analízis modell
Felhasználói felületek
«modell»Logikai modell
«modell»
Komponens modell
«modell»Telepítési modell
Opcionális
Az implementáció alapja
Implementációs modell 1
Implementációs modell 2
Implementációs modell n
![Page 520: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/520.jpg)
UML diagramok – rövid összefoglaló
![Page 521: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/521.jpg)
Diagramok UML 1.x-ben- 9 diagram -
Dinamikus nézet
– eseménykövetési diagram– együttműködési diagram– állapot diagram– tevékenység/aktivitás diagram
Statikus nézet
– use case diagram–objektum diagram– osztály diagram– komponens diagram– működési/telepítési diagram
![Page 522: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/522.jpg)
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
![Page 523: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/523.jpg)
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
![Page 524: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/524.jpg)
Az UML dinamikája• interakció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)
![Page 525: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/525.jpg)
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
![Page 526: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/526.jpg)
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
![Page 527: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/527.jpg)
UML konceptuális modellje
![Page 528: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/528.jpg)
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.
![Page 529: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/529.jpg)
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.
![Page 530: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/530.jpg)
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.
![Page 531: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/531.jpg)
telepítési nézet
folyamat nézet
komponens nézet
Az UML öt nézete
use case nézet
logikai nézet
![Page 532: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/532.jpg)
Architektúra – Use Case nézet
• A use case nézet:– a rendszer funkcionalitását írja le,– definiálja a szerepköröket és funkciókat.
![Page 533: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/533.jpg)
Architektúra – Logikai nézet
• A 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.
![Page 534: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/534.jpg)
Architektúra – Folyamat nézet
• A 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.
![Page 535: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/535.jpg)
Architektúra – Komponens nézet
• A 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.
![Page 536: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/536.jpg)
Architektúra – Telepítési nézet
• A 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.
![Page 537: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/537.jpg)
Építőelemek
• Az építőelemek az egyes modellnézeteket reprezentáló diagramokba rendezhetők.
• Csoportjai:– elemek,– relációk, kapcsolatok,– diagramok.
![Page 538: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/538.jpg)
Elemek
• Az elemek három további csoportba sorolhatók:– strukturális elemek,– viselkedési elemek, – csoportosítási elemek.
![Page 539: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/539.jpg)
Strukturális elemek
• use case-ek,• osztályok,• aktív osztályok,• interfészek,• komponensek,• együttműködés,• csomópontok.
![Page 540: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/540.jpg)
Viselkedési elemek
• interakciók,• állapot-gépek.
![Page 541: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/541.jpg)
Csoportosítási elemek
• csomagok,• modellek,• alrendszerek,• keretrendszer.
![Page 542: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/542.jpg)
Relációk, kapcsolatok
• függőség,• asszociációk,• generalizáció.
![Page 543: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/543.jpg)
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.
![Page 544: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/544.jpg)
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.
![Page 545: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/545.jpg)
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.
![Page 546: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/546.jpg)
Á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.
![Page 547: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/547.jpg)
Á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).
![Page 548: UML-alapú fejlesztés](https://reader035.vdocuments.mx/reader035/viewer/2022062501/56815da5550346895dcbd411/html5/thumbnails/548.jpg)
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.