asper school of business university of manitoba systems analysis & design instructor: bob...

17
Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated 2014

Post on 19-Dec-2015

218 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

Asper School of Business University of Manitoba

Systems Analysis & Design

Instructor: Bob Travica

Analyzing system processes:Use Case Diagram

Updated 2014

Page 2: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

3510 Systems Analysis & Design * Bob Travica 2

Outline

The use case concept Business events and systems Elements of use case diagram Include and Extend relationships

between use cases Reading use case diagrams Creating use case diagrams

Page 3: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

3

Use case concept

• Use case is a model of system functionality.• Think of main functions a system performs

for users – “cases” of using a system.

Figure 6-3

Use Case Diagram

of Order-Entry

Subsystem

for RMO

Use case

Page 4: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

3510 Systems Analysis & Design * Bob Travica 4

Use case diagram in system documentation

• Use Case helps to model system requirements

• Easier for users to understand than other diagrams

Page 5: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

5

Business Event concept

Figure 5-2Events affecting a payment system

that determine what system has to do – functions, use cases

• A stimulus that requires a system’s response • Delineated in time; stands on its own

External events occur outside the system

“clerk calls upcustomer account”

Temporal Events

Page 6: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

3510 Systems Analysis & Design * Bob Travica 6

Event types

External Events (outside an IS)

Caused by external agent (human, system)

Temporal Events (inside an IS)

Occur at a certain point in calendar time

State Events (inside an IS) Changes in system states, such as data

Event: QuantityOnHand =< ReorderAmount (QOH goes under

a min.) System’s response: Create new

purchase order

Internal events - logic of automated decisions

Page 7: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

3510 Systems Analysis & Design * Bob Travica 7

Figure 5-10

Input Output

Events Table

Page 8: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

3510 Systems Analysis & Design * Bob Travica 8

Elements of use case diagram:

Actor and System• Actor is someone interacting with use case (system function). Named by a noun.

• Similar to the concept of user, but(a)can be non-human and (b)a user can play different roles;(e.g.,: an employee can be worker and manager – plays 2 roles in a system*).

Name

System

• System• Shape of oval, contains small ovals that stand for use cases (system functions)

Page 9: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

Actor-System relationship

3510 Systems Analysis & Design * Bob Travica 9 of 14

• Actor triggers (initiates, starts) use case (a system function).

•Actor has responsibility toward the system (inputs), and Actor has expectations from the system (outputs).

• System has responsibility to respond properly to events – to execute an appropriate function.

Page 10: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

= Use Case

3510 Systems Analysis & Design * Bob Travica 10

Elements of use case diagram:Use Case

System function (process – automated or manual). Named by a verb.

Do something

Each Actor must be linked to a UC, while some use cases may not be linked to actors (e.g., functions responding to temporal events, UC related to another UC).

Page 11: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

3510 Systems Analysis & Design * Bob Travica 11

Elements of use case diagram:

Other components

Boundary of system

<<include>>

Include relationship between Use Cases (one UC must

call another; e.g., Login UC includes User Authentication UC)

<<extend>>

Extend relationship between Use Cases (one UC may

call another under certain conditions; think: if-then decision points)

Connection between Actor and Use Case

Relationships between Use Cases

Page 12: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

3510 Systems Analysis & Design * Bob Travica 12

Include relationship

• Include relationship – a standard UC linked to a mandatory UC.

• Standard use case can NOT execute without the include case tight coupling.

• Example: to Authorize Car Loan (standard use case), a clerk must run Check Client’s Credit History (include use case). • The standard UC includes the mandatory UC (use the verb to figure direction arrow).

• Note: Visio calls this “uses” relationship.

Do something And do as part ofDo something

includes

Page 13: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

3510 Systems Analysis & Design * Bob Travica 13

Reading use case diagramwith Include relationship

Page 14: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

3510 Systems Analysis & Design * Bob Travica 14

• Extend relationship – linking an optional use case to a standard use case.

Extend relationship

• Example: Register Course (standard use case) may have Register for Special Class (extend use case) – class for non-standard students, in unusual time, with special topics, requiring extra fees…).

• The optional UC extends the standard UC

• Standard UC executes without the extend UC; an extend UC executes instead of standard UC. loose coupling.

Do something Do if conditions apply

extends

Page 15: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

UC relationships – warning!

Invoke them sparingly, only when necessary to show connections between system functions.

Do not fall in a process trap - thinking about UCs as steps of a process. UCs are system functions.

Note: UC diagram vs. Activity diagram

3510 Systems Analysis & Design * Bob Travica 15 of 14

System collapsed into

expanded into

Page 16: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

Temptations with <<extend>>

3510 Systems Analysis & Design * Bob Travica 16 of 14

Log in<<extends>>

<<extends>>

<<extends>>

Over-draft WDL

<<extends>>

Page 17: Asper School of Business University of Manitoba Systems Analysis & Design Instructor: Bob Travica Analyzing system processes: Use Case Diagram Updated

3510 Systems Analysis & Design * Bob Travica 17

How to create use case diagram

1. List main system functions (use cases) in a column:

think of business events demanding system’s response

users’ goals/needs to be accomplished via the system

Create, Read, Update, Delete (CRUD) data tasks

Naming use cases – user’s needs usually can be translated in data

tasks

2. Draw ovals around the function labels (use cases)

3. Draw system boundary 4. Draw actors and connect them with use cases (if more

intuitive, this can be done as step 2)

5. Specify include and extend relationships between use cases (yes, at the end - not before, as this may pull you into process thinking,

which does not apply in UC diagramming).