Object-Oriented Analysis and Design

Evolutionary Requirements

UP Requirements Artifacts

Use Case Model – typical scenarios of functional requirements

Supplementary Specifications – primarily non-functional requirements

Glossary – noteworthy terms including a Data Dictionary (a recording of data requirements)

Vision – high-level requirements and business case summary

Business Rules – (aka Domain Rules) requirements or policies which apply to many projects required by business or domain (e.g. tax laws)

Object-Oriented Analysis and Design

Use Cases

Read chapter 6

Define the Problem

The most critical question: “Is this the right system to make?”

Use Case Relationships

Domain Model

Use Case Model

Interaction DiagramsDesign

Requirements

Business Model

Objects, attributes, associations

VISION

GLOSSARY

SUPPLEMENTARYSPECIFICATION

Use Cases are not Diagrams Use Cases have a diagram associated with them

easy way for analyst to discuss a process with a domain expert

Use cases are primarily text text = important; diagram = optional

Why Use Cases?

Simple and familiar storytelling makes it easier, especially for customers, to contribute and review goals.

They keep it simple They emphasize goals and the user

perspective Focus on the essence/intent of requirements Avoid bias of reproducing the existing system

Identify Use Cases Capture specific ways of using the system as

dialogue between an actor and the system. Use cases are used to:

Capture functional system requirements Communicate with end users and Domain

Experts Test the system

Specifying Use Cases Create a written document for each Use Case

Clearly define intent of the Use Case Define Main Success Scenario (Happy Path) Define any alternate action paths Use format of Stimulus: Response Each specification must be testable Write from actor’s perspective, in actor’s

vocabulary

Use Case Template Items

Use Case Name Scope (the system under design) Level ("user-goal" or "subfunction") Primary Actor (calls on system to deliver its function) Stakeholders and Interests (Who cares? What do they

want?) Preconditions (what must be true at use case start) Success Guarantee (aka Posconditions; what must be

true on successful use case completion) Main Success Scenario (happy path/sunny day) Extensions (alternative scenarios) Special Requirements (non-functional requirements)

Suggested Other Use Case Items

Technology and Data Variations (I/O methods and data formats)

Frequency of Occurrence (of use case) Miscellaneous (e.g. open issues) See Use Case UC1: Process Sale p. 68

Naming Use Cases A complete process from end user viewpoint Usually in verb-object form, (e.g. Register for

Classes) Use enough detail to make it specific Use active voice, not passive From viewpoint of the actor, not the system

Use Case Name Examples Excellent - Purchase Concert Ticket Very Good - Purchase Concert Tickets Good - Purchase Ticket (insufficient detail) Fair - Ticket Purchase (passive) Poor - Ticket Order (system view, not user) Unacceptable - Pay for Ticket (procedure, not

process)

Singular or Plural?

Usually determined by context. Preference for the simplest form, but most

common form can be better. In the example of concert tickets, most people

buy more than one, but a significant number buy only one.

At a supermarket, Buy Items would be best. At a vending machine, it would be Buy Item.

Identify Actors Part of understanding a system is knowing

who uses it Direct users Users responsible to operate and maintain it External systems used by the system External systems that interact with the system

Specifying Actors External to the system Non-deterministic May be different roles for one individual user May be other external systems

Identifying Actors Primary Actor

Emphasis is on the primary actor for the use case – has goals to be fulfilled

Stakeholders and Interests Other actors are listed as stakeholders. The interests of each key actor should

be described.

Working with Use Cases Determine the actors that will interact with the

system Examine the actors and document their needs For each separate need, create a use case During Analysis, extend use cases with

interaction diagrams

Preconditions

Anything that must always be true before beginning a scenario is a precondition.

Assumed to be true, not tested within the Use Case

Ignore obvious preconditions (e.g. power is on)

Success Guarantees (Postconditions)

States what must be true if the Use Case is completed successfully

May include the main success scenario and some alternative paths

Stakeholders should agree on the guarantee.

Scenarios Main Success Scenario, or “happy path” is

expected primary use of the system, without problems or exceptions.

Alternative Scenarios or Extensions are used to document other common paths through the system and error handling or exceptions.

Happy Path / Sunny Day Scenario Success Scenario (or basic course) gives the best

understanding of the use case Each step contains the activities and inputs of the

actor and the system response Two column template works well for this

If three or more items, create a list Label steps for configuration management and

requirements traceability Use present tense and active voice

Extensions (Alternative Flows) Extensions or Alternative Flow Use Cases

allow the specification of Different ways of handling transactions Error processes

Sections are convenient way to handle alternative courses of action Sections are a segment of a use case

executed out of sequence

Essential versus Real Use Cases Essential (black box) use case leaves out

technology and focuses only on functionality Real (white box) use case includes technology is

fundamental. E.g., essential Withdraw Cash from ATM use

case can mention identification or validation Only real Withdraw Cash from ATM use case

can mention a key pad or card reader

Extension Use Cases Users appreciate simplicity, so most use

cases leave out alternate courses Do this by extending the use case (see Use

Case Diagramming section below) while leaving the original use case alone

Use-case driven development Requirements are primarily recorded in the

Use Case model. Iterations are planned around implementing

particular Use Cases. Use Case Realizations drive design. Use Case often influence the way user

manuals are organized.

Diagramming Use Cases

read Chapter 30

Object-Oriented Analysis and Design

Actor

An actor is an idealized user of a system

Actors can be users, processes, and other systems

Many users can be one actor, in a common role

One user can be different actors, if in different roles

An actor is labeled in singular with the name of the role

Non-human Actor Actors can be users,

processes, and other systems.

Non human actors typically shown as rectangle rather than stick figure

Usually not primary users, and thus are usually shown on the right

Inventory

System

Use Case Is a coherent unit of externally

visible functionality provided by a system and expressed by a sequence of messages

Additional behavior can be shown with generalize, extend, and include use case relationships

Labeled with the use case name

System

A system is shown as a rectangle, labeled with the system name

Actors are outside the system

Use cases are inside the system

The rectangle shows the scope or boundary of the system

Don’t forget the boundary and the system name, unless you are using Rational Rose!

Association Relationship

An association is the communication path between an actor and the use case that it participates in

It is shown as a solid line It does not have an arrow, and is

normally read from left to right Here, the association is between a

Modeler and the Create Model use case

Include Relationship

Include relationships insert additional behavior into a base use case

They are shown as a dotted line with an open arrow and the key word <<include>>

Shown is a process that I observed in an earlier career

Extend Relationship

Extend puts additional, optional behavior in a use case that does not know about it.

It is shown as a dotted line with an arrow point and labeled <<extend>>

In this case, a customer can request a catalog when placing an order

Generalize Relationship

Is a relationship between a general use case and a more specific use case that inherits and extends its features

It is shown as a solid line with a closed arrow point

Here, the payment process is modified for cash and charge cards

Use Case Example: Alarm Clock

This is a contrivedexample, to showmany relations.Your diagrams

should be simpler.