Use Cases

From Suhrid.net Wiki
Revision as of 04:39, 15 November 2011 by Suhridk (talk | contribs) (→‎Scenario)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Intro

  • A use case is a typical interaction that a user has with the system in order to achieve a goal.
  • A use case does two things:
  1. Describe how an actor achieves a goal using the system. This is described in terms of scenarios.
  2. Ensures interests of stakeholder are protected by the system.
  • Use cases drive the whole development process.
  • Use cases provide the basis of communication between the customers and developers in planning a project.
    • e.g. deciding which use cases to include in the current release.
  • Use cases can be used to capture the systems functional requirements.

Actor

  • An actor is someone or something external to the system and who interacts with the system.

Scenario

  • A scenario is a description of a sequence of actions that is a way of achieving a goal.
  • The main success scenario is the usual/main/straightforward way of achieving the goal.
  • All scenarios have (Note: UML does not specify any standard, this is the York recommendation)
    • A precondition : required condition before starting.
    • Interaction steps
    • Postcondition :
      • Guaranteed state of world once use case exits. successful precondition holds for successful exit.
    • A minimal postcondition: Something that guarantees to protect stakeholder interests.
  • For each step of main success scenario, think of:
  • Secondary Scenarios:
    • Alternative Scenario: A different way of achieving success (the goal)
    • Exception Scenario: Something that can go wrong - and can lead to a different postcondition.
  • The scenarios must be kept free of design assumptions.
  • A use case is therefore is a set of scenarios tied together by a common user goal.
  • ... and each scenario defines one way the goal is or is not achieved.

Structuring Use Cases

Inclusion

  • A step in the scenario of a use case that is detailed - and might be another use case by itself.
  • The main use case "calls" the inclusion use case.
  • For e.g. use case for "Edit Document" - might have a step called "Modifies Text" which might be a use case by itself.

Generalization

  • Use when one use case is similar to another use case, but does a little bit more.
  • For e.g. "Draw Square" can be a specialized use case of "Draw Rectangle".

Extension

  • Sort of an interruption to to the Main use case.
  • For e.g. if the main use case is "Check Balance" and if the balance > 5000$, the "Enrol as privilege customer" use case can kick in.
  • The point at which the extension use case kicks in is the extension point. The extension points have to be declared in the base use case.
  • Note that the main use case has no control over the special use case.

Use Case Diagrams

  • Is a summary of the functionality of the whole system.
  • Gives an overview of the relationships between all the actors and all the use cases.
  • Not meant to record details of use cases - for that text is best, but rather as a sort of visual guide to the various use cases in the system.