Használati eset

  A szoftver- és rendszertervezésben a használati eset egy poliszéma, amelynek kétféleképpen értelmezhető:

1. Egy szoftver használati forgatókönyve; gyakran többes számban használják olyan helyzetekre utalva, amikor egy szoftver hasznos lehet.
2. 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á.

Egy wikirendszer nagyon egyszerű használatieset-diagramja.

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:

Hatály	Ikon
Szervezet (fekete doboz)	Tele ház	Scope-icons-filled-house
Szervezet (fehér doboz)	Töltetlen ház	Hatókör-ikonok-töltetlen-ház
Rendszer (fekete doboz)	Megtöltött doboz	Hatókör-ikonok-töltött-doboz
Rendszer (fehér doboz)	Töltetlen doboz	Hatókör-ikonok-töltetlen doboz
Összetevő	Csavar	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.

Célszintek

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; az előnyben részesített szint a "Felhasználói cél" ["User-goal"] (vagy köznyelven "tengerszint" [sea level] ).

Célszint	Ikon	Szimbólum
Magas szintű összefoglaló	Felhő	++
Összefoglaló	Papír sárkány	+
Felhasználói cél	Hullámok a tengeren	!
Alfunkció	Hal	-
Alacsony	Kagyló	--

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:

• Cím: "aktív igei célkifejezés, amely megnevezi az elsődleges szereplő célját"
• 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:

• 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

Cockburn felismeri, hogy a projekteknek nem mindig van szükségük részletes „teljesen felöltöztetett” ("fully dressed") használati esetekre. Ezért megfogalmazott egy alkalmi használati esetet a következő mezőkkel:

• Cím (cél)
• Elsődleges aktor
• Hatókör
• Szint
• (Sztori): a használati eset törzse egyszerűen egy-két bekezdésnyi szöveg, amely informálisan leírja, hogy mi történik.

Fowler stílus

Martin Fowler kijelenti: "Nincs szabványos módszer a használati eset tartalmának megírására, és a különböző formátumok jól működnek a különböző esetekben." A következőképpen fogalmazta meg "egy általánosan használható stílust":

• Cím: "cél, amelyet a használati eset próbál elérni"
• A siker fő forgatókönyve: a lépések számozott listája
  • Lépés: "egy egyszerű kijelentés a szereplő és a rendszer közötti interakcióról"
• Kiterjesztések: külön számozott listák, bővítményenként egy
  • Kiterjesztés: "olyan állapot, amely a fő sikerforgatókönyvtől eltérő interakciókat eredményez". A 3. fő lépésből származó kiterjesztés 3a stb. számmal van ellátva.

A Fowler-stílus a Cockburn-sablon egyszerűsített változataként is felfogható.

. . .

„Think of a User Story as a Use Case at 2 bits of precision. Bit 1 of precision names the goal of the use case, Bit 2 adds the main scenario. Bit 3 adds the failure conditions, Bit 4 adds the failure actions. Bit 5 adds data description of the in/out data. I would put Catalysis at a 6th bit of precision, as they include a model also of the recipient of the message. In the CrystalMethodology family differently founded projects use use cases at different levels of precision. A methodologically light project uses User Stories, a methodologically heavier project uses Use Cases to 4 bits of precision, and Catalysis uses 6 bits of precision.”

. . .

„It is all about how people use use cases. I've seen many people use use cases in a very formalized manner. Kent does his UserStories in a much more approachable manner. I do use cases the way Kent does User Stories. I call them use cases to better communicate with other developers and to influence them to use a more lightweight approach.”

Aktorok, szereplők, szerepkörök

A használati eset meghatározza a külső szereplők (más szóval aktorok) és a szóban forgó rendszer közötti interakciókat egy cél elérése érdekében. A szereplőknek képesnek kell lenniük döntéseket hozni, de nem kell embereknek lenniük: "Egy aktor lehet egy személy, egy vállalat vagy szervezet, egy számítógépes program vagy egy számítógépes rendszer – hardver, szoftver vagy mindkettő." A szereplők mindig érdekeltek, de nem minden érdekelt fél szereplő, mivel "soha nem lépnek kapcsolatba közvetlenül a rendszerrel, még akkor sem, ha joguk van érdekelni, hogyan viselkedik a rendszer". Például „a rendszer tulajdonosai, a vállalat igazgatótanácsa és az olyan szabályozó testületek, mint az Internal Revenue Service és a Department of Insurance” mind érintettek lehetnek, de nem valószínű, hogy szereplők.

