jobbra|bélyegkép|Egy wikirendszer nagyon egyszerű használatieset-diagramja.
A szoftver- és rendszertervezésben a használati eset egy poliszéma, amelynek kétféleképpen értelmezhető:
Egy szoftver használati forgatókönyve; gyakran többes számban használják olyan helyzetekre utalva, amikor egy szoftver hasznos lehet. Egy lehetséges forgatókönyv, amelyben a rendszer külső kérést kap (például felhasználói bemenetet), és válaszol rá.
Ez a cikk az utóbbi jelentést tárgyalja.
A használati eset (use case) olyan műveletek vagy eseménylépések listája, amelyek jellemzően egy szerepkör (amely az Unified Modeling Language (UML) szereplőként [actor] ismert) és egy rendszer közötti interakciókat határozzák meg a cél elérése érdekében. A szereplő lehet ember vagy más külső rendszer. A rendszertervezésben a használati eseteket (use case-eket) magasabb szinten használják, mint a szoftverfejlesztésben, gyakran küldetéseket vagy érdekelt felek céljait képviselve. A részletes követelmények ezután rögzíthetők a Systems Modeling Language -ben (SysML) vagy szerződéses nyilatkozatok formájában.
Történelem 1987-ben Ivar Jacobson bemutatta az első használati esetekről (use case-ről) szóló cikket a OOPSLA '87 nevű konferencián. Leírta, hogyan használták ezt a technikát az Ericssonnál a rendszer követelményeinek rögzítésére és meghatározására szöveges, szerkezeti és vizuális modellezési technikák segítségével az objektumorientált elemzés és tervezés előmozdítása érdekében. Eredetileg a használati forgatókönyvek (usage scenarios) és a felhasználási eset (usage case) kifejezéseket használta – utóbbi az användningsfall svéd kifejezésének közvetlen fordítása volt –, de úgy találta, hogy ezek a kifejezések egyike sem hangzik természetesnek angolul, és végül a használati eset (use case) mellett döntött.
1992-ben Ivar Jacobson társszerzője volt az Object-Oriented Software Engineering – A Use Case Driven Approach című könyvnek, amely lefektette az OOSE rendszertervezési módszer alapjait, és elősegítette a funkcionális követelmények rögzítésére szolgáló használati esetek (use case for capturing functional requirementes) népszerűsítését, különösen a szoftverfejlesztésben . 1994-ben könyvet adott ki az üzleti modellekben és az üzleti folyamatok újratervezésében alkalmazott használati esetekről (use case-ről) és objektumorientált technikákról.
Ugyanakkor Grady Booch és James Rumbaugh objektumorientált elemzési és tervezési módszereik, a Booch-módszer és az Object Modeling Technique (OMT) egységesítésén dolgoztak. 1995-ben Ivar Jacobson csatlakozott hozzájuk, és együtt létrehozták az Unified Modeling Language (UML) nyelvet, amely magában foglalja a használati esetek modellezését (use case modelling). Az UML-t az Object Management Group (OMG) szabványosította 1997-ben. Jacobson, Booch és Rumbaugh az Objectory szoftverfejlesztési folyamat finomításán is dolgozott. Az így létrejött egységes folyamatot 1999-ben tették közzé, és egy használati eset-vezérelt (use case driven) megközelítést hirdettek.
Azóta sok szerző járult hozzá a technika kifejlesztéséhez, nevezetesen: Larry Constantine 1995-ben fejlesztette ki a felhasználás-központú tervezés kontextusában, az úgynevezett "esszenciális használati eseteket" ("essencial use-cases"), amelyek célja a felhasználói szándékok leírása, nem pedig a műveletek sorozata, vagy olyan forgatókönyvek, amelyek korlátozhatják vagy torzíthatják a felhasználói felület kialakítását; Alistair Cockburn 2000-ben publikált egy célorientált használati gyakorlatot, amely szöveges narratívákon és táblázatos specifikációkon alapul; Kurt Bittner és Ian Spence 2002-ben fejlett gyakorlatokat dolgozott ki a funkcionális követelmények felhasználási esetekkel történő elemzésére; Dean Leffingwell és Don Widrig javasolta a használati esetek (use case-ek) alkalmazását a változáskezelési (change management) és az érdekelt felekkel folytatott (stakeholder) kommunikációs tevékenységekben; Gunnar Overgaard 2004-ben javasolta a tervezési minták elveinek kiterjesztését a használati esetekre.
2011-ben Jacobson, Ian Spence, Kurt Bittner közösen kiadták a Use Case 2.0 című e-könyvet, hogy a technikát agilis kontextushoz igazítsa, növekményes használati eset "szeletekkel" (use case slices) gazdagítsa, és a teljes fejlesztési életcikluson keresztül népszerűsítse a használatát , miután bemutatta a megújult megközelítés az éves IIBA konferencián.
Általános elv A használati esetek (use case-ek) a rendszer követelményeinek rögzítésére, modellezésére és meghatározására szolgáló technika. A használati eset (use case) azoknak a viselkedéseknek a halmazának felel meg, amelyeket a rendszer a szereplőivel interakcióban hajthat végre, és amely olyan megfigyelhető eredményt produkál, amely hozzájárul a céljaihoz. A szereplők azt a szerepet képviselik, amelyet az emberi felhasználók vagy más rendszerek játszanak az interakcióban.
A követelményelemzésben (requirement analysis) azonosításukkor egy használati esetet aszerint neveznek el, hogy melyik felhasználói célt képviseli az elsődleges szereplő számára. Az esetet tovább részletezik egy szöveges leírás vagy további grafikus modellek, amelyek elmagyarázzák a tevékenységek és események általános sorrendjét, valamint olyan változatokat, mint a speciális feltételek, kivételek vagy hibahelyzetek.
A Software Engineering Body of Knowledge (SWEBOK) szerint a használati esetek (use case-ek) a forgatókönyv-alapú követelményfeltáró technikákhoz, valamint a modell alapú elemzési technikákhoz tartoznak. De a használati esetek (use case-ek) támogatják a narratív alapú követelménygyűjtést, a növekményes követelménygyűjtést, a rendszerdokumentációt és az elfogadási tesztelést is.
Variációk Különféle felhasználási esetek és változatok léteznek a technikában:
A rendszerhasználati esetek meghatározzák a fejlesztendő rendszer követelményeit. Részletes leírásukban nemcsak a szereplőkkel való interakciókat azonosítják, hanem a feldolgozásban részt vevő entitásokat is. Ezek jelentik a további elemzési modellek és tervezési tevékenységek kiindulópontját. Az üzleti felhasználási esetek egy üzleti szervezetre összpontosítanak szoftverrendszer helyett. Az üzleti folyamatok újratervezési kezdeményezéseivel összefüggésben az üzleti modellek és az üzleti folyamatokra vonatkozó követelmények meghatározására szolgálnak. Az alapvető használati esetek, amelyeket absztrakt használati eseteknek is neveznek, leírják a szereplők lehetséges szándékait, és azt, hogy a rendszer hogyan kezeli ezeket, anélkül, hogy bármilyen sorrendet vagy forgatókönyvet írnának le. Ezt a gyakorlatot azzal a céllal fejlesztették ki, hogy támogassa a felhasználó-központú tervezést, és elkerülje a felhasználói felület torzítását a rendszerspecifikációk korai szakaszában. A Use Case 2.0 adaptálja a technikát az agilis fejlesztési módszerek kontextusához. Ez a technika a felhasználói sztori narratívák támogatásával gazdagítja a követelménygyűjtési gyakorlatot. Ezenkívül használati eset "szeleteket" is biztosít, amelyek megkönnyítik a követelmények növekményes előhívását és lehetővé teszik a növekményes megvalósítást.
Hatókör A használati eset hatóköre tárgyonként és célokonként határozható meg:
Az alany azonosítja azt a rendszert, alrendszert vagy komponenst, amely az interakciókat biztosítja. A célok hierarchikusan strukturálhatók, figyelembe véve a célban érdekelt szervezeti szintet (pl. vállalat, részleg, felhasználó), illetve a felhasználó céljának részcélokra bontását. A cél dekompozíciója a felhasználók szemszögéből, rendszertől függetlenül történik, ami eltér a hagyományos funkcionális dekompozíciótól.
Használat Ismeretes, hogy a használati eseteket a következő összefüggésekben alkalmazzák:
Objektumorientált szoftverfejlesztés (OOSE), mint meghajtó elem; Unified Modeling Language (UML), mint viselkedésmodellező eszköz; Unified Software Development Process (UP) és elődje, az IBM Rational Unified Process (RUP) ; a szoftverkövetelmény-specifikáció (SRS) előzetes dokumentációja, mint a funkcionális követelmények alternatív struktúrája; a tervezés levezetése a követelményekből az entitás-ellenőrzés-határ megközelítés alkalmazásával; és agilis fejlesztés .
Sablonok Számos módja van a használati eset (use case) szövegben történő megírásának, a használati eset rövid, alkalmi, vázlattól, egészen felöltözve stb.ig, változatos sablonokkal. A felhasználási esetek írása különféle szállítók vagy szakértők által kidolgozott sablonokba bevett gyakorlat a kiváló minőségű funkcionális rendszerkövetelmények elérése érdekében.
Cockburn stílus Az Alistair Cockburn által a Hatékony használati esetek írása (Writning Effective Use Cases) című könyvében meghatározott sablon az egyik legszélesebb körben használt használati eset írási stílusa.
Tervező távcsövek Cockburn azt javasolja, hogy minden használati esetet jelöljön meg egy szimbólummal, amely megmutatja a "tervezési kört" ("Design Scope"), amely lehet fekete doboz (a belső részletek el vannak rejtve) vagy fehér doboz (a belső részletek láthatók). Öt szimbólum áll rendelkezésre:Cockburn, 2001. Inside front cover. Icons "Design Scope". Hatály Ikon Szervezet (fekete doboz) Tele ház Szervezet (fehér doboz) Töltetlen házközépre|Hatókör-ikonok-töltetlen-ház Rendszer (fekete doboz) Megtöltött dobozközépre|Hatókör-ikonok-töltött-doboz Rendszer (fehér doboz) Töltetlen dobozközépre|Hatókör-ikonok-töltetlen doboz Összetevő Csavarközépre|Hatókör-ikonok-csavar-csavar Más szerzők néha a szervezeti szintű használati eseteket „Üzleti felhasználási eseteknek” ("Business use cases")nevezik.Suzanne Robertson. Scenarios in Requirements Discovery. Chapter 3 in Alexander and Maiden, 2004. Pages 39-59.
Célszintek bélyegkép|A célszintek hierarchiája Cockburn azt javasolja, hogy minden használati esetet jelöljenek meg egy szimbólummal a „Célszint” ["Goal Level"] jelzésére;Cockburn, 2001. Inside front cover. Icons "Goal Level". az előnyben részesített szint a "Felhasználói cél" ["User-goal"] (vagy köznyelven "tengerszint" [sea level]Fowler, 2004. ). Célszint Ikon Szimbólum Magas szintű összefoglaló Felhő ++középre Összefoglaló Papír sárkány +középre Felhasználói cél Hullámok a tengeren !középre Alfunkció Hal -középre Alacsony Kagyló --középre Szövegírásban néha egy használati esetnév (use case name), majd egy alternatív szövegszimbólum (!, +, - stb.) tömörebb és kényelmesebb módja a szintek jelölésének, pl . rendelés leadásának!, bejelentkezés- .
Teljesen felöltöztetett (Fully dressed) A Cockburn sokkal részletesebb felépítést ír le egy használati esethez (use case-hez), de lehetővé teszi annak egyszerűsítését, ha kevesebb részletre van szükség. Teljesen öltözött használati eset sablonja a következő mezőket sorolja fel:Cockburn, 2001. Page 120.
Cím: "aktív igei célkifejezés, amely megnevezi az elsődleges szereplő célját"Cockburn, 2001. Inside rear cover. Field "Use Case Title". Elsődleges aktor Kontextuson belüli cél Hatókör Szint Érintettek és érdekek Előfeltétel Minimális garanciák A siker garanciái Kiváltó esemény A siker fő forgatókönyve Kiterjesztések Technológia és adatváltozatok listája
Ezenkívül Cockburn két eszköz használatát javasolja az egyes használati esetek jellegének jelzésére: ikonok a tervezési hatókörhöz (design scope) és a célszinthez (goal level).
Cockburn megközelítése más szerzőkre is hatással volt; például Alexander és Beus-Dukic általánosítja Cockburn "Teljesen felöltöztetett" („Fully dressed use case”) sablonját szoftverről mindenféle rendszerre. A következő mező térnek el a Cockburn-étől:Alexander and Beus-Dukic, 2009. Page 121
Változatos forgatókönyvek "(talán elágazás a fő forgatókönyvtől, és talán visszatér a főforgatókönyvhöz)" Kivételek "azaz kivételes események és azok kivételkezelési forgatókönyvei"
Alkalmi