Případ použití - Use case

Bylo navrženo, že Scénář (výpočet) být sloučeny do tohoto článku. (Diskutujte) Navrhováno od června 2020.

Velmi jednoduché použít případový diagram a Wiki Systém.

v software a systémové inženýrství, a případ použití je seznam akcí nebo kroků události obvykle definujících interakce mezi rolí (známou v Unifikovaný Modelovací Jazyk (UML) jako herec ) a systém k dosažení cíle. Aktérem může být člověk nebo jiný externí systém. V systémovém inženýrství se případy použití používají na vyšší úrovni než v rámci softwarové inženýrství, často zastupující mise nebo zúčastněná strana cíle. Podrobné požadavky pak mohou být zachyceny v Systémový modelovací jazyk (SysML) nebo jako smluvní prohlášení.

Dějiny

V roce 1987 Ivar Jacobson představuje první článek o případech použití na OOPSLA Konference '87.^[1] Popisuje, jak byla tato technika používána Ericson zachytit a specifikovat požadavky systému pomocí textových, strukturálních a vizuální modelování techniky řízení objektově orientované analýzy a návrhu.^[2] Původně používal tyto výrazy scénáře použití a případ použití - posledně jmenovaný přímý překlad jeho švédského výrazu användningsfall - ale zjistil, že ani jeden z těchto výrazů nezní v angličtině přirozeně, a nakonec se rozhodl případ použití.^[3]

V roce 1992 je spoluautorem knihy Objektově orientované softwarové inženýrství - přístup založený na konkrétních případech použití,^[4] který položil základ OOSE metoda systémového inženýrství a pomohla popularizovat případy použití pro snímání funkční požadavky, speciálně v vývoj softwaru. V roce 1994 vydává knihu o případech použití a objektově orientovaných technikách obchodní modely a reengineering obchodních procesů.^[5]

Ve stejnou dobu, Grady Booch a James Rumbaugh práce na sjednocení jejich objektově orientovaná analýza a návrh metody, Boochova metoda a Technika modelování objektů (OMT) resp. V roce 1995 se k nim přidal Ivar Jacobson a společně vytvářejí Unified Modeling Language (UML), který zahrnuje modelování případů použití. UML je standardizován Skupina správy objektů (OMG) v roce 1997.^[6] Jacobson, Booch a Rumbaugh také pracují na zdokonalení Objektivní proces vývoje softwaru. Výsledný Sjednocený proces je publikován v roce 1999 a podporuje přístup založený na konkrétních případech.^[7]

Od té doby přispělo k vývoji techniky mnoho autorů, zejména: Larry Constantine se vyvíjí v roce 1995 v kontextu design zaměřený na použití, takzvané „základní případy použití“, jejichž cílem je popsat spíše uživatelské záměry než posloupnosti akcí nebo scénářů, které by mohly omezovat nebo zkreslovat design uživatelského rozhraní;^[8] Alistair Cockburn v roce 2000 publikuje cíleně zaměřenou případovou praxi založenou na příbězích textu a tabulkových specifikacích;^[9] Kurt Bittner a Ian Spence vyvíjejí v roce 2002 pokročilé postupy pro analýzu funkčních požadavků s případy použití;^[10] Dean Leffingwell a Don Widrig navrhují použít případy použití ke změně činností správy a komunikace se zúčastněnými stranami;^[11] Gunnar Overgaard navrhl v roce 2004 rozšířit principy návrhových vzorů na případy použití.^[12]

V roce 2011 publikuje Jacobson s Ianem Spenceem a Kurtem Bittnerem e-knihu Použijte případ 2.0 přizpůsobit techniku ​​agilnímu kontextu, obohatit ji o přírůstkové „řezy“ případu použití a propagovat její použití v celém životním cyklu vývoje^[13] poté, co na výroční konferenci představil obnovený přístup IIBA konference.^[14][15]

Obecná zásada

Případy použití jsou technikou pro zachycení, modelování a specifikaci požadavků systému.^[10] Případ použití odpovídá souboru chování, které může systém provádět v interakci s jeho aktéry, a které vytváří pozorovatelný výsledek, který přispívá k jeho cílům. Herci představují roli, kterou v interakci mají lidští uživatelé nebo jiné systémy.

