chapter 4: business process and functional modeling

PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 5th EditionCopyright © 2015 John Wiley & Sons, Inc. All rights reserved.

Chapter 4:

Business Process and

Functional Modeling

1

Twittie Senivongse (Ed.)


Objectives

Understand the process used to identify business processes and use

cases.

Understand the process used to create use-case diagrams

Understand the process used to model business processes with

activity diagrams.

Understand the rules and style guidelines for activity diagrams.

Understand the process used to create use-case descriptions.

Understand the rules and style guidelines for use-case descriptions.

Be able to create functional models of business processes using use-

case diagrams, activity diagrams, and use-case descriptions.

2


Introduction

Now begin the process of turning the requirements into three

representations for the functional models

Models are logical; i.e. independent of how they are implemented (manual or

computerized)

Develop use-cases from the requirements

Use-case: how a business system interacts with its environment (i.e. how the users

externally view the process of the system)

Depict use-cases by a use-case diagram to show discrete activities that

the users perform

Develop an activity diagram to augment each use-case

It models a business process or how a business operates

Used to illustrate the movement of objects (data) between activities

Develop a use-case description to document each use-case

3


Use Cases Diagram

Use Case ประกอบดว้ย

1. ผูแ้สดง(Actor)

2. การโตต้อบ (Interaction )


ซกัผา้

ตวัอยา่ง UML Use-case Diagram

Verb

Use-case 1: เคร่ืองซกัผา้


ตวัอยา่ง UML Use-case Diagram Use-case 2: ระบบจ่ายเงินท่ีแคชเชียร์ซุปเปอร์มาร์เกต็

Check Out Itemcashier

customer

Verb


ตวัอยา่ง UML Use-case Diagram

Use-case 3: ระบบขายของบน internet

Browse หาสินคา้ เลือกสินคา้ลงตะกร้า electronic

ลงทะเบียนผูใ้ช้ จ่ายเงิน ไดรั้บใบเสร็จยนืยนั

Find Goods

user

Select Goods

Register

Pay

Receive Bill


ตวัอยา่ง UML Use-case Diagram Use-case 4: กลอ้งถ่ายรูป

A

B

https://forms.gle/91Wh42ag3B8K2Gha7


Business Process Identification

with Use-Case Diagram (1/2)

role, not specific user, providing input to and receiving output from the system

9


Business Process Identification

with Use-Case Diagram (2/2)

Used

use case

Base

use case

Extension

use case

Base

use case

Generalized

use case

Specialized

use case

actor

actor actor

Generalized actor Specialized actor

Multiplicity = number of associations, No arrowhead = two-way flow of information

Solid arrowhead = one-way flow of information

10


Creating a Use-Case Diagram

Review the requirements definition

Identify the subject’s boundaries, primary actors and their

goals, business processes and major use-cases

Carefully review the current set of use-cases

Split or combine some to create the right size

Identify additional use-cases

Place & draw the use-cases and actors

Draw the subject boundary

Add the associations

11


Example Use-Case Diagram

12



13

High level



14

More detailed

Make Old Patient Appt

extension points

Patient info update

New payment arrangement

or


Use Case Levels (1/3)

15

Cockburn, 2001, Writing Effective Use Cases.

Getting Started With Use Case Modeling

http://www.oracle.com/technetwork/testcontent/gettingstartedwithusecasemodeling-133857.pdf

http://www.oracle.com/technetwork/testcontent/gettingstartedwithusecasemodeling-133857.pdf


Use Case Levels (2/3)1. Summary goal

Cloud level (White): This is the enterprise level, and there may only be four

to five for the entire organization.

E.g. advertise goods, sell goods to customers, manage inventory, manage the supply

chain, and optimize shipping.

Kite level (White): This provides an overview, and may be at the business

unit or department level and is a summary of goals.

E.g. register students, or if working with a travel company: make an airline, hotel,

car, or cruise reservation.

2. User goal

Sea level (Blue): This often has the greatest interest for users and is easiest

for a business to understand. It is usually written for a business activity and

each person should be able to do one blue level activity in anywhere from 2 to

20 minutes.

E.g. register a continuing student, add a new customer, place an item in a shopping

cart, and checkout order.

16

http://www.w3computing.com/systemsanalysis/use-case-levels/



Use Case Level (3/3)

3. Subfunction

Underwater or fish level (Indigo): This shows lots of detail and

often at a functional or subfunctional level.

E.g. log in, choose a class, pay academic fees, look up the airport

code for a given city, and produce a list of customers after entering

a name.

Clam level (Black): This is the most detailed and at a