Hasonlóképpen egy rendszert használó személy különböző szerepek miatt különböző szereplőkként jelenhet meg. Például a "Joe" felhasználó az Ügyfél szerepét töltheti be, amikor bankjegykiadó automatát használ készpénzfelvételre a saját számlájáról, vagy bankpénztári szerepkört tölthet be, amikor a rendszer segítségével feltölti a pénztárgépet a saját számlájáról. bank.

Az aktorok gyakran valaki más nevében dolgoznak. Cockburn azt írja, hogy „Manapság az „ügyfél értékesítési képviselője” vagy a „marketing osztály ügyintézője” kifejezéseket írom, hogy érzékeltessem, a rendszer felhasználója valaki más nevében jár el. Ez azt mondja a projektnek, hogy a "felhasználói felületet és a biztonsági tanúsítványokat" az értékesítési képviselőnek és az ügyintézőnek kell megtervezni, de az ügyfelek és a marketing osztály feladatai az eredményekkel kapcsolatban.

Az érdekelt felek egyaránt játszhatnak aktív és inaktív szerepet: például a Fogyasztó egyszerre "tömegpiaci vásárló" (nem lép interakcióba a rendszerrel) és Felhasználó (a megvásárolt termékkel aktívan interakcióba lépő szereplő). A Felhasználó viszont egyszerre „normál üzemeltető” (a rendszert rendeltetésszerűen használó szereplő) és „funkcionális haszonélvező” (a rendszer használatából hasznot húzó érintett). Például, amikor "Joe" felhasználó készpénzt vesz fel a számlájáról, akkor a pénzkiadó automatát üzemelteti, és a saját nevében szerez eredményt.

Cockburn azt tanácsolja, hogy keressenek szereplőket a rendszer érintettjei, egy használati eset elsődleges és támogató (másodlagos) szereplői, maga a tervezés alatt álló rendszer (SuD), végül a "belső szereplők", nevezetesen a rendszer összetevői között. tervezés alatt.

Üzleti felhasználási eset

Ugyanúgy, ahogy egy használati eset egy felhasználó (vagy más típusú szereplő) és egy rendszer közötti események és interakciók sorozatát írja le, annak érdekében, hogy értéket (célt) hozzon létre, az üzleti használati eset az általánosabb interakciót írja le. egy üzleti rendszer és a rendszer felhasználói/szereplői között, hogy értékes üzleti eredményeket hozzanak létre. Az elsődleges különbség az, hogy az üzleti használati esetmodellben figyelembe vett rendszer a technológiai rendszereken kívül személyeket is tartalmazhat. Ezeket a "rendszerbeli embereket" üzleti dolgozóknak hívják. Egy étterem példájában el kell dönteni, hogy minden embert szereplőként (tehát a rendszeren kívül) vagy üzleti dolgozóként (a rendszeren belül) kezelünk. Ha a pincért aktornak tekintjük, ahogy az az alábbi példában látható, akkor az éttermi rendszer nem tartalmazza a pincért, és a modell feltárja a pincér és az étterem közötti interakciót. Alternatív megoldásként a pincért az éttermi rendszer részének tekintjük (üzleti dolgozónak), míg az ügyfelet a rendszeren kívülinek (szereplőnek) tekintjük.

Az üzleti felhasználási eset diagramja több üzleti felhasználási eset (cél) modelljét ábrázolja, amely az étterem (az üzleti rendszer) és az elsődleges érdekelt felei (az üzleti szereplők és az üzleti dolgozók ) közötti interakciókat ábrázolja.

Vizuális modellezés

  A használati esetek nem csak szövegek, hanem szükség esetén diagramok is. Az egységes modellezési nyelvben a használati esetek és a szereplők közötti kapcsolatokat használati eset diagramok ábrázolják, amelyek eredetileg Ivar Jacobson Objectory jelölésén alapultak. A SysML ugyanazt a jelölést használja rendszerblokk szintjén.

