Use Case Diagrams – Functional Models

Chapter 5

Objectives

• Understand the rules and style guidelines for activity diagrams.

• Understand the rules and style guidelines for use cases and use-case diagrams.

• Understand the process used to create use cases and use-case diagrams

• Be able to create functional models using activity diagrams, use cases, and use-case diagrams.

2

BUSINESS PROCESS MODELING WITHACTIVITY DIAGRAMS

3

Business Process Modeling Business process models describe the activities

that collectively support a business process A very powerful tool for communicating the

analyst’s current understanding of the requirements with the user

Activity diagrams are used to model the behavior in a business process

4

Activity Diagram Syntax Action or Activity– Represents action or set of actions

Control Flow– Shows sequence of execution

Initial Node– The beginning of a set of actions

Final Node– Stops all flows in an activity

Decision Node– Represents a test condition

5

Sample Activity Diagram

6

Guidelines for Activity Diagrams

1. Set the scope of the activity being modeled2. Identify the activities, control flows, and object

flows that occur between the activities3. Identify any decisions that are part of the

process being modeled4. Identify potential parallelism in the process5. Draw the activity diagram

7

USE-CASE DESCRIPTIONS

8

Use Cases A use case illustrates the activities that are

performed by users of a system. Describe basic functions of the system

– What the user can do– How the system responds

Use cases are building blocks for continued design activities.

9

Types of Use CasesPurpose

Amount of information

Overview Detail

Essential

High-level overview of issues essential to understanding required functionality

Detailed description of issues essential to understanding required functionality

Real

High-level overview of a specific set of steps performed on the real system once implemented

Detailed description of a specific set of steps performed on the real system once implemented

10

Use Case Elements: Overview

• Name• ID Number• Type• Primary Actor• Brief Description• Importance Level• Stakeholder(s)• Trigger(s)

11

Use Case Elements: Relationships Association

‒ documents the communication between the use case and the actors that use the use case

Extend‒ represents the extension of the functionality of the use case to incorporate optional

behavior Include

‒ shows the mandatory inclusion of another use case Generalization

‒ allows use cases to support inheritance Normal Flows

‒ include only those steps that normally are executed in a use case Sub-Flows

‒ the normal flow of events decomposed to keep the normal flow of events as simple as possible

Alternate or Exceptional Flows‒ flows that do happen but are not considered to be the norm 12

Sample Use Case Description

13

Use Case Writing Guidelines

1. Write in the form of subject-verb-direct object2. Make sure it is clear who the initiator of the step is3. Write from independent observer’s perspective4. Write at about the same level of abstraction5. Ensure the use case has a sensible set of steps6. Apply the KISS principle liberally.7. Write repeating instructions after the set of steps to be

repeated

14

USE-CASE DIAGRAMS

15

Use Case Diagram Syntax

• Actor– person or system that derives benefit from and is

external to the subject• Use Case– Represents a major piece of system functionality

• Association Relationship• Include Relationship• Extend Relationship• Generalization Relationship

16

<<extends>>

<<includes>>

Sample Use Case

17

CREATING USE-CASE DESCRIPTIONSAND USE-CASE DIAGRAMS

18

Identify the Major Use Cases

1. Review the activity diagram2. Find the subject’s boundaries3. Identify the primary actors and their goals4. Identify and write the overviews of the major

use cases for the above5. Carefully review the current use cases. Revise as

needed

19

Extend the Major Use Cases

6. Choose one of the use cases to expand7. Start filling in the details of the chosen use case8. Write the normal flow of events of the use case9. If the normal flow of events is too complex or

long, decompose into sub flows10. List the possible alternate or exceptional flows11. For each alternate or exceptional flow, list how

the actor and/or system should react

20

Confirm the Major Use Cases

12. Carefully review the current set of use cases. Revise as needed

13. Start at the top again

21

Create the Use Case Diagram

1. Draw the subject boundary2. Place the use cases on the diagram3. Place the actors on the diagram4. Draw the associations

22

REFINING PROJECT SIZE AND EFFORTESTIMATION USING USE-CASE POINTS

23

Use-Case Points A size and effort estimation technique that was

developed around use cases– Better for OOSAD projects than function points

Requires at a minimum:– The set of essential use cases– The use case diagram– All actors and use cases classified as simple, average,

or complex

24

Actor & Use Case Weighting Tables

Actor Type Description Weighting Factor

Simple External System with well-defined API 1

Average External System using a protocol-based 2interface, e.g., HTTP, TCT/IP, or a database

2

Complex Human 3

Use-Case Type Description Weighting Factor

Simple 1-3 transactions 5

Average 4-7 transactions 10

Complex More than 7 transactions 15

Unadjusted Use Case Points (UUCP) = UAW + UUCW

Unadjusted Use Case Weighting (UUCW)

Unadjusted Actor Weighting (UAW)

25

Technical Complexity FactorsFactor Number

Description Weight

T1 Distributed system 2.0

T2 Response time or throughput performance objectives 1.0

T3 End-user online efficiency 1.0

T4 Complex internal processing 1.0

T5 Reusability of code 1.0

T6 Easy to install 0.5

T7 Ease of use 0.5

T8 Portability 2.0

T9 Ease of change 1.0

Technical Complexity Factor (TCF) = 0.6 + (0.01 * TFactor)26

Environmental FactorsFactor Number

Description Weight

E1 Familiarity with system development process in use 1.5

E2 Application experience 0.5

E3 Object-oriented experience 1.0

E4 Lead analyst capability 0.5

E5 Motivation 1.0

E6 Requirements stability 2.0

E7 Part time staff -1.0

E8 Difficulty of programming language -1.0

Environmental Factor (EF) = 1.4 + (-0.03 * EFactor)27

Person-Hours Multiplier

If the sum of (number of Efactors E1 through E6 assigned value < 3) and (number of Efactors E7 and E8 assigned value > 3) ≤ 2

PHM = 20Else If the sum of (number of Efactors E1 through E6

assigned value < 3) and (number of Efactors E7 and E8 assigned value > 3) = 3 or 4

PHM 28Else

Rethink project; it has too high of a risk for failure28

Computing Use-Case Points Adjusted Use Case Points (UCP)

UCP = UUCP * TCF * ECF Effort in Person Hours = UCP * PHM

29

Use-Case Point Estimation for the Appointment System

30

Summary Business Process Modeling with Activity Diagrams Use-Case Descriptions Use-Case Diagrams Refining Project Size and Effort Estimation with

Use-Case Points

31