V analýza požadavků, při jejich identifikaci je případ použití pojmenován podle konkrétního cíle uživatele, který představuje pro svého primárního aktéra. Případ je dále podrobně popsán textovým popisem nebo dalšími grafickými modely, které vysvětlují obecný sled činností a událostí a také varianty, jako jsou speciální podmínky, výjimky nebo chybové situace.

Podle Těleso znalostí softwarového inženýrství (SWEBOK),^[16] případy použití patří do scénáře vyvolání požadavku techniky, stejně jako modelová analýza techniky. Případy použití ale také podporují shromažďování požadavků založených na příběhu, přírůstkové získávání požadavků, dokumentaci systému a akceptační testování.^[1]

Variace

Existují různé druhy případů použití a variace v technice:

• Případy použití systému specifikují požadavky systému, který má být vyvinut.^[2] Ve svém podrobném popisu identifikují nejen interakce s aktéry, ale také subjekty, které se na zpracování podílejí. Jsou výchozím bodem pro další analytické modely a návrhové činnosti.
• Obchodní případy použití se zaměřují na obchodní organizaci místo na softwarový systém. Používají se ke specifikaci obchodních modelů a požadavků obchodních procesů v kontextu iniciativ reengineeringu obchodních procesů.^[5]
• Základní případy použití, nazývané také abstraktní případy použití, popisují potenciální záměry aktérů a způsob, jakým je systém řeší, aniž by definoval jakoukoli sekvenci nebo popisoval scénář.^[8] Tato praxe byla vyvinuta s cílem podpořit design zaměřený na uživatele a zabránit vyvolání zaujatosti ohledně uživatelského rozhraní v rané fázi specifikací systému.^[7]
• Pouzdro Use 2.0 upravuje techniku ​​pro kontext agilních vývojových metod.^[1] Tato technika obohacuje praxi shromažďování požadavků o podporu vyprávění příběhů uživatelů. Poskytuje také "řezy" případu použití, které usnadňují přírůstkové vyvolání požadavků a umožňují přírůstkovou implementaci.

Rozsah

Rozsah případu použití lze definovat podle předmětu a cílů:

• Subjekt identifikuje systém, subsystém nebo komponentu, která zajistí interakce.^[17]
• Cíle lze hierarchicky strukturovat s přihlédnutím k organizační úrovni zajímající se o cíl (např. Společnost, oddělení, uživatel) a rozkladu cíle uživatele na dílčí cíle.^[9] Rozklad cíle se provádí z pohledu uživatelů a nezávisle na systému, který se liší od tradičního funkčního rozkladu.^[10]  

Používání

Je známo, že případy použití se používají v následujících kontextech:

• Objektově orientované softwarové inženýrství (OOSE), jako hnací prvek;^[4]
• Unifikovaný Modelovací Jazyk (UML), jako nástroj pro modelování chování;^[17]
• Unified Software Development Process (UP) a jeho předchůdce, IBM Rational Unified Process (RUP);^[7]

• úvodní dokumentace specifikace softwarových požadavků (SRS), jako alternativní struktura pro funkční požadavky;^[18]
• odvození návrhu od požadavků pomocí hranice entity-kontroly přístup;^[7]
• a agilní vývoj.^[1][19]

Šablony

Existuje mnoho způsobů, jak napsat případ použití v textu, z stručný případ použití, neformální, obrys, do plně oblečený atd. a s různými šablonami. Zápis případů použití do šablon navržených různými prodejci nebo odborníky je běžnou praxí v oboru, jak získat vysoce kvalitní funkční systémové požadavky.

Cockburn styl

Šablona definovaná uživatelem Alistair Cockburn ve své knize Psaní případů efektivního použití byl jedním z nejpoužívanějších stylů psaní případů použití.^{[Citace je zapotřebí ]}

Rozsahy návrhu

Cockburn navrhuje anotovat každý případ použití symbolem pro zobrazení „Design Scope“, což může být černá skříňka (vnitřní detail je skrytý) nebo bílá skříňka (vnitřní detail je zobrazen). K dispozici je pět symbolů:^[20]

Rozsah	Ikona
Organizace (black-box)	Plněný dům
Organizace (bílá skříňka)	Neplněný dům
Systém (černá skříňka)	Plněná krabice
Systém (bílá skříňka)	Nevyplněná krabice
Součástka	Šroub nebo šroub

Jiní autoři někdy nazývají případy použití na úrovni organizace „Obchodní případy použití“.^[21]