Ezenkívül más viselkedési UML diagramok, például tevékenységdiagramok, szekvenciadiagramok, kommunikációs diagramok és állapotgép-diagramok is használhatók a használati esetek megfelelő megjelenítésére. Pontosabban, a System Sequence Diagram (SSD) egy szekvenciadiagram, amelyet gyakran használnak a külső szereplők és a tervezett rendszer (SuD) közötti interakciók bemutatására, általában egy használati eset egy adott forgatókönyvének megjelenítésére.

A használati esetek elemzése általában használati eset diagramok rajzolásával kezdődik. Az agilis fejlesztéshez a felhasználási eseteket ábrázoló UML-diagramok követelménymodellje, valamint néhány szöveges leírás, megjegyzés vagy használati esetre vonatkozó összefoglaló nagyon könnyű, és éppen elegendő kis vagy egyszerű projekthasználathoz. A használati esetek szövegeinek jó kiegészítéseként a használati esetek vizuális diagramábrázolásai hatékony segítő eszközök a komplex rendszer-viselkedési követelmények jobb megértéséhez, kommunikációjához és tervezéséhez.

Példák

Az alábbiakban a Cockburn-stílusú sablon enyhén módosított változatával írt használati minta látható. Ne feledje, hogy az alapvető használati esetleírásban nincsenek gombok, vezérlők, űrlapok vagy egyéb UI-elemek és műveletek, amelyekben csak a felhasználói célok, részcélok vagy szándékok jelennek meg az alapfolyamat vagy a bővítmények minden lépésében. Ez a gyakorlat egyértelműbbé teszi a követelményspecifikációt, és maximalizálja a tervezés és a megvalósítások rugalmasságát.

Használati eset : cikk szerkesztése

Elsődleges szereplő : Tag (Regisztrált felhasználó)

Hatáskör : Wiki rendszer

Szint : ! (Felhasználói cél vagy tengerszint)

Röviden : ( felhasználói történetnek vagy eposznak felel meg)

A tag az éppen olvasott cikk bármely részét (a teljes cikket vagy csak egy részét) szerkeszti. Az előnézet és a változtatások összehasonlítása megengedett a szerkesztés során.

Az érintettek

Az érdekelt felek egyaránt játszhatnak aktív és inaktív szerepet: például a Fogyasztó egyszerre "tömegpiaci vásárló" (nem lép interakcióba a rendszerrel) és Felhasználó (a megvásárolt termékkel aktívan interakcióba lépő szereplő). A Felhasználó viszont egyszerre „normál üzemeltető” (a rendszert rendeltetésszerűen használó szereplő) és „funkcionális haszonélvező” (a rendszer használatából hasznot húzó érintett). Például, amikor "Joe" felhasználó készpénzt vesz fel a számlájáról, akkor a pénzkiadó automatát üzemelteti, és a saját nevében szerez eredményt.

Utófeltételek

Minimális garanciák :

A siker garanciái :

• A cikk mentésre kerül, és egy frissített nézet jelenik meg.
• A cikkhez szerkesztési rekordot hoz létre a rendszer, így a cikk figyelői később értesülhetnek a frissítésről.

Előfeltételek :

Az engedélyezett szerkesztéssel rendelkező cikk megjelenik a tagnak.

Kiváltó okok :

A tag szerkesztési kérelmet indít a cikken (a teljes cikkre vagy csak egy szakaszra vonatkozóan).

Alapfolyamat :

1. A rendszer egy új szerkesztőterületet/dobozt biztosít, amely tele van a cikk összes releváns tartalmával és egy informatív szerkesztési összefoglalóval, amelyet a tag szerkeszthet. Ha a tag csak a cikk egy részét szeretné szerkeszteni, akkor csak a rész eredeti tartalma jelenik meg, a szerkesztési összefoglalóban automatikusan kitöltve a szakasz címét.
2. A tag addig módosítja a cikk tartalmát, amíg a tag elégedett nem lesz.
3. A tag kitölti a szerkesztési összefoglalót, közli a rendszerrel, ha meg akarja nézni ezt a cikket, és elküldi a szerkesztést.
4. A rendszer elmenti a cikket, naplózza a szerkesztési eseményt, és befejezi a szükséges utófeldolgozást.
5. A rendszer a cikk frissített nézetét mutatja be a tagnak.

Kiterjesztések :

2–3.

a. Előnézet megjelenítése:

1. A tag kiválasztja az Előnézet megjelenítése lehetőséget, amely elküldi a módosított tartalmat.
2. A rendszer újra lefutja az 1. lépést a megjelenített frissített tartalom hozzáadásával az előnézethez, és tájékoztatja a tagot, hogy a szerkesztéseit még nem mentette el, majd folytatja.

b. Változások megjelenítése:

1. A tag kiválasztja a Módosítások megjelenítése lehetőséget, amely elküldi a módosított tartalmat.
2. A rendszer újrafutja az 1. lépést, és megjeleníti a tag aktuális szerkesztései és a cikk legutóbbi mentett verziója közötti különbségek összehasonlításának eredményeit, majd folytatja.

c. A szerkesztés visszavonása:

1. A tag a Mégse lehetőséget választja.
2. A rendszer elveti a tag által végrehajtott változtatásokat, majd továbblép az 5. lépésre.

4a. Időtúllépés:

Szint : ! (Felhasználói cél vagy tengerszint)

Előnyök

Az agilis mozgalom kezdete óta az Extreme Programming felhasználói sztori technikája annyira népszerű, hogy sokak szerint ez az egyetlen és legjobb megoldás minden projekt agilis követelményeihez. Alistair Cockburn öt okot sorol fel, miért ír még mindig használati eseteket az agilis fejlesztésben .

1. A célnevek listája a legrövidebb összefoglalót nyújtja a rendszer által kínált dolgokról (még a felhasználói történeteknél is). Ezenkívül egy projekttervezési vázat is biztosít, amely a kezdeti prioritások, becslések, csapatelosztás és időzítés kialakításához használható.
2. Az egyes használati esetek sikerének fő forgatókönyve minden érintett számára megegyezést biztosít arról, hogy a rendszer alapvetően mit fog csinálni, és mit nem. Kontextust biztosít minden egyes sorkövetelményhez (pl. finomszemcsés felhasználói történetek), olyan kontextust, amelyet máshol nagyon nehéz elérni.
3. Az egyes használati esetek kiterjesztési feltételei keretet adnak minden olyan apró, ócska dolog kivizsgálására, amelyek valamilyen módon a fejlesztési idő és költségvetés 80%-át lefoglalják. Előretekintő mechanizmust biztosít, így az érdekeltek észrevehetik azokat a problémákat, amelyekre valószínűleg hosszú időre van szükség a válaszadáshoz. Ezeket a kérdéseket az ütemterv elé lehet és kell tenni, hogy a válaszok készen álljanak, amikor a fejlesztőcsapat hozzálát a feldolgozáshoz.
4. A használati esetbővítési forgatókönyv-részletek választ adnak a sok részletes, gyakran trükkös és figyelmen kívül hagyott üzleti kérdésre: "Mit tegyünk ebben az esetben?" Ez egy gondolkodási/dokumentációs keretrendszer, amely illeszkedik az if...akkor...egyéb kijelentéshez, és segít a programozóknak a problémák átgondolásában. Kivéve, hogy ez a vizsgálat idején történik, nem a programozási időben.
5. A teljes használati esetkészlet azt mutatja, hogy a vizsgálók minden felhasználó igényét, a rendszerrel kapcsolatos minden céljukat és minden érintett üzleti változatot végiggondoltak.

Összefoglalva, a rendszerkövetelmények használati esetekben történő meghatározása a következő nyilvánvaló előnyökkel jár a hagyományos vagy más megközelítésekhez képest:

Felhasználó összpontosít

A használati esetek hatékony, felhasználó-központú eszközt jelentenek a szoftverkövetelmények specifikációs folyamatához. A használati esetek modellezése jellemzően a rendszerrel interakcióban részt vevő kulcsfontosságú érdekelt szerepkörök ( szereplők ) és azok céljainak vagy célkitűzéseinek azonosításával kezdődik, amelyeket a rendszernek teljesítenie kell (külső nézőpont). Ezek a felhasználói célok ideális jelöltekké válnak a használati esetek neveihez vagy címeihez, amelyek a rendszer által biztosított kívánt funkcionális jellemzőket vagy szolgáltatásokat reprezentálják. Ez a felhasználó-központú megközelítés biztosítja, hogy az kerüljön fejlesztésre, ami valódi üzleti értékkel bír, és amit a felhasználó valóban szeretne, nem pedig a fejlesztői vagy a rendszer (belső) szemszögéből spekulált triviális funkciókat.