subfunction level.

E.g. validate login, insert an order line in an order,

17




Finding Actors

What are external objects that produce or consume data of the

system?

Who will use the main functionality of the system?

Who will need support from the system to do their daily tasks?

Who will need to maintain and administer the system, and keep it

working?

Which hardware devices does the system need to handle?

With which other systems does the system need to interact?

Who or what has an interest in the results (the value) that the

system produces?

18

Human Machine External system Organizational unit Sensor

http://www.inf.ed.ac.uk/teaching/courses/seoc/2011_2012/notes/SEOC03_notes.pdf



19

Four Types of Actors Primary business actor

The stakeholder that primarily benefits from the execution of the use case.

E.g. an employee receiving the paycheck

Primary system actor

The stakeholder that directly interfaces with the system to initiate or trigger the business or system event.

E.g. a bank teller entering deposit information

External server actor

The stakeholder that responds to a request from the use case.

E.g. a credit bureau authorizing a credit card charge

External receiver actor

The stakeholder that is not the primary actor but receives something of value from the use case.

E.g. a warehouse receiving a packing slip

19


Generalization between Actors

Actors may be similar in how they use the system.

Actor generalization indicates that instances of the more

specialized actor may be substituted for instances of the more

generalized actor.

20




Finding Use Cases

For each identified actor,

Which functions does the actor require from the system? What

does the actor need to do?

Does the actor need to read, create, destroy, modify, or store

some kind of information in the system?

Does the actor have to be notified about events in the system, or

does the actor need to notify the system about something? What

do those events represent in terms of functionality?

Could the actor’s daily work be simplified or made more

efficient by adding new functions to the system?

21




Generalization Relationship

between Use Cases

The specialized use case inherits the actors, behavior, and

meaning of the generalized use case.

The specialized use case may add to or override the behavior

of the generalized use case.

22

http://csis.pace.edu/~marchese/CS389/L9/Use%20Case%20Diagrams.pdf


http://www.interface.ru/rational/rup51/process/modguide/md_ucgen.htm

Place Order

Place Internet

Order

Place Phone

Order



http://www.interface.ru/rational/rup51/process/modguide/md_ucgen.htm


Include Relationship between

Use Cases The base use case incorporates the behavior of the included use case.

The included use case occurs as a required part of some larger base that

includes it.

The included use case can show the common behavior between base use

cases.

23

Update

Grade

Verify Student ID

Generate

Grade Report






Extend Relationship between

Use Cases The base use case is meaningful and complete on its own. It is

independent of the extension use case. The extension use case depends on

the base use case.

The extension use case represents additional functionality that is optional,

without which the model is consistent in itself. The extension use case is

somewhat divorced from the main flow of the base use case.

24

https://www.uml-diagrams.org/use-

case-extend.html

http://www.karonaconsulting.com/do

wnloads/UseCases_IncludesAndExt

ends.pdf

http://www.technologyuk.net/comput

ing/software-development/unified-

modelling-language/use-case-

diagrams.shtml

https://www.uml-diagrams.org/use-case-extend.html

http://www.karonaconsulting.com/downloads/UseCases_IncludesAndExtends.pdf

http://www.technologyuk.net/computing/software-development/unified-modelling-language/use-case-diagrams.shtml


Other Useful UML Elements: Package

25

membership

broad

cast

mainte

nance

discus

sion

newsletter


Other Useful UML Elements: Comment

26

http://uwe.pst.ifi.lmu.de/exampleIMDB.html

http://uwe.pst.ifi.lmu.de/exampleIMDB.html


Business Process Documentation with

Use Cases and Use-Case Descriptions

Use-case diagram provides a bird’s-eye view of the basic

functionality of the business processes in the system.

Use case

Primary driver for all UML diagramming techniques and continued design

activities

Describes a single function in which users interact with the system

May contain several execution paths or scenarios that a user can take when

interacting with the system.

Use-case description more fully documents the different aspects of each

use case.

27


Elements of a Use-Case

Description (1/2)• Overview:

• Name: verb-noun phrase

• ID number: for identification and tracing design decisions back to a requirement

• Type: overview or detail, and essential or real

• Primary actor: person or thing that starts the execution of the use case

• Brief description

• Importance level: for prioritizing which functions need to be included in which version of the system

• Stakeholder(s): those who have an interest in the use case

• Trigger(s): event (s) that cause the use case to begin

• External: e.g. customer placing an order, fire alarm ringing

• Temporal: e.g. book being overdue, the need to pay the rent

28


Elements of a Use-Case

