CONCEPTUAL DESIGN:

PURPOSE, ACTORS, FEATURES, AND UML USE

CASES
155

Information Systems Purpose

The overriding purpose of any information system is to support the mission of the enterprise Every information system has a [specific] purpose or mission No matter how trivial the purpose may seem, do not skip documenting it

156

Information System Purpose Examples

A Convenience Store: The purpose of the information system is "To help each cashier work more effectively during checkout, to keep good records of each sale, and to support more efficient store operations." A Warehouse: The purpose of the information system is "To improve warehouse profitability by helping team members put away and pick items more efficientlyby keeping more accurate inventory counts, and by increasing fill rate."

157

Information Systems Purpose Guidelines

Purpose Statements should be:

Kept short 25 words or less if possible Proactive in form Supportive the mission of the enterprise

Broad in scope, yet specific to the problem

Void of technology jargon

158

Actors
Actor definitions:
An abstraction for entities outside a system, subsystem, or class that interact directly with the system. An actor participates in a use case or coherent set of use cases to accomplish an overall purpose. [UML] A coherent set of roles that users of use cases play when interacting with the use cases. [Booch, Rumbaugh and Jacobson] Roles people or other information systems play when interacting through a use case with this information system. [Norman]
159

Actors

Actors are not part of the systemthey represent anyone or anything [another system] that must interact with the system Actors input to and/or receive output from the information system Actors are often identified via conversations with subject domain [matter] experts
160

Actor Examples
Mary Tom Jack Dino

Customer Student

Employee
Faculty

Member
Credit Card Validation System
161

Features

A prominent or significant functional, behavioral or descriptive part of an information system

Broad in scope; apply to whole system Narrow in scope; apply to one part of the system

An end-to-end (start-to-finish) significant process of the information system Synonymous with the UMLs Use Case Granularity is arbitrary
162

Feature Examples
(note the start-to-finish characteristic)

Course Registration or
Add a course Drop a course Check seat availability

Membership Maintenance or
Add a members information Change a members information Delete a membership Print/Display membership information
163

page 1 of 3

Types of Information System Features

A feature is a tangible, measurable, desired outcome that an information system could produce.

Log Information
(needed information) Business Problem Reference Data (Master, Foundational data)

Conduct Business
Business Problem Transaction Data

Analyze results
Business Problem Results

Interact with other systems

Business Problem Integration
164

page 2 of 3

Features Examples
Log

Information:
Maintain membership information Maintain product information Maintain vendor (supplier) information Maintain employee security information etc

Conduct

Business:

Rental transaction Sales transaction Order products transaction etc...

165

(Maintain = adding, changing, deleting, & viewing)

page 3 of 3

Features Examples
Analyze

results:

Produce Periodic Sales Report s by: Product Employee Fastest-moving rentals Fastest-moving sales Produce On-Order Report sorted by Vendor Produce On-Order Report sorted by Product etc
Interact

with other systems:

166

Validation of Credit Cards etc...

Documenting Actors and Features

Actor #1
Feature #1 Feature #2 Feature #3

Actor #3
Feature #1 Feature #2 Feature #3

Actor #2
Feature #1 Feature #2 Feature #3

Actor #4
Feature #1 Feature #2 Feature #3

167

Use Case Diagram Example #1

168

Use Case Diagram Example #2

169

Use cases and Use-Case Diagrams

A use case is a description of a specific usage of the system Use cases define the functionality requirements (features) of
the system

A use case usually represents a user-recognizable end-toend process rather than an individual step or activity within a process (e.g., rent a video instead of pay for video rental)

A use-case diagram shows any number of external actors and

their connection to the use cases that the system provides

A use-case diagram generally includes a number of use cases Use cases are often identified by: identifying actors who input to or receive something from
the system

external events that the system must respond to (e.g.,

purchase an airline ticket, check-out a video)
170

Components of the Use Case

Actor (stick figure) a role that a user (e.g., people, other systems, and objects) plays with respect to the system Use case (oval) Valuation significant end-to-end process Stereotypes (<< >>) [guillemets] - provides the capability to extend the basic modeling elements of the UML to create new elements <<Include>> - a similar chunk of behavior across more than one use case (artifact reuse) <<Extend>> - indicates that one use case is similar to another but it does more Scenario (documented via an interaction diagram) documented step-by-step instantiation of an 171 actual use case

Type

Brief Description
A role played by a person, other system or other objects A start-to-finish feature of the system The communication path between an actor and a use case that it participates in The insertion of additional behavior into a base use case that does not know about it A relationship between a general use case and a more specific use case that inherits and adds features to it The insertion of additional behavior into a base use case that explicitly describes the insertion The boundary of the information system

Notation

Actor Use case Association Extend Use case realization Include Boundary

<<extend>>

<<include>>

Figure 4.4 UML Use Case Diagram Notation

(adapted from The Unified Modeling Language Reference Manual, p. 65)
172

base use case

Place Order <<extend>> Request Catalog

extension use case

<<include>>
<<include>> Supply Customer Data Order Product

<<include>>

Arrange Payment

parent use case child use case

inclusion use cases

Pay Cash

Arrange Credit

Figure 4.5 UML Use Case Relationships

(adapted from The Unified Modeling Language Reference Manual, p. 66)
173

QUITTING

TIME

174