A használati esetek létrehozása évek óta fontos és értékes elemző eszköz a felhasználóközpontú tervezés (UCD) területén.

Jobb kommunikáció

A használati eseteket gyakran természetes nyelveken írják strukturált sablonokkal. Ez a szinte mindenki számára érthető narratív szöveges forma (olvasható követelménytörténetek), amelyet vizuális UML diagramok egészítenek ki, jobb és mélyebb kommunikációt tesz lehetővé az összes érdekelt fél között, beleértve az ügyfeleket, a végfelhasználókat, a fejlesztőket, a tesztelőket és a menedzsereket. A jobb kommunikáció minőségi követelményeket és ezáltal minőségi rendszereket eredményez.

Minőségi követelmények strukturált feltárással

Az egyik legerősebb dolog a használati esetekkel kapcsolatban a használati esetsablonok formátumában rejlik, különösen a fő sikerforgatókönyvben (alapfolyamat) és a kiterjesztési forgatókönyv-részletekben (bővítmények, kivételes és/vagy alternatív folyamatok). Egy használati eset elemzése lépésről lépésre az előfeltételektől az utófeltételekig, a használati esetfolyamatok minden műveleti lépésének feltárása és vizsgálata az alaptól a kiterjesztésekig, hogy azonosítsa azokat a trükkös, általában rejtett és figyelmen kívül hagyott, triviálisnak tűnő, de reálisan gyakran költséges követelményeket (amint azt Cockburn említette fent), egy strukturált és előnyös módja a világos, stabil és minőségi követelmények szisztematikus elérésének.

Egy használati eset cselekvési lépéseinek minimalizálása és optimalizálása a felhasználói cél elérése érdekében szintén hozzájárul a rendszer jobb interakciós kialakításához és felhasználói élményéhez .

A tesztelés és a felhasználói dokumentáció megkönnyítése

A művelet- vagy eseményfolyam-struktúrán alapuló tartalommal a jól megírt használati esetek modellje kiváló alapot és értékes iránymutatást is nyújt a rendszer vagy termék teszteseteinek és felhasználói kézikönyveinek megtervezéséhez, ami megtérülő befektetés. elölről. Nyilvánvaló összefüggések vannak egy használati eset áramlási útvonalai és a tesztesetek között. A funkcionális tesztesetek levezetése használati esetből a forgatókönyvein keresztül (egy használati eset példányainak futtatása) egyszerű.

Korlátozások

A felhasználási esetek korlátozásai a következők:

• A felhasználási esetek nem alkalmasak egy rendszer nem interakción alapuló követelményeinek (például algoritmus vagy matematikai követelmények) vagy nem funkcionális követelmények (például platform, teljesítmény, időzítés vagy biztonságkritikus szempontok) rögzítésére. Ezeket inkább máshol deklaratív módon határozzuk meg.
• Mivel a használati esetekre nincsenek teljesen szabványos definíciók, minden projektnek saját értelmezést kell kialakítania.
• Egyes használati esetkapcsolatok, például a kiterjesztések értelmezése nem egyértelmű, és az érintettek számára nehéz lehet megérteni, amint arra Cockburn is rámutatott (6. probléma) 
• A használati esetek fejlesztői gyakran nehezen tudják meghatározni a felhasználói felület (UI) függőség szintjét, amelyet be kell építeni egy használati esetbe. Míg a használati esetek elmélete azt sugallja, hogy a felhasználói felület nem tükröződik a használati esetekben, kényelmetlen lehet a tervezés ezen aspektusának absztrahálása, mivel ez megnehezíti a használati esetek megjelenítését. A szoftverfejlesztésben ezt a nehézséget a követhetőség követelményeinek alkalmazásával oldják meg, például egy nyomon követési mátrixszal . Az UI-elemek használati esetekhez való társításának másik módja az, hogy a használati eset minden lépéséhez csatolni kell egy UI-tervet. Ezt használati eset storyboard-nak hívják.
• A használati esetek túlhangsúlyozhatók. Bertrand Meyer olyan kérdéseket tárgyal, mint a vezetési rendszer tervezése túlságosan szó szerint a használati esetekből, és a használati esetek felhasználása, kizárva az egyéb potenciálisan értékes követelményelemzési technikákat.
• A használati esetek a teszttervezés kiindulópontjai, de mivel minden tesztnek saját sikerkritériumra van szüksége, előfordulhat, hogy a használati eseteket módosítani kell, hogy külön utófeltételeket biztosítsanak minden egyes útvonalhoz.
• Bár a használati esetek magukban foglalják a célokat és összefüggéseket, függetlenül attól, hogy a célok mögött meghúzódó célok és motivációk (az érdekelt felekkel kapcsolatos aggodalmaik és értékeléseik, beleértve az interakció hiányát) ütköznek egymással, vagy negatívan/pozitívan befolyásolják más rendszercélokat, célorientált követelménymodellezési technikák tárgyát képezik (például BMM, I. *, KAOS és ArchiMate ARMOR).

