Use Case Modeling

Commonly Used UML Diagrams

The most commonly used UML diagrams are:
Use case diagram, describing how the system is used.
The starting point for UML modeling.

Use case (not a diagram). Activity diagram.

Each use case may create one activity diagram.

Commonly Used UML Diagrams

The most commonly used UML diagrams (continued): Sequence diagram, showing the sequence of activities and class relationships.
Each use case may create one or more sequence diagrams. A collaboration diagram is an alternative to a sequence diagram.

Commonly Used UML Diagrams

The most commonly used UML diagrams (continued): Class diagram, showing classes and relationships.
Sequence diagrams and CRC cards are used to determine classes.

Statechart diagram.
Each class may create a statechart diagram, useful for determining class methods.

Overview of UML Diagrams

Kendall & Kendall

2005 Pearson Prentice Hall

18-5

Use Cases
Depiction of a systems behavior or functionality under various conditions as the system responds to requests from users Full functioning for a specific business purpose

Use Case Diagram

A use (yoos) case describes what the system does, not how it does the work. The use case model reflects the view of the system of the user outside of the system. Symbols are:
Actor, a stick figure. Use case, an oval. Connecting lines.

UML Use Case Diagram Symbols

Use Case
Actor Boundary Connection
<<include>>

Include relationship Extend relationship

<<extend>>

Actors
Represent role played by one or more users Exist outside of the system May be a person, another system, a device, such as a keyboard or Web connection Can initiate an instance of a use case May interact with one or more use cases and a use case may involve one or more actors

Actors (Continued)
Actors may be divided into two groups: Primary actors supply data or receive information from the system Secondary actors help to keep the system running or provide help
Help desk, analysts, programmers, etc.

What is a Boundary?
A boundary is the dividing line between the system and its environment. Use cases are within the boundary. Actors are outside of the boundary.

Use Case
Consists of three things:
An actor (user) that initiates an event. An event that triggers a use case. The use case that performs the actions triggered by the event.

Use Case (Continued)

Better to create fewer use cases 20 use cases for a large system 50 use cases would be the maximum for a large system Can nest use cases, if needed

What is a Connection?
A connection is an association between an actor and a use case. Depicts a usage relationship Connection does not indicate data flow

Use Case Relationships

Communicates
Connect an actor to a use case

Includes
Use case contains a behavior that is common to more than one use case. The common use case is included in other use cases. Dotted arrow points toward common use case.

What is an <<include>> Relationship?

A connection between two use cases Indicates a use case that is used (invoked) by another use case Links to general purpose functions, used by many other use cases

Use Case Relationships (Continued)

Extends
A different use case handles variations or exceptions from the basic use case. Arrow goes from extended to basic use case.

Generalizes
One thing is more general than another thing. Arrow points to the general thing.

What is an <<extend>> Relationship?

A connection between two use cases Extends a use case by adding new behavior or actions Specialized use case extends the general use case

Use Case Relationships

2005 Pearson Prentice Hall

Steps for Creating a Use Case Model

The steps required to create a use case model are:
Review the business specifications and identify the actors within the problem domain. Identify the high-level events and develop the primary use cases that describe the events and how actors initiate them.

Steps for Creating a Use Case Model

The steps required to create a use case model are (continued):
Review each primary use case to determine possible variations of flow through the use case. Develop the use case documents for all primary use cases and all important use case scenarios.

Data Flow Diagrams

Introduction
What is a Data Flow Diagram? Why do we use DFDs? Levelling Conventions Decomposition and Abstraction The Elements Process and Data Stores Outside Entity Data Flow The Levels Rules The Procedure for Constructing DFDs The Document Flow Diagram

What is a Data Flow Diagram?

Known as DFDs A way to model a real world situation They are the interface between the real world activities and an understanding of how this can be converted into a computer system.

Why do we use DFDs?

It is a way of taking the physical view and converting it into a logical view. The physical view - all documents involved The logical view - the data they contain Their main purpose is to communicate with the user, the analysts understanding of the scope of the required system

Levelling
DFDs are expanded or decomposed into levels. Separating each process into sub processes Uncovers more and more detail

Conventions
Balancing Process at lower level should have identical data flows if they flow out of a process Modelling Data Stores Only use DATA STORES used within this process on the diagram Numbering 1 - 1.1 - 1.1.1 1.2 - 1.2.1 Labels Should carry as much meaning as possible

Decomposition and Abstraction

Decomposition - Divide and subdivide into manageable size problems Abstraction - Concentrate on the important issues and ignore the irrelevant

The Elements
The four main elements of DFDs notation Data Flows, with a label to indicate what data is flowing Processes, that handle the data Data stores, within the system (diary, filing cabinet or computer file) Outside entities, outside sources of data

Process and Data Stores

A process is made up of
Process Number Destination (Place or Name)

Process description Should be descriptive, starting with a verb.

