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
01Example 1: a library system
The library is the standard first example for a reason: everybody already knows the domain, so the only thing left to look at is the notation. Two actors, five use cases, and a boundary that says which of them the software is responsible for.
Notice what the ellipses are. Borrow book is a goal - a member wants to leave with a book - and it stays a goal whether the counter is a person, a self-service kiosk or an app. That independence from mechanism is the test for a use case: if replacing the interface would change the label, the label is a step.
Two relationships are doing real work. Check membership is included by Borrow book, meaning it always happens as part of it and the arrow points from the borrower to the included behaviour. It has no actor of its own, and that is correct - nobody arrives at the library wanting their membership checked. Pay overdue fine extends Return book: it happens only sometimes, and the arrow points the other way, from the optional behaviour into the base.
02Example 2: an online store, with an external system
The second example adds the piece most first diagrams leave out: a system you depend on and do not control.
The Payment gateway is a secondary actor. It initiates nothing - the customer starts everything on this diagram - but the system calls out to it, so it belongs outside the boundary with a line into the use case that needs it. Drawing it is how a use case diagram earns its keep in a scoping conversation: the boundary now shows exactly which behaviour you are on the hook for and which you are buying.
Apply discount code extends Place order because most orders do not have one. If nearly every order did, it would be an include instead. The question is not whether the behaviour is important, it is whether it always happens.
Four ellipses is a reasonable size. A real store has hundreds of behaviours, and the diagram does not grow to match - you draw one per conversation, scoped to the question being asked, which is the discipline scoping a model is about.
03Example 3: the same notation used badly
Most bad use case diagrams are bad in exactly one way, and it is worth seeing once.
Four ellipses, one actor, a boundary, no notation errors at all - and the diagram is worthless. Every label is a step in a user interface rather than a goal a person has. Nobody wants to enter a username; they want to log in, and even that is usually only in service of something else.
The whole diagram collapses to a single use case, and the four steps belong in its text description or, if the branching genuinely matters, in an activity diagram. That is the standard repair: sequence goes to activity, goals stay here.
04Adapting these to your system
The two good diagrams above are the same diagram with different nouns, which is the useful thing about the notation - once the shape is in your hand, the next one takes ten minutes.
Reach for it when
- Goals a user would name, phrased as verb plus object: place order, borrow book.
- A boundary drawn around exactly one system, with actors outside it.
- Secondary actors for every external service the system calls, so dependencies are visible.
- Include for behaviour that always happens; extend for behaviour that sometimes does.
Reach for something else when
- Interface steps - click, enter, select, submit. They are not goals.
- CRUD sprayed across the diagram: create, read, update and delete a thing is one use case, not four.
- Plain lines between two ellipses. Only include, extend and generalization are legal there.
- More than about a dozen ellipses. Split by actor or by subsystem instead.
05What to remember
In one line each
- 01A use case is a goal that survives an interface redesign. If the label would change, it is a step.
- 02Include points from the base to the always-included behaviour; extend points from the optional behaviour back to the base.
- 03Included use cases have no actor of their own, and that is correct.
- 04Secondary actors are what makes the diagram useful in a scoping conversation.
- 05Three to a dozen ellipses. Past that, the diagram has become a list of screens.
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.
Související články