Tévhitek

A használati esetekkel kapcsolatos gyakori félreértések a következők:

A felhasználói történetek agilisak; használati esetek nem.

Az Agile és a Scrum semlegesek a követelménytechnikák tekintetében. Ahogy a Scrum Primer kijelenti,

A termékhátralék tételei bármilyen világos és fenntartható módon vannak megfogalmazva. A közkeletű félreértésekkel ellentétben a Termékhátralék nem tartalmaz "felhasználói történeteket"; egyszerűen elemeket tartalmaz. Ezeket az elemeket felhasználói történetként, használati esetként vagy bármilyen más követelmény-megközelítésként lehet kifejezni, amelyet a csoport hasznosnak talál. Bármi legyen is a megközelítés, a legtöbb elemnek az ügyfelek számára történő értékteremtésre kell összpontosítania.

A használati esettechnikák úgy fejlődtek, hogy figyelembe vegyék az agilis megközelítéseket azáltal, hogy használati esetszeleteket használnak a használati esetek fokozatos gazdagításához.

A felhasználási esetek főleg diagramok.

Craig Larman hangsúlyozza, hogy "a használati esetek nem diagramok, hanem szövegek".

A használati esetek túl sok felhasználói felülettel kapcsolatos tartalommal rendelkeznek.

Ahogy egyesek fogalmaznak, 

A használati esetek gyakran tartalmaznak olyan részletezési szintet (pl. a címkék és gombok elnevezését), amelyek miatt nem alkalmasak egy új rendszer követelményeinek a semmiből való rögzítésére.

Kezdő félreértések. Egy jól megírt használati eset minden lépése bemutatja a szereplő céljait vagy szándékait (a funkcionális követelmények lényegét), és általában nem tartalmazhat semmilyen felhasználói felület részletet, pl. címkék és gombok elnevezése, felhasználói felület műveletei stb., ami rossz . gyakorlatot, és szükségtelenül bonyolítja a használati eset írását és korlátozza annak megvalósítását.

Ami egy új rendszer követelményeinek a semmiből történő rögzítését illeti, a használati esetek diagramjait és a használati esetleírásokat gyakran praktikus és értékes eszközként használják, amelyek legalább olyan könnyűek, mint a felhasználói történetek. 

A nagy rendszerek használati eseteinek írása fárasztó és időpocsékolás.

Ahogy egyesek fogalmaznak, 

A használati eset formátuma megnehezíti egy nagy rendszer leírását (pl CRM rendszer) kevesebb mint több száz oldalon. Ez időigényes, és azt tapasztalhatja, hogy feleslegesen sok átdolgozással tölti az időt.

 

Ha sok időt töltünk olyan unalmas használati esetek írásával, amelyek nem vagy csak csekély értéket adnak hozzá, és sok átdolgozást eredményeznek, az rossz szag arra utal, hogy az írók nem elég képzettek, és kevés tudásuk van a minőségi használati esetek hatékony és eredményes megírásáról. A használati eseteket iteratív, növekményes és evolúciós ( agilis ) módon kell megírni. A használati esetsablonok alkalmazása nem jelenti azt, hogy egy használati eset sablon összes mezőjét átfogóan kell használni és ki kell tölteni elölről vagy egy speciális dedikált szakaszban, azaz a hagyományos vízesés -fejlesztési modell követelményfázisában.