Úrovně cílů

Hierarchie úrovní cílů

Cockburn navrhuje anotovat každý případ použití symbolem, který ukazuje „úroveň cíle“;^[22] preferovaná úroveň je „Uživatelský cíl“ (nebo hovorově „hladina moře“)^[23]:101).

Úroveň cíle	Ikona	Symbol
Velmi vysoké shrnutí	Mrak	++
souhrn	Létající drak	+
Cíl uživatele	Vlny na moři	!
Dílčí funkce	Ryba	-
Příliš nízká	Mořské dno škeble	--

Někdy je při psaní textu výstižnější a pohodlnější způsob označení úrovní název případu použití, za nímž následuje alternativní textový symbol (!, +, - atd.), Např. objednat!, přihlásit se-.

Plně oblečený

Cockburn popisuje podrobnější strukturu případu použití, ale umožňuje její zjednodušení, pokud je zapotřebí méně podrobností. Jeho plně oblečená šablona případu použití uvádí následující pole:^[24]

• Název: „fráze cíle aktivního slovesa, která pojmenuje cíl primárního aktéra“^[25]
• Primární herec
• Cíl v kontextu
• Rozsah
• Úroveň
• Zúčastněné strany a zájmy
• Předpoklad
• Minimální záruky
• Záruky úspěchu
• Spoušť
• Hlavní scénář úspěchu
• Rozšíření
• Seznam technologií a datových variací

Cockburn navíc navrhuje použít dvě zařízení k označení povahy každého případu použití: ikony pro rozsah návrhu a úroveň cíle.

Cockburnův přístup ovlivnil další autory; například Alexander a Beus-Dukic zobecňují Cockburnovu šablonu „Plně oblečeného případu použití“ od softwaru po systémy všeho druhu, přičemž následující pole se od Cockburna liší:^[26]

• Variační scénáře „(možná odbočení z hlavního scénáře a možná jeho návrat)“ “
• Výjimky „tj. Události výjimek a jejich scénáře zpracování výjimek“

Neformální

Cockburn uznává, že projekty nemusí vždy vyžadovat podrobné „plně oblečené“ případy použití. Popisuje příležitostný případ použití s ​​poli:^[24]

• Název (cíl)
• Primární herec
• Rozsah
• Úroveň
• (Příběh): tělo případu použití je jednoduše odstavec nebo dva textu, neformálně popisující, co se stane.

Fowlerův styl

Martin Fowler uvádí „Neexistuje standardní způsob zápisu obsahu případu použití a různé formáty fungují dobře v různých případech.“^[23]:100 „Popisuje běžný styl“ následovně:^[23]:101

• Název: „cíl, který se případ použití snaží splnit“^[23]:101
• Hlavní scénář úspěchu: očíslovaný seznam kroků^[23]:101
  • Krok: „jednoduché prohlášení o interakci mezi aktérem a systémem“^[23]:101
• Rozšíření: samostatně očíslované seznamy, jeden na rozšíření^[23]:101
  • Rozšíření: „podmínka, která vede k různým interakcím od .. hlavního scénáře úspěchu“. Rozšíření z hlavního kroku 3 je očíslováno 3a atd.^[23]:101

Fowlerův styl lze také považovat za zjednodušenou variantu šablony Cockburn.

Herci

Případ použití definuje interakce mezi externími aktéry a uvažovaným systémem k dosažení cíle. Herci musí být schopni rozhodovat, ale nemusí to být člověk: „Aktérem může být osoba, společnost nebo organizace, počítačový program nebo počítačový systém - hardware, software nebo obojí.“^[27] Herci jsou vždy zúčastněné strany, ale ne všechny zúčastněné strany jsou aktéry, protože „nikdy nekomunikují přímo se systémem, přestože mají právo se starat o to, jak se systém chová“.^[27] Například „vlastníci systému, představenstvo společnosti a regulační orgány, jako jsou Internal Revenue Service a Department of Insurance“, mohou být všichni zúčastněnými stranami, ale je nepravděpodobné, že by byli aktéry.^[27]

Podobně může být osoba používající systém zastoupena jako různí aktéři, protože hraje různé role. Například uživatel „Joe“ může hrát roli zákazníka, když používá automatický bankomat k výběru hotovosti ze svého vlastního účtu, nebo hrát roli bankovního pokladníka, když používá systém k doplňování peněžní zásuvky jménem banka.