Description (2/2)• Relationships:

• Association: Communication between the use case and the actors

• Extend: Extends the functionality of a use case to incorporate optional behavior

• Include: Includes another use case, enabling functional decomposition and reuse

• Generalization: Allows use cases to support inheritance

• Flow of events:

• Normal flow: the usual set of activities

• Sub-flows: decomposed normal flows to simplify the use-case

• We could also replace a sub-flow with a separate “included” use case.

• Alternate or exceptional flows: those not considered the norm

• We could also, in some cases, replace an alternate/exceptional flow with a separate “extension” use case.

• Optional characteristics

• Complexity level, time taken to execute, precondition of execution etc.

29


Types of Use Cases: Two Dimensions

30

Purp

ose

Amount of information

Overview DetailE

ssenti

al

• High-level overview of the

requirement, documenting only

the overview and relationships

parts, and

• Describing only essential

implementation-independent

issues necessary to understand

the required functionality

• Documenting all parts, including the

flow of events based on the activity

diagram

• Describing only essential

implementation-independent issues

necessary to understand the required

functionality• Example event: Receptionist

matches the patient’s desired

appointment time with the available

time.

Real

• High-level overview of the

requirement, documenting only

the overview and relationships

parts, and

• Describing technology and

design commitments and user

interface details on the real

system once implemented

• Documenting all parts, including the

flow of events based on the activity

diagram

• Describing technology and design

commitments and user interface

details on the real system once

implemented• Example event: Receptionist looks

up the available dates on Google

calendar to determine if the

requested appointment time is

available.


Creating Use-Case Descriptions

(1/2) Choose a high priority use-case and create the overview and relationships parts

Describe the normal flow of events

Write each step in the form of subject-verb-direct object, and optionally,

preposition-indirect object (SVDPI sentence)

E.g. The patient contacts the office regarding the appointment (will later suggest Patient,

Office, Appointment classes in the structural model)

Make clear who or what is the initiator and who or what is the receiver of the step,

i.e. subject and direct object

Write from independent observer’s perspective, not the initiator’s or the receiver’s

Write a sensible set of steps that should comprise four parts:

Primary actor initiates execution by sending a request (and data) to the system.

System ensures that the request (and data) is valid.

System processes the request (and data) and possibly changes its internal state.

System sends the primary actor the processing result.

Write repeating instructions after the set of steps to be repeated

31


Creating Use-Case Descriptions

(2/2) Ensure that the steps listed are not too complicated or long, and are about

the same size

E.g. Borrower specifies the name of book to borrow is smaller than Borrower

reserves a book via interlibrary loan.

Apply the KISS principle liberally, i.e. use sub-flows or decompose into a set

of use cases (care must be taken though)

Identify and write the alternate or exceptional flows

Review the use-case description with the user to confirm that it is correct

Look for opportunities for include, extend, and generalization relationships,

and to add or merge use cases

Repeat until a sufficient number of major use cases are documented

32



33

https://forms.gle/rKx3d7Jb7RTnDtWH6

https://forms.gle/rKx3d7Jb7RTnDtWH6


Example Use-Case Description

343a.

4a.

1

2

3

45

6

7

8109



35

High level



36

More detailed

Make Old Patient Appt

extension points

Patient info update

New payment arrangement

or

PowerPoint Presentation for Dennis, Wixom, & Tegarden Systems Analysis and Design with UML, 5th EditionCopyright © 2015 John Wiley & Sons, Inc. All rights reserved. 37

High

, Make Payment Arrangements

or Extension points: Patient info update

or Extension points: New payment arrangement


Place Call

extension points

Conference Call

Caller Identity

Show Caller

Identity

Place

Conference

Call

http://www.michael-richardson.com/processes/rup_for_sqa/core.base_rup/guidances/guidelines/extend-

relationship_EF38D814.html

http://www.michael-richardson.com/processes/rup_for_sqa/core.base_rup/guidances/guidelines/extend-relationship_EF38D814.html


Normal Flow of Place Call (base use case)

1. The Caller lifts receiver.

2. The system presents dial-tone.

3. The Caller dials a digit.

4. The System turns off the dial-tone.

5. The Caller enters the remainder of the number.

6. The system analyzes digits, determines network address of the Receiving Party.

7. The system analyzes the digits, determining the location in the network where the

Receiving Party exists.

8. The system then determines whether a virtual circuit can be established to the Receiving

Party.

9. If a virtual circuit can be established, the System rings the Receiving Party's phone and

presents the ringing tone on the Caller's phone.

10. When the Receiving Party answers the phone, the system disables the ringing tone on