Data Stores

Can be M for manual or D for computer base data stores.

M1

Name of Store

Outside Entity
Is anything outside the system that is of interest to the system. Can be a person, a company or another system.
Customer a

Outside entity shows the Name and a lowercase alpha character is used to uniquely identify it.

Customer a

If an outside entity is repeated for the purpose of neat layout a line is added across the top.

Data Flow
Is shown by a line with an arrowhead, indicating the direction of the flow of data. Each data flow should be named to indicate what data is being passed. Nouns or adjectives only no verbs are permitted.

The Levels
Context - Overview - contains only one process Level 1 - Utilises all four elements Level 2 - A breakdown of a level 1 process Level 3 - A breakdown of a level 2 process There is no rule as to how many levels of DFD that can be used.

Rules
Sequence not important - getting the Process correct is

Context or Level 0 - Identifies the system/ boundary/External Links Level 1 - Overview of function Level 2 - Breakdown to Understand Hard to know where to stop Rule of Thumb If there are more than 8 data flows break it Process of Identifying major Processes

The Procedure for Constructing DFDs

Draw a document flow diagram of the current situation Draw a systems boundary around the agencies that are part of the system Draw a Context Diagram Identify processes in the system Complete the level 1 Current Physical DFD

The Document Flow Diagram

The task of modelling a business situation can be daunting at first. It is best to start with something simple such as a document flow diagram.
Production Planning
Production Plan Delivery Note Purchase Order Supplier Details Update Form Delivery Note Material Requirements List

Supplier

Stock Control

Purchasing

Stock Withdrawal Note

Bill of Materials

Factory

Design

The Context Diagram

You decide which agencies are to be part of the system that you are examining. These agencies fall inside the system boundary and are reduced to one box in the centre. This is a Context Diagram

a Production Planning
Produc tion Plan

b Supplier
Delivery Note

e Design
Bill of M aterials

Stock Co ntrol Maintain Stock System

Stock Withdrawal Note

Supplier Details Update Form Delivery Note M aterial Requirements Lis t

c Purchasing

d Factory

(Lejk & Deeks)

All data flows going into the system must be received by a process. All data flows going out of the system must be generated by process. The first task is therefore to identify these processes:
1
Stoc k c l er k M ai ntai n pl anned cal l - off

Stoc k c l er k M ai ntai n s toc k c ar ds

Stoc k c l er k Pr epar e mater i al r eq mnts li st

Draw the external entities and data stores.

a Production Planning

Stock clerk

M1 Bill of m aterials
Maintain planned call-off

b Supplier

M2

Stock cards

c Factory

Stock clerk Maintain stock cards

3
d Purchasing

Stock clerk Prepare material reqmnts list

State Transition Diagrams

Dynamic Modelling

 An objects state and behaviour can be affected by:

Changes to attribute values Results of operations Changes of links with other objects Internal events External events

Three models
Object model:
Static structure of objects in a system and their relationships. Contains class diagrams.

dynamic model;
describes aspects that change over time: state transition diagrams

functional model;
Use Case diagrams

Dynamic modelling
Events states state diagrams conditions operations

Events
Something that happens at a point in time
Mouse button clicked / Signal changes

Logically ordered events - causally related Concurrent events - causally unrelated

do not effect each other there is no order between them

1-way transmission of information from one object to another

Event classes
Event occurrences are grouped into event classes
Flight 123 departs from Chicago / Flight 456 departs from Rome Event class is Flight Departs

Attributes of event classes

Departure origin of flight Flight number

Data values are Attributes

Event Classes and Attributes

Aeroplane flight departs (airline, flight no, city) Mouse button pushed (button, location) Input string entered (text) phone receiver lifted digit dialled (digit) engine speed enters danger zone

States
A state is an abstraction of the attribute values and links of an object. Sets of values are grouped together into a state according to properties that affect the gross behaviour of the object. E.G.. A bank is solvent or insolvent depending on whether its assets exceed its liabilities. A state corresponds to the interval between 2 events received by an object.
A state separates 2 events. An event separates 2 states.

Characterisations of a state
State: Alarm ringing Description: alarm on watch is ringing to indicate target time Event sequence that produces the state: set alarm (target time) any sequence not including clear alarm current time = target time

Condition that characterises the state:

alarm = on, and target time <= current time <= target time + 20s and button has not been pushed since the target time

Events accepted in the state:

event action next state current time = target time + 20s reset alarm normal button pushed (any button) reset alarm normal

State Diagrams
Relates to a specific object Relate states and events A change of state is called a transition All transitions leaving a state must correspond to different events The transition fires An event that has no transition is ignored A sequence of events corresponds to a path through the graph

State Transition Diagram