Herci často pracují jménem někoho jiného. Cockburn píše, že „V dnešní době píšu„ obchodní zástupce pro zákazníka “nebo„ referent pro marketingové oddělení “, abych zachytil, že uživatel systému jedná pro někoho jiného.“ Projektu to říká, že „uživatelské rozhraní a bezpečnostní prověrky“ by měly být navrženy pro obchodního zástupce a úředníka, ale že výsledky se týkají role zákazníka a marketingového oddělení.^[28]

Zainteresovaná strana může hrát aktivní i neaktivní roli: například Spotřebitel je „kupujícím na masovém trhu“ (neinteraguje se systémem) a Uživatelem (aktér, který aktivně interaguje se zakoupeným produktem).^[29] Uživatel je zase „běžným provozovatelem“ (aktér využívající systém k zamýšlenému účelu) a „funkčním příjemcem“ (účastník, který má prospěch z používání systému).^[29] Například když uživatel „Joe“ vybírá hotovost ze svého účtu, obsluhuje bankomat a získává výsledek svým vlastním jménem.

Cockburn radí hledat aktéry mezi zúčastněnými stranami systému, primárními a podpůrnými (sekundárními) aktéry případu použití, samotným systémem podle návrhu (SuD) a nakonec mezi „interními aktéry“, konkrétně složkami systému podle návrhu.^[27]

Obchodní případ použití

Stejným způsobem, že případ použití popisuje řadu událostí a interakcí mezi uživatelem (nebo jiným typem herce) a systémem, za účelem získání výsledku hodnoty (cíle) popisuje případ použití v podnikání obecnější interakci mezi obchodním systémem a uživateli / aktéry tohoto systému za účelem dosažení hodnotných obchodních výsledků. Hlavní rozdíl spočívá v tom, že systém uvažovaný v modelu případu obchodního použití může kromě technologických systémů obsahovat i lidi. Tito „lidé v systému“ se nazývají obchodní pracovníci. V příkladu restaurace je třeba rozhodnout, zda s každou osobou zacházet jako s hercem (tedy mimo systém) nebo s obchodním pracovníkem (uvnitř systému). Pokud je číšník považován za herce, jak je znázorněno v níže uvedeném příkladu, pak restaurační systém nezahrnuje číšníka a model odhaluje interakci mezi číšníkem a restaurací. Alternativou by bylo považovat číšníka za součást restauračního systému (obchodního pracovníka), přičemž by měl být klient mimo systém (herec).^[30]

Byznys Použijte případový diagram zobrazuje model několika obchodní případy použití (cíle), které představují interakce mezi restaurací (obchodním systémem) a jejími hlavními zúčastněnými stranami (obchodní subjekty a obchodní pracovníci).

Vizuální modelování

Případy použití nejsou jen texty, ale v případě potřeby také diagramy. V Unifikovaný Modelovací Jazyk, jsou zastoupeny vztahy mezi případy použití a aktéry použít případové diagramy původně založeno na Ivar Jacobson je Objektivní notace. SysML používá stejnou notaci na úrovni systémového bloku.

Kromě toho další behaviorální diagramy UML, jako je diagramy činnosti, sekvenční diagramy, komunikační diagramy a stavové automatové diagramy lze také použít k odpovídající vizualizaci případů použití. Konkrétně a Sekvenční diagram systému (SSD) je sekvenční diagram, který se často používá k zobrazení interakcí mezi externími aktéry a systémem ve fázi návrhu (SuD), obvykle pro vizualizaci konkrétního scénáře případu použití.

Analýza případů použití obvykle začíná nakreslením diagramů případů použití. Pro agilní vývoj je model požadavku mnoha diagramů UML zobrazujících případy použití plus některé textové popisy, poznámky nebo pouzdra na případy použití by bylo velmi lehké a dostačující pro malé nebo snadné použití projektu. Jako dobrý doplněk k použití textů případů jsou vizuální diagramové znázornění případů použití také účinnými pomocnými nástroji pro lepší pochopení, komunikaci a návrh komplexních požadavků na chování systému.

Příklady

Níže je ukázkový případ použití napsaný s mírně upravenou verzí šablony ve stylu Cockburn. Všimněte si, že v popisu základního případu použití nejsou žádná tlačítka, ovládací prvky, formuláře ani jiné prvky a operace uživatelského rozhraní, kde jsou v každém kroku základního toku nebo rozšíření vyjádřeny pouze cíle, dílčí cíle nebo záměry uživatelů. Tato praxe zpřesňuje specifikaci požadavků a maximalizuje flexibilitu návrhu a implementací.