the Caller's phone, stops ringing the Receiving Party's phone and completes the virtual

circuit.

11. The system starts a billing record, recording the start time for the call, the end points of

the call, and the Caller's customer information.

(Extension points: Conference Call)

12. The call continues for some length of time. When either the Caller or the Receiving

Party disconnects from the call, the system records the end time for the call, and frees all

resources required to support the virtual circuit. The use case then ends.





Normal Flow of Place Conference Call (extension use case is inserted at extension

point Conference Call)

1. Caller depresses the hang-up, link, or flash button.

2. The system generates 3 short beeps to acknowledge.

3..12.<these steps are identical to steps 3..12 from the base use case>

13. Caller is reconnected to the receiving party from the Place Call base use case.





Business Process Modeling with

Activity Diagrams

Business process models describe a number of activities that

support a business process.

Powerful tool for communicating the analyst’s understanding of the

requirements to the user.

Activity diagrams depict the sequence of these activities

An activity diagram provides a more-detailed graphical view of the

underlying activities of each business process

Diagrams are abstract and describe processes in general

They model behavior independent of objects

Can be used for any type of process

E.g. high-level workflow involving many use cases, detail of a single use

case, detail of a method

42


Activity vs. Action

Final-Activity Node vs. Final-Flow Node

www.gentleware.com

www.safaribooksonline.com


Swimlane



Activity Diagram Symbols (1/2)

45

Manual or computerized

Named with a verb and a noun,

short but understandable Mostly associated with a use case

Actual information object that flows into and out of the action or activity

Other parallel paths can continue.

There should be one node at the top or top left.

Mostly there should be one node at the bottom or bottom right.


Activity Diagram Symbols (2/2)

46

or guard condition

Mutually exclusive

Most important individual or object should be at the top or the left.

After a fork, there is a join.


Creating an Activity Diagram

Choose a business process to set the scope

Review the requirements definition and use-case diagram

Review other documentation collected thus far

Identify the set of activities; connect them with control flows,

object flows, and nodes

Identify any decisions that must be made and potential

parallelism

Draw the diagram

Minimize crossing lines

Lay out in left-to-right and/or top-to-bottom order

47


High

, Make Payment Arrangements




Example Activity Diagram

Involving

Manage Appointments,

Make Old Patient Appt,

Make New Patient Appt,

Update Patient Information,

Make Payment Arrangements,

and

Create New Patient use cases

1

2

3 4 5

6

https://forms.gle/CPDPYBnzfsCAb3gc6

https://forms.gle/CPDPYBnzfsCAb3gc6


Verifying and Validating Business

Processes and Functional Models Verification: The process of checking that a system meets specifications, i.e. are

we building the system right?

Validation: The process of checking that a system fulfills its intended purpose or

meets the needs of the user and other identified stakeholders, i.e. are we building

the right system?

Utilize a walkthrough to review all functional models before beginning

structural and behavioral modeling

Purpose:

Test fidelity of the functional models to the functional requirements

Ensure that the models are consistent

Performed by individuals from the development team and the client (very interactive)

Facilitator: schedule and set up the meeting

Presenter: the one who is responsible for the specific representation being reviewed

Recorder (scribe) to take notes and especially to document errors

51


Rules for Verification &

Validation (1/4)1. Ensure one recorded event in the flows of the use-case description for

each action/activity on the activity diagram

2. All objects in an activity diagram must be mentioned in an event of the

use-case description

52



Validation (2/4)3. The sequence of the use-case description should match the

sequence in the activity diagram

4. One and only one use-case description for each use-case

53





Validation (3/4)5. All actors listed in a use-case description must be shown on the use-case

diagram with the association link

6. Stakeholders listed in the use-case description may be shown on the use-

case diagram (check local policy)

54

Not really participate in Make Old Patient Appt



Validation (4/4)7. All other relationships in the use-case description (include, extend,

generalization) must be depicted on the use-case diagram

8. All diagram-specific rules (syntax and semantics) must be enforced

e.g. (activity diagram) decision node connects to activity/action node only with

control flow, every decision node should have a matching merge node etc.

55




Demo: Patterson Superstore

https://forms.gle/f8gVqiDE56e5ej1c8

57

https://forms.gle/f8gVqiDE56e5ej1c8


Summary

Presented in this chapter:

The identification of business processes using use-case

diagrams and descriptions

Modeling business processes with activity diagrams

How to create the documentation of use-cases and use-case

descriptions

How to verify and validate the business processes and

functional models

58

chapter 4: business process and functional modeling

Documents