on-hook Idle off-hook Dial tone do : Sound dial tone digit (n) digit (n) Dialling Busy tone do : slow busy tone trunk busy number busy Fast busy tone do : play fast busy tone routed ringing do : ring bell called phone answ ers /connect line Connected on-hook/ disconnect line called phone hangs up /disconnect line Disconnected message done valid number Connecting do : find connection invalid number time-out Recorded message do : Play message time-out Time out do : sound loud beep

Initial/final States
The previous example is a continuous loop Most situations will have an initial and final state Chess game
White's turn checkmate Start White moves Black's turn Black moves stalemate white wins Draw Black wins

stalemate
Checkmate

Conditions
Used as guards on transitions.
A guarded transition only fires when the condition is true e.g.
When you go out in the morning (event), If the temperature is below freezing (condition). Put on your gloves (next state).

State Transition Diagram With Conditions

Traffic light time-out[cars in N/S right lanes] North/south may go straight time-out time-out[no cars in E/W right lanes] East/west may turn right Time out[cars in E/W right lanes] East/west may go straight North/south may turn right time-out[no cars in N/S right lanes] Time-out

Operations
Attached to state Performed in response to the state Attached to a transition Performed in response to the event

Activities and Actions

An activity is an operation that takes time.
E.G.. Display a picture on a screen. Do:a indicates that activity A occurs throughout the lifetime of the state to which it is attached.

An action is an instantaneous operation.

E.G.. Disconnect phone line. An action is shown on a transition as action / event.

T e e l p h o n e c a l I d e l o n h o o k o h f o o k

m i t e o u t D a i o t l n e T i m e o u t

d o S : o u n d d a i o t l n e d o s : o u n d o l u d d g i n ( t i ) d g i n ( t i ) m i t e o u t

D a i n i l g R e c o d r e d m e s n i v a d i l n u m b e r B u s y o t n e d o : P l a y m e s s a v a d i l n u m b e r d o s : o l w b u s y o t n e n u m b e b r u s y C o n n e c n i t g d o n i f : d c o n n e c o i t n r t u n k b u s y o r u e t d F a s b t u s y o t n e n i r g n i g

d o a f : s b t u s y o t n e d o n i r : g b e l m e s s a g c a e l d p h o n e a n s w e s r c / o n n e c n i l t e

C o n n e c e t d o n h o o k / d s i c o n n e c t n i l e c a e l d p h o n e h a n g s u p d / s i c o n n e c n i l t e D s i c o n n e c e t d

Constructing The Object Model Diagram

The Object Model Diagram is a graphical representation of the classes within a system and the static or underlying relationships between them.

The Class Diagram

Class name

Attributes

May be completed during design phase Completed during the design phase

methods

Associations Between Classes

One or more Student in a Course

Student

Course

name ID major GPA credit_hr

takes

name number credits prereqs

All Course objects participate

Cardinality Constraints

Zero or more

One or more

Zero or one

All objects of the class participate in the association (total)

1..4

Explicit cardinality

Examples
All Course objects have a professor and at least 1 student In any semester a professor will teach zero or more courses Students may take up to 6 courses
Student

+
takes 0.. 6 Course

Professor 1 teaches

Examples
Student Associations read from left to right

and top to bottom

+
takes 0.. 6

Professor 1 teaches

Course

Relationship Attributes
Employee Company + name works forfor works salary

+ name ss_num

salary

Bad salary as an attribute precludes the possibility Better model salary as a relationship attribute of an employee working for more than one company

Role Relationships
Person
name ss_num address 2

parent
child of

child

Role identifiers

Every person has 2 parents and zero or more children

Ternary Relationships
Project Programmer

assigned * +

1
Language

Every project is assigned a team of 1 or more programmers and written in 1 language

Aggregation
Colemans Notation

Aggregate Class Name

* Component 1 + Component 2 3 Component 3

Aggregation models the has-a relationship

Multiplicity of each component

Aggregation
UML Notation

Aggregate Class

Component 1

Component 2

Component 3

Example of Aggregation
Consider the Ternary Relationship Project-Programmer-Language

Project

Language

assigned

+ * Programmer

uses

A project has-a language and a team of one or more programmers assigned to it

Qualification to Remove Multiplicty

The qualifier is a special attribute that limits the multiplicity of an association.

The qualifier distinguishes among the set of objects at the many end of an association

Qualification
Example

Directory * contains

File

A directory contains zero or more files

Multiplicity can be removed by the qualifier file name which uniquely identifies a single file.

Qualification

Directory File name

File

Multiplicity is removed by the qualifier

Generalization and Specialization

Shape

area
perimeter

Circle

Rectangle

area perimeter

area
perimeter

Classes having the same attributes may be generalized to a common ancestor class

Generalization and Specialization

Vehicle

Land Vehicle

Air Vehicle

Water Vehicle

A sea plane travels in the air and on water

Generalization and Specialization

An empty triangle indicates that some objects belong to more than one of the subclasses (subclasses overlap)

A filled triangle indicates that all objects of the parent class belong to distinct subclasses