Valójában az ilyen népszerű sablonstílusok által megfogalmazott használati esetformátumok, pl. a RUP és a Cockburn (szintén az OUM módszerrel átvett) stb., a gyakorlatban értékes és hasznos eszközöknek bizonyultak az összetett követelmények rögzítésére, elemzésére és dokumentálására. nagy rendszerek. A jó használati esetdokumentáció ( modell ) minőségét nem szabad nagyrészt, vagy csak a mérete alapján megítélni. Az is lehetséges, hogy egy nagy rendszer minőségi és átfogó használati esetmodellje végül több száz oldalassá fejlődik, elsősorban a probléma eredendő összetettsége miatt, nem pedig a szerzők gyenge íráskészsége miatt. 

Eszközök

A használati esetek írásához gyakran használnak szövegszerkesztőket és/vagy szövegszerkesztőket sablontámogatással. Nagy és összetett rendszerkövetelmények esetén a dedikált használati esetekre vonatkozó eszközök hasznosak.

Néhány jól ismert használati eset eszköz:

• Case Complete
• Vállalati építész
• MagicDraw
• A Rational Software RequisitePro – az egyik korai, jól ismert használati eset- és követelménykezelő eszköz az 1990-es években.
• Szoftverötletek modellező
• Wiki-szoftver – jó eszközök csapatok számára a felhasználási esetek közös létrehozásához és kezeléséhez.

A legtöbb UML-eszköz támogatja a szövegírást és a használati esetek vizuális modellezését.

Lásd még

• Visszaélési ügy
• Üzleti eset
• Entitás-vezérlés-határ
• Esemény particionálás
• Funkció
• Az UML-eszközök listája
• Visszaélés esete
• Követelmény
• Követelmények feltárása
• Forgatókönyv
• Storyboard
• Próbaper
• Használjon esetpontokat

Fordítás

• Ez a szócikk részben vagy egészben az Use case című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.

További irodalom

• Alexander, Ian és Beus-Dukic, Ljerka. Követelmények feltárása: Termékek és szolgáltatások meghatározása . Wiley, 2009.
• Alexander, Ian és Maiden, Neil. Forgatókönyvek, történetek, használati esetek . Wiley 2004.
• Páncél, Frank és Granville Miller. Haladó használati esetmodellezés: Szoftverrendszerek . Addison-Wesley, 2000.
• Kurt Bittner, Ian Spence, Use Case Modeling, Addison-Wesley Professional, 2002. augusztus 20.
• Cockburn, Alistair. Hatékony használati esetek írása. Addison-Wesley, 2001.
• Larry Constantine, Lucy Lockwood, Használati szoftver: Gyakorlati útmutató a használat-központú tervezés alapvető modelljéhez és módszereihez, Addison-Wesley, 1999.
• Denney, Richard. Sikeres használati esetek: Dolgozzon okosan a minőség érdekében . Addison-Wesley, 2005.
• Fowler, Martin. UML desztillált (harmadik kiadás) . Addison-Wesley, 2004.
• Jacobson Ivar, Christerson M., Jonsson P., Övergaard G., Object-Oriented Software Engineering – A Use Case Driven Approach, Addison-Wesley, 1992.
• Jacobson Ivar, Spence I., Bittner K. 2.0 használati eset: The Guide to Succeeding with Use Cases, IJI SA, 2011.
• Dean Leffingwell, Don Widrig, Managing Software Requirements: A Use Case Approach, Addison-Wesley Professional. 2012. december 7.
• Kulak, Daryl és Eamonn Guiney. Használati esetek: követelmények a kontextusban. Addison-Wesley, 2012.
• Meyer, Bertrand. Objektumorientált szoftverkonstrukció. (2. kiadás). Prentice Hall, 2000.
• Schneider, Geri és Winters, Jason P. Alkalmazási esetek alkalmazása 2. kiadás: Gyakorlati útmutató . Addison-Wesley, 2001.
• Wazlawick, Raul S. Objektumorientált elemzés és tervezés információs rendszerek számára: Modellezés UML, OCL és IFML segítségével . Morgan Kaufmann, 2014.

Külső linkek

• Alistair Cockburn használati eset oszlopa és alapvető használati esetsablonja
• Használati esetek a GSA Usability.gov webhelyén
• Használati esetek alkalmazása az Academia.edu "Project Icarus" érdekelt felek elemzéséhez
• Keressen rá a „use case” kifejezésre az IBM Developernél