Příklady diagramů případů užití
Dva diagramy případů užití systémů, které každý zná, plus jeden nakreslený záměrně špatně - chybu, která kazí většinu takových diagramů, je totiž snazší poznat než definovat.
8 min čteníUML 2.5.112 z 35
Krátká odpověď
- Dva aktéři, pět elips a jedna hranice tvoří úplný diagram. Knihovní systém v této velikosti pokryje include, extend i oba druhy aktérů.
- Přihlášení obvykle případ užití není. Nikdo neotvírá aplikaci proto, aby se přihlásil, takže cílem je to, kvůli čemu se přihlásil.
- Obyčejná čára mezi dvěma elipsami je nepřípustná. Asociace vedou jen od aktéra k případu užití; mezi případy je to include, extend nebo generalizace.
- Tři až tucet případů užití. Nad tucet jsou elipsy kroky místo cílů, nebo byla hranice nakreslena kolem dvou systémů.
01Příklad 1: knihovní systém#
Knihovna je standardním prvním příkladem z dobrého důvodu: doménu už každý zná, takže jediné, na co zbývá koukat, je notace. Dva aktéři, pět případů užití a hranice, která říká, za které z nich je software odpovědný.
Všimněte si, čím ty elipsy jsou. Půjčit knihu je cíl - člen chce odejít s knihou - a zůstává cílem, ať je za pultem člověk, samoobslužný kiosek nebo aplikace. Právě ta nezávislost na mechanismu je testem případu užití: pokud by výměna rozhraní změnila popisek, je ten popisek krokem.
Skutečnou práci dělají dva vztahy. Ověřit členství je zahrnuté případem Půjčit knihu, což znamená, že se vždy děje jako jeho součást, a šipka míří od vypůjčování k zahrnutému chování. Nemá vlastního aktéra a to je správně - nikdo nepřichází do knihovny s touhou, aby mu ověřili členství. Zaplatit pokutu za prodlení rozšiřuje Vrátit knihu: děje se jen někdy a šipka míří opačně, od volitelného chování do základního.
02Příklad 2: online obchod s externím systémem#
Druhý příklad přidává kus, který většina prvních diagramů vynechává: systém, na kterém závisíte a který neřídíte.
Payment gateway je sekundární aktér. Nic neiniciuje - všechno na tomhle diagramu začíná zákazník - ale systém se na něj obrací, takže patří mimo hranici s čárou do případu užití, který ho potřebuje. Právě jeho nakreslení je to, čím si diagram případů užití zaslouží místo v rozhovoru o rozsahu: hranice teď přesně ukazuje, které chování máte na starosti a které kupujete.
Uplatnit slevový kód rozšiřuje Zadat objednávku, protože většina objednávek žádný nemá. Kdyby ho měla téměř každá, bylo by to místo toho include. Otázkou není, jestli je chování důležité, ale jestli se děje vždy.
Čtyři elipsy jsou rozumná velikost. Skutečný obchod má stovky chování a diagram s tím neroste - kreslíte jeden na rozhovor, zúžený na otázku, která se právě klade, což je disciplína, o které je zúžení modelu.
03Příklad 3: tatáž notace použitá špatně#
Většina špatných diagramů případů užití je špatná přesně jedním způsobem a vyplatí se ho jednou vidět.
Čtyři elipsy, jeden aktér, hranice, vůbec žádné chyby v notaci - a diagram je bezcenný. Každý popisek je krokem v uživatelském rozhraní, ne cílem, který člověk má. Nikdo nechce zadat uživatelské jméno; chce se přihlásit, a i to je obvykle jen ve službách něčeho jiného.
Celý diagram se smrskne na jediný případ užití a ty čtyři kroky patří do jeho textového popisu, nebo - pokud na větvení opravdu záleží - do diagramu aktivit. To je standardní náprava: sled jde do aktivit, cíle zůstávají tady.
04Jak je přizpůsobit vašemu systému#
Ty dva dobré diagramy výše jsou tentýž diagram s jinými podstatnými jmény, a to je na téhle notaci to užitečné - jakmile máte tvar v ruce, další zabere deset minut.
Sáhněte po něm, když
- Cíle, které by uživatel pojmenoval, vyjádřené jako sloveso plus předmět: zadat objednávku, půjčit knihu.
- Hranice nakreslená kolem právě jednoho systému, s aktéry mimo ni.
- Sekundární aktéři pro každou externí službu, kterou systém volá, aby byly závislosti vidět.
- Include pro chování, které se děje vždy; extend pro chování, které se děje někdy.
Sáhněte po něčem jiném, když
- Kroky rozhraní - kliknout, zadat, vybrat, odeslat. Nejsou to cíle.
- CRUD rozstříkaný po diagramu: vytvořit, přečíst, upravit a smazat věc je jeden případ užití, ne čtyři.
- Obyčejné čáry mezi dvěma elipsami. Legální jsou tam jen include, extend a generalizace.
- Víc než zhruba tucet elips. Raději rozdělte podle aktéra nebo podsystému.
05Co si zapamatovat#
Po jednom řádku na každé
- 01Případ užití je cíl, který přežije redesign rozhraní. Pokud by se popisek změnil, je to krok.
- 02Include míří od základu k vždy zahrnutému chování; extend míří od volitelného chování zpět do základu.
- 03Zahrnuté případy užití nemají vlastního aktéra a to je správně.
- 04Sekundární aktéři jsou to, co dělá diagram užitečným v rozhovoru o rozsahu.
- 05Tři až tucet elips. Za tím se z diagramu stal seznam obrazovek.
06Časté dotazy#
Jaký je dobrý příklad diagramu případů užití?
Knihovní systém: člen hledá v katalogu, půjčuje si a vrací knihy; knihovník obsluhuje pultovou stranu týchž dvou; půjčení zahrnuje ověření členství; a zaplacení pokuty rozšiřuje vrácení. Dva aktéři, pět elips a jedna hranice tvoří úplný diagram.
Je přihlášení případ užití?
Obvykle ne samo o sobě. Nikdo neotvírá aplikaci proto, aby se přihlásil - přihlásí se, aby udělal něco jiného, a cílem je to něco jiného. Nakreslete jej jako zahrnutý případ užití tam, kde jej více cílů skutečně vyžaduje, jinak jej vynechte.
Kolik případů užití má mít jeden diagram?
Zhruba tři až tucet. Méně než tři a stačila by věta; více než tucet a elipsy jsou kroky místo cílů, nebo byla hranice systému nakreslena kolem dvou systémů.
Mohou být dva případy užití spojeny obyčejnou asociací?
Ne. Asociace vedou jen mezi aktérem a případem užití. Mezi dvěma případy užití jsou přípustné include, extend a generalizace; obyčejná čára mezi dvěma elipsami je známka, že někdo kreslí sled kroků místo množiny cílů.
Co je sekundární aktér v diagramu případů užití?
Externí strana, kterou systém volá, nikoli ta, která něco iniciuje: platební brána, poskytovatel identity, mailová služba. Kreslí se jako aktér na opačné straně hranice a je to ta část diagramu, která ukazuje, na čem závisíte, ale co neřídíte.
V této sérii
- 01Co je UML?
- 02Symboly UML
- 03Výběr diagramu
- 04Diagramy tříd
- 05Příklady diagramů tříd
- 06Jak nakreslit diagram tříd
- 07Symboly diagramu tříd
- 08Sekvenční diagramy
- 09Příklady sekvenčních diagramů
- 10Jak nakreslit sekvenční diagram
- 11Diagramy případů užití
- 12Příklady případů užití
- 13Diagramy aktivit
- 14Příklady aktivit
- 15Stavové diagramy
- 16Příklady stavových diagramů
- 17Diagramy komponent
- 18Příklady komponent
- 19Kreslení diagramu komponent
- 20Symboly komponent
- 21Diagramy nasazení
- 22Příklady nasazení
- 23Diagramy objektů
- 24Diagramy balíků
- 25Diagramy složené struktury
- 26Komunikační diagramy
- 27Sekvenční vs komunikační
- 28Časové diagramy
- 29Diagramy přehledu interakcí
- 30Diagramy profilů
- 31UML pomocí AI
- 32Příklad e-shopu
- 33Příklad banky
- 34Příklad mikroslužeb
- 35Příklad AWS
Související články
Diagramy chování
Základy
Diagramy chování
Praxe modelování
Diagramy chování
Diagramy chování