UML - Use-case Diagram

[jimin-kiim]

• Use case
• Use-case Diagram
  • system, actor, usecases
  • relatonships
  • association
  • generalization
  • extend
  • include

[jimin-kiim]

Use Cases

• a mechanisms to capture requirements, primarily functional(behavioral) requirements
  • it can reduce the importance or use of detailed old-style feature list
• text stories of some actor using a system to meet goals
• a collection of related success and failure scenarios, which describe an actor using the system to achieve a goal.
• a simple way of capturing user goals helping keep it simple and make it possible for domain experts or requirement donors to themselves write
• emphasize the user goals and perspective instead of asking for a list of system features

Actor

• a role played by a user or any other system that interacts with the system to develop
• Primary Actor
  • initiator of the use case (use cases exist to satisfy the primary actor)
  • has user goals fulfilled through using services of the SuD(System under Discussion)
  • e.g., cashier
• Supporting Actor
  • provides a service to the system
  • clarify external interfaces and protocols
  • e.g., payment authorization service
• Offstage Actor
  • has an interest in the behavior of the use case, but not a primary or supporting
  • all necessary interests should be identified and satisfied
  • offstage actor interests are sometimes subtle or easy to miss unless these actors are explicitly named
  • e.g., government tax agency

Format

• scenario(a use case instance) : a specific sequence of actions and interactions between actors and the system.
  • Main Success Scenario(basic flow)
  • Alternate Scenario(extension)
• style
  • brief
  • one terse paragraph summary
  • usually the main success scenario or happy path
  • casual
  • multiple informal paragraph format.
  • cover various scenarios
  • fully dressed
  • includes all steps, variations and supporting sections
  • scope, level, primary goal, stakeholders and interests, precondition, postconditions(success guarantee), main success scenario, alternate scenario,

Section

• scope
  • bounds the system under design.
  • system use case: describes the use of one software system
  • business use case: enterprise-level process description
• level
  • user-goal level: a common kind that describes the scenarios to fulfill the goals of primary actor
  • subfunction level: substeps required to support a user goal. e.g., Pay by Credit
• primary actor
  • the principal actor that calls upon system services to fulfuill a goal
• stakeholders and interest list
  • suggests and bounds what the system do
  • are the answers to the question "what should be in the use cases"
• precondition and postcondition
  • precondition
    • state what must always true before a scenario is begun
    • imply completion of another scenario ( e.g., login)
    • don't need to mention if so obvious (e.g., system powered)
    • if it isn't met, the use case doesn't initiate
  • postcondition(success guarantee)
  • state what must be true on successful completion of the use case
  • if it isn't met, we can know that the use case ran correctly.
  • but even though it's met, we cannot ensure that the use case ran correctly.
• basic flow( main success scenario, happy path scenario)
  • describe the typical success path that satisfies the interests of the stakeholders
  • often doesn't include any conditions or branching
  • includes
  • an interaction between actors
  • a validation
  • a state change by the system
• extensions( alternate flows)
  • branches from the main success scenarios
  • at the end of the extension handling, by default the scenario merges back with the main success scenario, unless the extension indicates otherwise.
  • complicated extension points are usually expressed as separate use cases

Guideline

• "write in an essential UI-Free style"
  • expressing user intentions and system responsibilites
• "write terse use cases"
• "write black-box use cases"
• "take an actor and actor goal perspective"

How to find use cases

1. choose the system boundary
2. identify the primary actors and the goals for each primary actor
   • write an actor- goal list first, review and refine it, and then draw the use case diagram
3. define use cases that satisfy user goals

Tests for more useful use cases

• Boss Test
  • a use case should have some real measurable value; something that would make the boss happy
• EBP(Elementary Business Process) Test
  • EBP: a task performed by one person in one place at a time, in response to a business event, which adds measurable business value and leaves the data in a consistent state
  • a use case is not a single step action rather the main success scenario would be 5 or 10 steps
  • a use case doesn't require days to complete or multiple sessions
• Size Test
  • a use case should contain many steps

Applying UML

• use case: text document
• use case diagram and use case relationship are secondary in use case work
  • a common sign of a novice use case modeler is a preoccupation with use case diagrams and use case relationships, rather than writing text.
• use case diagram illustrates the name of use cases and actors and the relationships between them.
• a simple use case diagram can provide a succinct visual context diagram for the system
  • keep use case diagrams short and simple
  • an excellent picture of the system context
  • shows boundary of a system
  • summarizes the behavior of a system and its actors

[jimin-kiim]

Use case Diagram

Use Case

• describes functionality expected from the system under development
• provides tangible benefit for one or more actors that communicate with use case
• derived from collected customer wishes

Actor

• is not a part of the system, outside of the system boundaries
• represents roles that users adopt
  • Specific users can adopt and set aside multiple roles simultaneously.
• interact with the system by both using use cases and being used by use cases.
  • the actors initiate the execution of use cases and the actors provide functionality for the execution of use cases.
• human, non-human

Relationships between use cases and actors

• actors are connected with use cases via solid lines(associations)
• every actor must be associated with at least one use case
• every use case must be connected with at least one actor
• multiplicities may be specified

include relationship

• when cases share behavior we can factor this out into a separate inclusion use case and <> it in base use cases
• the behavior of one use case(included) is integrated in the behavior of another use case(base)
• the base use case executes until the point of inclusion
• control passes to the inclusion use case that executes
• when the inclusion use case is finished, control passes back to the base use case which finishes execution
• base use case:
  • requires the behavior of the included use case.
  • base use cases are not complete without the included use cases.
  • treats 'included use case' as a subroutine because it's re-usable in many places
• included use case:
  • may be executed on its own.
  • may be complete use cases or they may just specify a fragment of behaviour for inclusion elsewhere

extend relationship

• the behavior of one use case(extending use case) is integrated in the behavior of another use case(base use case) but doesn't have to.
• the extension use case inserts behavior into the base use case. The base use case provides extension points, but doesn't know about the extensions
• extension points define at which point the behavior is integrated.
• conditions define under which circumstances the behavior is integrated.
  • extending use case does not necessarily execute, execute only when the condition is met
• base use case:
  • treats 'included use case' as a subroutine

generalization relationship

Generalization of Use cases

• use case A(base use case) generalizes use case B(sub use case) == B inherits the behavior of A and may either extend or overwrite it.
• B also inherits all relationships from A.
• B adopts the basic functionality of A but decides itself what part of A is executed or changed
• if A cannot be executed directly and only B is executable, A may be labeled {abstract}

  Generalization of Actors

• Actor A(sub-actor) inherits from actor B(super actor)
• A can communicate with X and Y
• B can only communicate with Y
• Multiple inheritance is permitted
• abstract actors are possible.

Typical Errors to Avoid

• use case diagrams do not model process/ workflows
  • ordering relation should be expressed in activity diagrams not the use case diagram
• actors are not the part of the system, hence, they are positioned outside the system boundaries
• either or => use abstract actor
• many small use cases that have the same objective may be grouped to form one use case
• when the various steps are part of the use cases, not separate use cases themselves. no functional decomposition