Használati eset , használati eset, használati eset ( eng. use case ) - a szoftverfejlesztésben és a rendszertervezésben ez a rendszer viselkedésének leírása, amikor az interakcióba lép valakivel (vagy valamivel) a külső környezetből. A rendszer képes válaszolni a színész külső kérésére ( angol színész , oroszul a hangsúly az első szótagon van; használható az Actant [1] kifejezés ), maga is interakció kezdeményezője lehet. Más szavakkal, a használati eset leírja, hogy "ki" és "mit" tehet a kérdéses rendszerrel, vagy mit tehet a rendszer a "ki" vagy "mit" kifejezéssel. A használati eset módszertana a rendszer viselkedési követelményeinek azonosítására szolgál , más néven felhasználói és funkcionális követelmények.
A rendszertervezésben a használati eseteket magasabb szinten alkalmazzák, mint a szoftverfejlesztésben, gyakran az érintettek céljait vagy küldetéseit képviselve. A követelményelemzés szakaszában a használati esetek részletes követelmények készletévé alakíthatók, és SysML követelménydiagramok vagy más hasonló mechanizmusok segítségével dokumentálhatók.
1986-ban Ivar Jakobson , az Unified Modeling Language (UML) és a Rational Unified Process (RUP) későbbi társfeltalálója először fogalmazott meg egy vizuális modellezési technikát a használati esetek leírására. Kezdetben kissé eltérő kifejezéseket használt - eng. használati forgatókönyvek és használati esetek , de egyik sem volt természetes az angol nyelv számára. És végül a használati eset – használati eset kifejezés mellett döntött. A Jakobson használati esetmodellezési módszertanának kifejlesztése óta számos szoftvermérnök hozzájárult a módszertan tökéletesítéséhez, köztük Kurt Bittner, Alistair Coburn , Gunner Overgaard és Jerry Schneider.
Az 1990-es években a használati esetek az egyik leggyakoribb technikává váltak a funkcionális követelmények dokumentálására, különösen abban az objektumorientált környezetben, amelyből származtak. Használatuk azonban nem korlátozódik az objektumorientált rendszerekre, mivel a használati esetek nem objektumorientáltak.
„Minden használati eset egy cél vagy célkitűzés elérésének leírására összpontosít. A legtöbb szoftverprojekt esetében ez azt jelenti, hogy sok használati esetre lesz szükség az új rendszer kívánt tulajdonságkészletének meghatározásához. A szoftverprojekt formalitási foka és szakasza befolyásolja az egyes használati esetekhez szükséges részletességi szintet.”
A használati eseteket nem szabad összetéveszteni a rendszertulajdonságok fogalmával ( angol jellemző ). Egy használati eset egy vagy több rendszertulajdonsághoz, egy tulajdonság pedig egy vagy több használati esethez társítható.
A használati eset a külső ágensek és a rendszer közötti interakciókat határozza meg, amelyek célja a cél elérése. A színész egy olyan szerep, amelyet egy személy vagy dolog játszik el, amikor interakcióba lép egy rendszerrel. Ugyanaz a személy, aki a rendszert használja, különböző szereplőként ábrázolható, mert különböző szerepet tölt be. Például "Jack" betöltheti az ATM-et készpénzfelvételre használó Ügyfél szerepét, vagy a banki alkalmazott szerepét, aki a rendszert az ATM-be bankjegyekkel való feltöltésére használja.
A használati esetek a rendszert "fekete dobozként" kezelik, és a rendszerrel való interakciókat, beleértve a rendszer válaszait is, egy külső megfigyelő szemszögéből írják le. Ez egy szándékos politika, mert arra kényszeríti a szerzőt, hogy arra összpontosítson, mit kell tennie a rendszernek, nem pedig arra, hogyan kell csinálni, és elkerüli, hogy feltételezéseket tegyen a funkcionalitás megvalósításáról.
A használati esetek leírhatók egy altartományt leíró elvont szinten (üzleti használati eset, néha kulcshasználati esetnek is nevezik), vagy rendszerszinten (rendszerhasználati eset). A köztük lévő különbség a részletekben rejlik.
A használati esetnek:
Alistair Coburn a Writing Effective Use Cases című könyvében három részletszintet azonosított a használati esetekben:
Egyes szoftverfejlesztési folyamatok esetében egy egyszerű használati eset elegendő a rendszerkövetelmények meghatározásához. Másoknak sok részletes használati esetre van szükségük. Általánosságban elmondható, hogy minél nagyobb és összetettebb a projekt, annál valószínűbb, hogy sok részletes forgatókönyvet kell alkalmazni.
A használati esetek részletessége gyakran a projekt szakaszától függ. A kezdeti forgatókönyvek rövidek lehetnek, de a projekt előrehaladtával egyre részletesebbek lesznek. Ez a felhasználási esetekre vonatkozó eltérő követelményeket tükrözi. Kezdetben csak rövidek legyenek, mivel arra szolgálnak, hogy a felhasználó szemszögéből megismerjék az általános üzleti követelményeket. A későbbi rendszerépítés során azonban a fejlesztőknek sokkal konkrétabb és részletesebb útmutatásra van szükségük.
A Rational Unified Process (RUP) arra ösztönzi a fejlesztőket, hogy a használati esetek rövid leírását használják a használati esetek diagramjában, a szokásos részletezettséggel megjegyzésként és részletes leírással a szövegelemzésben. A szkriptek dokumentálhatók speciális eszközökkel (pl . UML Tool , SysML Tool), vagy normál szövegszerkesztőben írhatók.
Az Egységes Modellező Nyelvben a használati esetek egésze vagy egy része és a szereplők közötti kapcsolatokat használati eset diagram formájában, vagy eredetileg Ivar Jakobson objektumjelölése alapján diagramokban ábrázolják. A SysML ugyanazt a reprezentációt használja rendszerszinten.
Az UML használati esetdiagramjaiban a forgatókönyv ellipszisként jelenik meg . Az ellipszisben vagy alatta található az elem neve.
A következő típusú kapcsolatok vonatkoznak az UML használati eseteire:
Többek között a precedensek között:
A szkriptek fejlesztési folyamatban való használatának lehetőségei az alkalmazott fejlesztési módszertől függenek. Egyes fejlesztési módszereknél csak a forgatókönyv rövid áttekintésére van szükség. A többi felhasználási eset bonyolultabbá válik, és a fejlesztés során megváltozik. Egyes módszerekben ezek rövid üzleti esetekként indulhatnak, részletes rendszerhasználati esetekké fejlődhetnek, majd rendkívül részletes és kimerítő tesztekké nőnek.
Nincs szabványos sablon a részletes használati esetek dokumentálására. Sok versengő séma létezik, de a legjobb, ha azokat a sablonokat használja, amelyek a legjobban megfelelnek a projektnek. Érdemes azonban megemlíteni azokat a főbb pontokat, amelyekre érdemes odafigyelni.
Szkript neve A szkript nevét ige-főnév formátumban kell írni (pl. Könyvek kölcsönzése, Készpénzfelvétel). Le kell írnia egy elérhető célt (például a Felhasználó regisztrálása jobb, mint a Felhasználó regisztrálása), és meg kell magyaráznia a használati eset jelentését. Célszerű a szkript nevét, a szereplő célját használni, így biztosítva a felhasználó igényeinek figyelembevételét. Két-három szó a legjobb. Ha több szó van a névben, akkor általában rövidebb és informatívabb név van. Cél Cél nélkül a forgatókönyv használhatatlan. Nincs szükség használati esetre, amikor a cél eléréséhez nincs szükség egyetlen szereplőre sem. A cél röviden leírja, hogy a felhasználó mit kíván elérni ezzel a forgatókönyvvel. Színészek (színész) A cselekvő olyan valaki vagy valami, aki a rendszeren kívül van, és befolyásolja a rendszert, vagy akit a rendszer befolyásol. A szereplő lehet egy személy, egy eszköz, egy másik rendszer vagy alrendszer vagy idő. Egy embert a való világban több szereplő is képviselhet, ha a rendszerrel kapcsolatban több különböző szerepe és célja van. Kölcsönhatásba lépnek a rendszerrel, és bizonyos műveleteket hajtanak végre rajta. Érintettek ( Stakeholders ) Érintettek – A használati eset által érintett személy vagy részleg. Ezek általában annak a szervezetnek vagy részlegnek az alkalmazottai, amelyhez a forgatókönyv készül. Az érdekelt felet felkérhetik, hogy adjon tájékoztatást, visszajelzést vagy engedélyt egy használati esethez. Előfeltételek Érdemes definiálni mindazon feltételeket, amelyeknek igaznak kell lenniük (vagyis le kell írni a rendszer állapotát), amelyek mellett a script végrehajtásának van értelme. Így, ha a rendszer nincs az előfeltételekben leírt állapotban, akkor a szkript viselkedése nem definiálható. Vegye figyelembe azt is, hogy az előfeltételek nem „aktivátorok” (lásd alább). Mert a megfelelő előfeltételek NEM indítják el a szkript végrehajtását. Aktivátorok Az aktivátor egy olyan esemény, amely egy szkript végrehajtását váltja ki. Ez az esemény lehet külső, ideiglenes vagy belső. Ha az aktiváló nem valós esemény (például a kliens megnyom egy gombot), hanem összetett feltételek sorozata, akkor érdemes leírni az aktiválási folyamatot. Ennek a folyamatnak rendszeresen vagy folyamatosan ellenőriznie kell az aktiválási feltételeket, és elindítania kell a szkriptet.Többféleképpen is leírhatjuk azt a helyzetet, amikor aktiválás történik, de az előfeltételek nem teljesülnek.