How I may help
LinkedIn Profile Email me!
Call me using Skype client on your machine

Reload this page Use Cases

This page, part of a series on UML, describes what Use Cases are and how to use them to develop and test applications.


Topics this page:

  • Use Case Diagrams
  • Activities
  • Diagrams
  • Relationships
  • Extends
  • Includes
  • Boundaries
  • Use Case Prose
  • Use Case Attributes
  • Use Case Rankings
  • Your comments???

    Site Map List all pages on this site 
    About this site About this site 
    Go to first topic Go to Bottom of this page

    Align at top of frame  
    use case diagram objects
    Use cases define the context of a system. Use cases identify the intent satisfying the role assumed by external “actors" interacting with the “system under discussion/test”. A primary actor is one having a goal requiring the assistance of the system. A secondary actor is one from which the system needs assistance to satisfy a goal.

    Use cases are useful for several reasons throughout the development life cycle:

    • In the planning stage, the process of defining important use cases helps to clarify the most important goals of the system. Use cases helps to narrow the scope of the project. They can surface often unspoken assumptions about the desired behavior of the system.

      A website external to this site Roles add a level of abstraction to object-based constructs. A role is an instance of an encapsulated set of properties and behavior, but is described and used in a way that is totally independent of the object(s) that may implement it.

      This definition is just a technical narrowing of the most common everyday sense of the word role. For example, we can talk about the role of Hamlet in a particular performance, without reference to the actor(s) playing this role. The decision about who actually plays this role on stage is a separate “casting” decision. Normally we'd like to pick the single actor providing the highest “quality of service”. But we would also like the freedom to swap in a designated “second” if the original actor gets sick, or perhaps even to use two children, one on the other's shoulders and together dressed to look like a single adult actor.

    • In the execution stage, use cases provide developers key parts of the specification. Some systems are built entirely with only use case descriptions from sponsors.

    Use cases can be presented graphically in a diagram or in prose form, somewhat structured and highly structured.

    Align at top of frame Types of Use Case Activities

    Activities performed in a use case may be categorized this way:

    • Activites that Assign Responsibility, determine appropriate resources. For example, in a project management system, a person is designated to a defined project task.
    • Activites that define New Objects, as in a new object aggregate.
    • Activites that define New Processes, such as an assembly of existing activities.

    Align at top of frame Use Case Diagrams

    Use case diagrams are external view of a system's interactions with the outside world. Therefore, the system under discussion is illustrated as a single entity. Each line represents a channel of dialog between the actor and the system. The oval use case icon encapsulates how the system achieves its goal -- structuring mechanism for interaction diagrams. The actual software is often structured in a completely different way.

    sample use case

    Align at top of frame Relationships

    Lines in a use case represent more than a transfer of data or command, as in traditional flow chart and UML Activity Diagrams.
    Lines in a UML use case between an actor and the system represent a more abstract concept of relationship of communication, acquaintance, or inheritance.

    A use case circle can be more than a user invoking an on-demand service that passively waits until called upon.

    A Use case circle can be event-driven, which proactively notifies one or more subscribers when specific events occur.

    Services that run on their own without formal invocation may be better represented as an (automated) actor rather than as a use case circle.

    Align at top of frame Uses

    The relationship lines labled with the <<uses>> stereotype illustrates how two use cases are combined.

    Align at top of frame Extends

    The relationship line labled <<extends>> illustrates a special case: conditional (optional) or exception behavior.

    A sample of a generalization relation is of a business use case "Withdraw Cash". Examples of use cases Subordinate to it would be:

      "Withdraw Cash from Teller" or
      "Withdraw cash from ATM Machine".

    Another sample of a generalization relation is of when different technologies are used to achieve the same ends:

      "Register using phone" or
      "Register using website".

    To identify extensions in your application, look through boundary values and states in your data, where a user may, while performing a business use case, optionally:

    • obtain approval from higher-level management;
    • request more or less detail; (switching between a list instead of a form, obtain a more detailed report or analysis, map, etc.); requst a reformatted view (alternative sort, another view, etc.);
    • reach limits (such as the credit limit or the spending example above);
    • trigger low balance alerts and trigger automatic transfers (such as with stored valued toll accounts);
    • trigger ratios dynamically calculated reach a specified threshold, trades are placed automatically.

    Align at top of frame Includes

    The relationship line labled with the <<includes>> streotype illustrates where a business use case is a part of the aggravation of many larger business processes. ;) Whoops. I mean the aggregation of a more comprehensive use case. This is why the relationship arrow point into the aggregate (higher level) use case.

    • "View Cart" includes to a part of "Choose shipping and payment methods".

    Align at top of frame Boundaries

    sample use case A box defines the boundaries of related use cases. Lines from a box point to lower-level entities -- subdivision -- subgoals.

    This sample use case diagram is from the Professional version of Microsoft Visio 2002 software. It's called a “Jacobson use case model” because use cases were popularized by Ivar Jacobson, one of the gurus who joined Rational corporation and defined the Unified Modeling Language (UML). This sample is within the “software” category because it is a widely accepted documentation protocol for Object Oriented design and programming.

    A “scenario” results from sequencing interactions. A use case defines a collection of possible scenarios. A use case is a collection of scenarios, each with a different triggering event. The main course is the simplest scenario, the one in which everything goes right and goal is achieved without difficulty — all the subordinate use cases succeed. Alternative courses (and there can be any number of them) describe deviations from that basic course.

    Use cases are one aspect of a complete design, described in this graphic from a pdf file named “Structure and Style in Use Cases for User Interface Design” at Larry Constantine's websiteA website external to this site:

    Go to Top of this page.
    Previous topic this page
    Align at top of frame

      Use cases should not assume or specify a particular user interface object, such as “push the start button” or “press the screen”.


    Use Case Prose

    There is no industry standard to describe use cases using sentences, but here is a typical example:
    • System under discussion: the insurance company
    • Primary Actor: me, the claimant
    • Goal: I get paid for my car accident
    • Conditions: Everything is in order
    • Outcome: Insurance company pays claim
    • Scenario:

      1. Claimant submits claim with substantiating data.

      2. Insurance company verifies claimant owns a valid policy (failure here probably means goal failure)

      3. Insurance company assigns agent to examine case.

      4. Agent verifies all details are within policy guidelines. (an interaction between the agent and secondary actors)

      5. Insurance company pays claimant (implies all preceding goals managed to pass)

    More Structured Use Case Prose

    Alistair Cockburn suggests a general form of prose using a event/response pair :

      <time or sequence factor> <actor> <action> <constraints>

      Convert to active voice the verbs listed in Sample Action Verbsanother page on this site

    Thus, typical sentences might look like:

      At any time after the clerk gets the quote, he may cancel the sale.

    Structured Use Case Prose

    Various authors have proposed methods to better structure use case writeups.

    webpage article Alistair Cockburn's template provides space for information that is filled out over several passes during the life of the project. An example is descriptions for failed Extensions to the use case.

    Go to Top of this page.
    Previous topic this page

    Align at top of frame Use Case Attributes

    Align at top of frame Use Case Rankings

    • by business process volumetrics

      • Transaction mix
      • Average Sustained Rate which the use case is executed (per day/week/month/quarter/year).
      • Peak Rate (per day / week / month / year) when maximum throughput will occur.
      • Allowed completion Time (seconds/minutes/hours) SLA
      • Bytes being moved through the scenario.
    • by business impact (critical, important, etc.)
    • by perceived complexity (high, medium, low, etc.)

    Go to Top of this page.
    Previous topic this page
    Next topic this page

    Portions ©Copyright 1996-2010 Wilson Mar. All rights reserved. | Privacy Policy |

    How I may help

    Send a message with your email client program

    Last updated

    Your rating of this page:
    Low High

    Your first name:

    Your family name:

    Your location (city, country):

    Your Email address: 

      Top of Page Go to top of page

    Thank you!