A használati eset modell a rendszer funkcionális követelményeinek leírásának elemzése segítségével készíthető el. Első lépésként célszerű az aktorokat azonosítani, mert az általában könnyebb, és még bonyolult rendszerek esetén sem kell túl sok aktorral számolnunk. Az aktorok köre már a fejlesztés elején is pontosan meghatározható.
Következő lépés a használati esetek azonosítása. Egy bonyolult rendszer esetén nagyon sok használati esettel kell foglalkozni, ezért ebben is az inkrementális megközelítés javasolt.
4.1. Aktorok azonosítása
Az aktorokra a feladat leírásában, a funkciólistákban többnyire valamilyen főnévvel hivatkozunk. Fontos azonban, hogy az aktor
1. a rendszeren kívül létező entitás
2. a rendszerrel valamilyen funkcionális kapcsolatba kerül.
Egy tanulmányi nyilvántartó rendszer leírásában (mint amilyen például a Neptun) találhatunk például egy alábbi mondatot:
„A portásfülke előtt elhelyezett terminálon bejelentkezett hallgató megnézheti, hogy egy általa felvett tárgynak mikor vannak a vizsgái.”
Nyilvánvaló, hogy a portásfülke, és a terminál, bár a rendszeren kívül álló dolgok, nem aktorai a rendszernek, mert nem lépnek vele kapcsolatba, és nem igénylik annak szolgáltatásait, a „hallgató” azonban egy lehetséges aktor.
4.2. Használati esetek azonosítása
Az aktorok azonosítása után a használati esetek azonosítása következik. Használati esetekre valamilyen igei szerkezet utalhat a feladat leírásában, azonban nem olyan közvetlenül, mint az aktorok esetén. A fenti példa mondatban három funkció is el van rejtve:
1. a hallgató lekéri az általa felvett tárgyak listáját, 2. a hallgató kijelöl egy tárgyat ezek közül,
3. a hallgató lekéri a kijelölt tárgy vizsgaidőpontjait.
Az UML nem mondja meg, hogy egy használati eset milyen összetett funkciót modellezhet. A jelölés rendszer ismertetése során a példák egyszerű funkcionalitásokat tartalmaztak, de ha egy bonyolult rendszert ilyen egyszerű funkciókból szeretnénk felépíteni, akár több ezer használati esetet tartalmazó modellt kaphatnánk.
A tapasztalatok szerint egy áttekinthető használati eset diagram legfeljebb tíz-húsz használati esetet tartalmazhat. A használati eset modellt tehát számos használati eset diagramból kell felépíteni. Ezt úgy tudjuk elérni, hogy
1. a rendszert részrendszerekre bontjuk, és azokat külön-külön modellezzük,
2. előbb nagyobb funkcionális egységeket modellezünk egy használati esetként, majd ezeket részletezve jutunk el a finomabb felbontásig.
4.3. Egy összetettebb példa
Ebben a fejezetben egy olyan példát mutatunk, amelyben majdnem minden jelölési elem szerepet kap, és illusztrálja, hogy milyen elemzése lépéseken keresztül juthatunk el egy használati eset modell megalkotásáig.
A modellezendő rendszer (pénztári rendszer) leírása:
„A rendszer egy pár alkalmazottat foglalkoztató, néhány pénztárral működő kis önkiszolgáló élelmiszerbolt pénztári rendszere. A vevő egy kosárban összegyűjti a megvásárolni kívánt árukat. A pénztáros az árukat a vonalkódok beolvasásával azonosítja, és így készíti el a blokkot, ami alapján a vevő fizet. A megvásárolt áruk mennyiségével a rendszer csökkenti a raktárkészletet. Bizonyos áruk csak betétdíjas göngyöleggel együtt adhatók el, és a göngyöleg készletét is nyilván kell tartani. (Például a sör…).
A boltvezető bármikor helyettesíthet egy pénztárost, ha annak valami miatt félbe kell szakítania a munkáját. A boltvezetőnek joga van egy törzsvásárló esetén hitelbe is odaadni az árut, ezt a pénztáros nem teheti meg.
Ha egy áru vonalkódja sérült, ezért nem olvasható be, a pénztáros az árut a megnevezése alapján keresi vissza az adatbázisból.”
4.3.1. Aktorok azonosítása
A fenti leírásból szereplőként kiemelhetők az alábbi szerepkörök:
1. vevő 2. pénztáros
3. boltvezető
Ezek közül a vevő – bár szereplője a folyamatnak – nem aktor, mert a rendszerrel nincs közvetlen kapcsolata.
Kapcsolata van a pénztárossal, de ez rendszeren kívüli kapcsolat, tehát a modellben nem kell szerepelnie. Így marad aktorként a pénztáros és a boltvezető.
A két aktor között egy általánosítási kapcsolat van: a boltvezető mindig lehet pénztáros szerepkörben, tehát a pénztáros leszármazottjaként modellezhető. (Vegyük észre, hogy bár ez egy hierarchikus kapcsolat, de a beosztási hierarchiával most éppen ellentétes irányú.)
Ez az egyszerű példa is rámutat a szakterületi követelmények fontosságára, és egyben problémát okozó szerepére. Aki ilyen rendszert akar fejleszteni, annak ugyanis tisztában kell lennie azzal, hogy a pénztárgép nem egyszerű számológép: a vonatkozó rendeletek szerint ugyanis kell rendelkeznie egy speciális memória modullal, az úgynevezett adómemóriával, amibe minden blokk adatát be kell írnia, és ennek a memóriának a tartalma nem változtatható meg, csak kiolvasható.
A szakterületi követelmények értelmében tehát van egy harmadik aktor is, az adómemória. Ez nem felhasználó, hanem egy eszköz.
A használati modell aktorai tehát:
8.9. ábra - A pénztári rendszer aktorai
4.3.2. Használati esetek azonosítása
A leírásból kiolvasható, hogy a központi használati eset a blokkolás. Ehhez a pénztáros aktor kapcsolódik. A blokkolásnak szerves része a göngyöleg kezelés, raktárkészlet módosítás és az adómemóriába írás. Ezek tehát
„include” kapcsolatban vannak a blokkolással, mert feltétel nélkül, minden esetben végrehajtandók a blokkolás során. Az adómemóriába íráshoz kapcsolódik az adómemória aktor.
A blokkolás különleges esete az, ha nem olvasható a vonalkód. Ilyenkor az áru név szerinti visszakeresése funkció (egyben használati eset) kiegészíti az alap funkcionalitást, tehát a blokkolással „extend” kapcsolatban van. (Csak bizonyos feltételes teljesülése esetén – ha nem olvasható a vonalkód – szükséges.)
A boltvezetőnek van egy olyan funkciója, ami csak rá jellemző: adhat hitelt, ez az utolsó felfedezett használati eset a leírás elemzéséből.
A fenti elemzés alapján az alábbi használati eset diagram építhető fel:
8.10. ábra - A pénztári rendszer használati eset diagramja
4.4. A használati eset modell dokumentációja
A diagram rajzolása során mind az aktoroknak, mind a használati eseteknek nevet kell adni. Az elnevezések nem csak azonosító szerepet töltenek be, (hiszen erre a rajzolásra használt programok által alapértelmezésben adott „Use case 1”, „Use case 2” stb. stílusú azonosítók is alkalmasak lennének), hanem segít a diagram tartalmának megértésében.
Minden további modell típusra is általánosan érvényes az, hogy az elnevezési kényszer egyben annak ellenőrzése, hogy az adott funkciót, fogalmat, kapcsolatot – általánosságban minden modell elem jelentését pontosan megértettük-e. A tapasztalatok alapján elmondható, hogy ha egy modell elemre nem tudunk rövid, frappáns, kifejező elnevezést találni, annak mindig az az oka, hogy nem tisztáztuk pontosan az adott elem jelentését és a modellen belül játszott szerepét.
Minden vizuális modellező eszköznek van olyan funkciója, aminek segítségével az egyes modell elemekhez rövid, tömör, néhány mondatos leírást rendelhetünk. A használati eset modell dokumentációjának ez a második eleme. A tömör leírás segít abban, hogy a modellt könnyebben megértse a fejlesztésben résztvevők mindegyike.
A fejlesztés korai időszakában a leírásokkal kiegészített diagramok elegendőek a használati eset modell definiálására. A későbbi fázisokban ezt ki kell egészíteni a használati esetek által modellezett funkció végrehajtásának részletes leírásával, hiszen ezek alapján lehet megtervezni és implementálni a megvalósításért felelős szoftver elemeket.
Egy használati eset konkrét végrehajtási folyamatának leírását forgatókönyvnek nevezzük. Egy használati esethez számos forgatókönyv kapcsolódhat.
Minden használati esethez általában tartoznak előfeltételek, úgynevezett prekondíciók, amelyeknek teljesülése szükséges ahhoz, hogy bármelyik forgatókönyv alapján a funkció végrehajtható legyen. A végrehajtás után előálló állapotot nevezzük postkondíciónak (utóhatásnak).
A forgatókönyveket aktor interakció – rendszer válasz párok sorozataként specifikálhatjuk. Bonyolultabb használati esetek forgatókönyvét ezen felül aktivitás vagy szekvencia diagrammal is szemléltethetjük.
Gyakran hasznos az egyes használati esetek fontosságát. prioritását („rank”) is megadni, mert ez segíthet a fejlesztési munka ütemezésében. Általában az alacsony – közepes – magas prioritás skála elegendő.
A jegyzet UML ábráit a Visual Paradigm vizuális modellező szoftver oktatási verziójával készítettük. Ez a szoftver is lehetőséget ad arra, hogy az egyes modell elemekhez további információkat csatoljunk, és ezekből az információkból html, pdf vagy Microsoft Word formátumú dokumentációt generáljunk.
Az összefoglaló dokumentáció egy részlete a 8-15. ábra diagramjához:
Summary
Name Documentation
Pénztáros A pénztárgépet kezelő személy. Felelős az eladott áruk
regisztrálásáért és a pénz kezeléséért.
Blokkolás Az eladott áruk regisztrálása, a blokk elkészítése és a fizetendő összeg kijelzése.
Boltvezető Az üzlet vezetője. Bármikor helyettesítheti a
pénztárost.
Secondary Actor(s)
Brief Description Blokkolás
Preconditions A pénztárgép megnyitva
A pénztáros bejelentkezve.
Az előző blokk lezárva
Flow of Events
Actor Input System Response
1 Új vásárló
2 Új blokk niytása
Fizetendő összeg 0.
3 Vonalkód
beolvasás
4 Darabszám
megadás
5 Újabb blokk
tétel kiírása Fizetendő összeg növelése
6 Blokk lezárása
7 Végső fizetendő
összeg kiírása
8 A vevő által
átadott összeg beírása
9 Visszajáró pénz
kijelzése Kasszafiók kinyitása
Post-conditions Elkészült és kinyomtatásra került a blokk.
Alternative flows and exceptions Hibás darabszám lett megadva - stornózni kell!
Áru vonalkódjának ismételt beolvasása - stornózni kell!
Non-behavior requirements
Assumptions Issue Source
Author Ficsor Lajos
Date 2011.02.21. 22:49:26