Pouzdro: Upravit článek

Primární herec: Člen (Registrovaný Uživatel)

Rozsah: a Wiki Systém

Úroveň: ! (Uživatelský cíl nebo hladina moře)

Stručný: (ekvivalent k uživatelský příběh nebo epos)

Člen upravuje jakoukoli část (celý článek nebo jen jeho část) článku, který čte. Během úprav jsou povoleny náhledy a porovnání změn.

Zúčastněné strany

...

Postkondice

Minimální záruky:

Záruky úspěchu:

• Článek se uloží a zobrazí se aktualizované zobrazení.
• Systém vytvoří záznam o úpravě článku, takže pozorovatelé článku mohou být o aktualizaci informováni později.

Předpoklady:

Člen s povolenou úpravou se zobrazí členovi.

Spouštěče:

Člen vyvolá u článku žádost o úpravy (u celého článku nebo pouze u jedné sekce).

Základní tok:

1. Systém poskytuje novou oblast / rámeček editoru naplněný veškerým relevantním obsahem článku s informativní souhrnnou úpravou, kterou má člen upravit. Pokud chce člen pouze upravit část článku, zobrazí se pouze původní obsah sekce s automaticky vyplněným názvem sekce v souhrnu úprav.
2. Člen upravuje obsah článku, dokud není spokojen.
3. Člen vyplní souhrn úprav, řekne systému, zda chce sledovat tento článek, a odešle úpravu.
4. Systém uloží článek, zaznamená událost úpravy a dokončí veškeré nezbytné následné zpracování.
5. Systém předloží členovi aktualizovaný pohled na článek.

Rozšíření:

2–3.

A. Ukaž ukázku:

1. Člen vybere Ukaž ukázku který odešle upravený obsah.
2. Systém znovu spustí krok 1 s přidáním vykresleného aktualizovaného obsahu k náhledu a informuje člena, že jeho úpravy ještě nebyly uloženy, a poté pokračuje.

b. Zobrazit změny:

1. Člen vybere Zobrazit změny který odešle upravený obsah.
2. Systém znovu spustí krok 1 s přidáním zobrazení výsledků porovnání rozdílů mezi aktuálními úpravami člena a nejnovější uloženou verzí článku, poté pokračuje.

C. Zrušit úpravy:

1. Člen vybere zrušení.
2. Systém zahodí jakoukoli změnu, kterou člen provedl, poté přejde na krok 5.

4a. Časový limit:

...

Výhody

Od počátku agilního hnutí se uživatelský příběh technika od Extrémní programování je tak populární, že si mnozí myslí, že je to jediné a nejlepší řešení pro agilní požadavky všech projektů. Alistair Cockburn uvádí pět důvodů, proč stále píše případy použití agilní vývoj.^[31]

1. Seznam jmen gólů poskytuje nejkratší souhrn toho, co systém nabídne (dokonce než uživatelské příběhy ). Poskytuje také kostru plánování projektu, která se má použít k vytvoření počátečních priorit, odhadů, alokace týmu a načasování.
2. Hlavní scénář úspěchu každého případu použití poskytuje všem zúčastněným dohodu o tom, co systém v zásadě bude dělat a co ne. Poskytuje kontext pro každý konkrétní požadavek na řádkovou položku (např. Podrobně zpracované uživatelské příběhy), což je kontext, který je velmi obtížné získat nikde jinde.
3. Podmínky rozšíření každého případu použití poskytují rámec pro vyšetřování všech těch drobných věcí, které nějak zabírají 80% času a rozpočtu na vývoj. Poskytuje mechanismus výhledu, takže zúčastněné strany mohou odhalit problémy, u nichž je pravděpodobné, že bude trvat dlouho, než se jim podaří získat odpovědi. Tyto problémy mohou a měly by být posunuty před plánovaný čas, aby odpovědi mohly být připraveny, až se vývojový tým dostane k práci na nich.
4. Fragmenty scénáře rozšíření případu použití poskytují odpovědi na mnoho podrobných, často složitých a ignorovaných obchodních otázek: „Co máme v tomto případě dělat?“ Jedná se o rámec myšlení / dokumentace, který odpovídá příkazu if ... then ... else, který pomáhá programátorům přemýšlet o problémech. Kromě toho, že se to děje v době vyšetřování, nikoli v době programování.
5. Kompletní sada případů použití ukazuje, že vyšetřovatelé promysleli potřeby každého uživatele, každý cíl, který mají s ohledem na systém, a všechny zapojené obchodní varianty.

Stručně řečeno, určení systémových požadavků v případech použití má tyto zjevné výhody ve srovnání s tradičními nebo jinými přístupy:

Zaměřeno na uživatele

Případy použití představují výkonný nástroj zaměřený na uživatele pro proces specifikace požadavků na software.^[32] Modelování případů použití obvykle začíná identifikací klíčových rolí zúčastněných stran (herci) interakce se systémem a jejich cíli nebo cíli, které musí systém splňovat (vnější pohled). Tyto uživatelské cíle se poté stávají ideálními kandidáty na názvy nebo názvy případů použití, které představují požadované funkční funkce nebo služby poskytované systémem. Tento přístup zaměřený na uživatele zajišťuje, že se vyvine to, co má skutečnou obchodní hodnotu a uživatel opravdu chce, nikoli ty triviální funkce spekulované z pohledu vývojáře nebo systému (uvnitř).

Tvorba případů užití byla důležitým a cenným analytickým nástrojem v oblasti Návrh zaměřený na uživatele (UCD) po celá léta.

Lepší komunikace

Případy použití jsou často psány v přirozených jazycích se strukturovanými šablonami. Tato narativní textová forma (čitelné příběhy požadavků), srozumitelná téměř každému, doplněná vizuálními diagramy UML, podporuje lepší a hlubší komunikaci mezi všemi zúčastněnými stranami, včetně zákazníků, koncových uživatelů, vývojářů, testerů a manažerů. Lepší komunikace má za následek požadavky na kvalitu a tím i dodávané systémy kvality.

Požadavky na kvalitu strukturovaným průzkumem

Jedna z nejmocnějších věcí v případech použití spočívá ve formátech případu použití šablony, zejména hlavní scénář úspěchu (základní tok) a fragmenty scénáře rozšíření (rozšíření, výjimečné a / nebo alternativní toky). Analýza případu použití krok za krokem od předpokladů po postkondice, zkoumání a zkoumání všech kroků akce toků případů použití, od základních po rozšíření, k identifikaci těchto záludných, obvykle skrytých a ignorovaných, zdánlivě triviálních, ale realisticky často nákladných požadavků (jak zmínil Cockburn výše) je strukturovaný a prospěšný způsob, jak systematicky získat jasné, stabilní a kvalitní požadavky.

K lepšímu přispívá také minimalizace a optimalizace kroků akce případu použití k dosažení cíle uživatele návrh interakce a uživatelská zkušenost systému.

Usnadněte testování a uživatelskou dokumentaci

S obsahem založeným na struktuře toku akcí nebo událostí slouží model dobře napsaných případů použití jako vynikající základ a cenné vodítko pro návrh testovacích případů a uživatelských příruček systému nebo produktu, což je investice hodná úsilí. vpředu. Existuje zřejmé propojení mezi cestami toku případu použití a jeho testovacích případů. Odvození funkčních testovacích případů z případu použití prostřednictvím jeho scénářů (spuštěných instancí případu použití) je jednoduché.^[33]

Omezení

Omezení případů použití zahrnují:

• Případy použití nejsou vhodné k zachycení neinterakčních požadavků systému (například algoritmus nebo matematické požadavky) nebo nefunkční požadavky (jako je platforma, výkon, načasování nebo aspekty důležité z hlediska bezpečnosti). Ty jsou lépe deklarativně specifikovány jinde.
• Protože neexistují zcela standardní definice případů použití, musí si každý projekt vytvořit vlastní interpretaci.
• Někteří používají případové vztahy, například rozšiřuje, mají nejednoznačný výklad a pro zúčastněné strany může být obtížné je pochopit, jak na to upozornil Cockburn (problém č. 6)^{[34][Citace je zapotřebí ]}
• Pro vývojáře případů použití je často obtížné určit úroveň uživatelské rozhraní (UI) závislost na začlenění do případu použití. Zatímco teorie případů použití naznačuje, že se uživatelské rozhraní v případech použití neprojevuje, může být nepříjemné tento aspekt designu abstrahovat, protože ztěžuje vizualizaci případů použití. V softwarovém inženýrství je tento problém vyřešen aplikací sledovatelnost požadavků, například s a sledovatelnost matice. Dalším přístupem k přidružení prvků uživatelského rozhraní k případům použití je připojení návrhu uživatelského rozhraní ke každému kroku v případě použití. Tomu se říká scénář použití scénáře.
• Případy použití lze příliš zdůraznit. Bertrand Meyer pojednává o problémech, jako je návrh systému řízení příliš doslovně z případů použití a použití případů s vyloučením jiných technik analýzy potenciálně cenných požadavků.^[35]
• Případy použití jsou výchozím bodem pro návrh zkoušky,^[36] ale protože každý test vyžaduje svá vlastní kritéria úspěchu, může být nutné upravit případy použití, aby byly pro každou cestu poskytnuty samostatné post-podmínky.^[37]
• Ačkoli případy použití zahrnují cíle a kontexty, ať už jsou tyto cíle a motivace za cíli (obavy zúčastněných stran a jejich hodnocení včetně neinterakce) konflikty nebo negativně / pozitivně ovlivňují jiné cíle systému, jsou předmětem technik modelování požadavků zaměřených na cíle (jako např. BMM, Já *, KAOS a ArchiMate ZBROJ).

Mylné představy

Tato sekce potřebuje expanzi. Můžete pomoci přidávat k tomu. (Červenec 2015)

Běžná nedorozumění ohledně případů použití jsou:

Příběhy uživatelů jsou hbití; případy použití nejsou.

Agilní a Skrumáž jsou neutrální vůči technikám požadavků. Jako Scrum Primer^[38] státy,

Položky produktového backlogu jsou vyjádřeny jakýmkoli způsobem, který je jasný a udržitelný. Na rozdíl od běžného nedorozumění produktový backlog neobsahuje „uživatelské příběhy“; jednoduše obsahuje položky. Tyto položky lze vyjádřit jako uživatelské příběhy, případy použití nebo jakýkoli jiný přístup k požadavkům, který skupina považuje za užitečný. Ale ať už je tento přístup jakýkoli, většina položek by se měla zaměřit na poskytování hodnoty zákazníkům.

Techniky případu použití se vyvinuly tak, aby zohledňovaly agilní přístupy, a to pomocí řezů případů použití k postupnému obohacení případu použití.^[13]

Případy použití jsou hlavně diagramy.

Craig Larman zdůrazňuje, že „případy použití nejsou diagramy, jsou textové“.^[39]

Případy použití mají příliš mnoho obsahu souvisejícího s uživatelským rozhraním.

Jak někteří řekli,

Případy použití budou často obsahovat úroveň podrobností (tj. Pojmenování štítků a tlačítek), díky nimž se nebude dobře hodit pro úplné zachycení požadavků na nový systém.

Nováček nedorozumění. Každý krok dobře napsaného případu použití by měl být uveden herec cíle nebo záměry (podstata funkčních požadavků) a obvykle by neměl obsahovat žádné podrobnosti uživatelského rozhraní, např. pojmenování štítků a tlačítek, operace uživatelského rozhraní atd., což je a špatný praxe a zbytečně zkomplikuje psaní případu použití a omezí jeho implementaci.

Pokud jde o zachycení požadavků na nový systém od nuly, použít případové diagramy Plus pouzdra na případy použití se často používají jako užitečné a cenné nástroje, přinejmenším stejně lehké jako uživatelské příběhy.

Psaní případů použití pro velké systémy je zdlouhavé a ztráta času.

Jak někteří řekli,

Formát případu použití znesnadňuje popis velkého systému (např. Systému CRM) na méně než několika stovkách stránek. Je to časově náročné a zjistíte, že trávíte čas zbytečným přepracováváním.

Trávit hodně času psaním zdlouhavých případů použití, které nepřidávají žádnou nebo jen malou hodnotu a vedou ke spoustě přepracování, je zápach což naznačuje, že autoři nejsou dobře kvalifikovaní a mají málo znalostí o tom, jak psát případy kvalitního použití efektivně a efektivně. Případy použití by měly být psány iterativně, inkrementálně a evolučně (agilní) způsob. Použití šablon případů použití neznamená, že všechna pole šablony případů použití by měla být použita a vyplněna komplexně zepředu nebo během speciální vyhrazené fáze, tj. Fáze požadavku v tradiční vodopád model rozvoje.

Ve skutečnosti formáty případu použití formulované ty populární styly šablon, např. RUP a Cockburn's (také přijaty metoda OUM ) atd., se v praxi osvědčily jako cenné a užitečné nástroje pro zachycení, analýzu a dokumentaci složitých požadavků velkých systémů. Kvalita dokumentace případu dobrého použití (Modelka) by neměl být posuzován z velké části nebo pouze podle jeho velikosti. Je také možné, že kvalitní a komplexní model případu použití velkého systému se nakonec může vyvinout na stovky stránek, zejména kvůli inherentní složitosti problém v ruce, ne kvůli špatným psacím schopnostem jeho autorů.

Nástroje

Textové editory a / nebo textové procesory s podporou šablon se často používají k zápisu případů použití. Pro velké a složité systémové požadavky jsou užitečné vyhrazené nástroje pro případ použití.

Mezi známé nástroje pro případy použití patří:

• CaseComplete
• Enterprise Architect
• MagicDraw
• Rational Software 'RequisitePro - jeden z prvních známých nástrojů pro správu případů a požadavků v 90. letech.
• Software Ideas Modeler
• Wiki software - dobré nástroje pro týmy pro společné vytváření a správu případů použití.

Většina UML nástroje podporovat psaní textu i vizuální modelování případů použití.

Viz také

• Případ zneužití
• Obchodní případ
• Hranice entity-kontroly
• Rozdělení událostí
• Vlastnosti
• Seznam nástrojů UML
• Případ zneužití
• Požadavek
• Vyvolání požadavků
• Scénář
• Storyboard
• Modelový případ
• Použijte případové body

Reference

Další čtení

• Alexander, Ian a Beus-Dukic, Ljerka. Objevování požadavků: Jak specifikovat produkty a služby. Wiley, 2009.
• Alexander, Ian a Maiden, Neil. Scénáře, příběhy, případy použití. Wiley 2004.
• Armor, Frank a Granville Miller. Pokročilé modelování případů použití: Softwarové systémy. Addison-Wesley, 2000.
• Kurt Bittner, Ian Spence, Použijte modelování případů, Addison-Wesley Professional, 20. srpna 2002.
• Cockburn, Alistair. Psaní případů efektivního použití. Addison-Wesley, 2001.
• Larry Constantine, Lucy Lockwood, Software pro použití: Praktický průvodce základními modely a metodami designu zaměřeného na použití, Addison-Wesley, 1999.
• Denney, Richarde. Úspěch v případech použití: Inteligentní práce k zajištění kvality. Addison-Wesley, 2005.
• Fowler, Martin. UML destilovaný (třetí vydání). Addison-Wesley, 2004.
• Jacobson Ivar, Christerson M., Jonsson P., Övergaard G., Objektově orientované softwarové inženýrství - přístup založený na konkrétních případech použití, Addison-Wesley, 1992.
• Jacobson Ivar, Spence I., Bittner K. Use Case 2.0: The Guide to Succeeding with Use Cases, IJI SA, 2011.
• Dean Leffingwell, Don Widrig, Správa softwarových požadavků: Přístup k případu použití, Addison-Wesley Professional. 7. prosince 2012.
• Kulak, Daryl a Eamonn Guiney. Případy použití: požadavky v kontextu. Addison-Wesley, 2012.
• Meyer, Bertrand. Objektově orientovaná konstrukce softwaru. (2. vydání). Prentice Hall, 2000.
• Schneider, Geri a Winters, Jason P. Appling Use Cases 2nd Edition: A Practical Guide. Addison-Wesley, 2001.
• Wazlawick, Raul S. Objektově orientovaná analýza a návrh pro informační systémy: Modelování pomocí UML, OCL a IFML. Morgan Kaufmann, 2014.

externí odkazy

• Sloupec případů použití Alistair Cockburn
• Pouzdra na použití (Usability.gov)
• Šablona případu základního použití Alistair Cockburn
• Použití případů použití pro analýzu zúčastněných stran „Projekt Icarus: Scénáře zúčastněných stran pro mezihvězdný průzkumný program“, JBIS, 64, 224-233
• „Akademický průzkum týkající se role případů použití v UML“
• Vyhledejte případ použití v IBM developerWorks