Req Modeling

7/30/2019 Req Modeling

1/78

Use Case Modeling


2/78

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.


3/78


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.


4/78


The most commonly used UML diagrams

(continued):

Class diagram, showing classes and relationships.

Sequence diagrams and CRC cards are used todetermine classes.

Statechart diagram.

Each class may create a statechart diagram, useful for

determining class methods.


5/78

Kendall & Kendall 2005 Pearson Prentice Hall 18-5

Overview of UML Diagrams


6/78

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


7/78

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.


8/78

UML Use Case Diagram Symbols

Use Case

Actor

Boundary

Connection

Include relationship

Extend relationship


9/78

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


10/78

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.


11/78

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.


12/78

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.


13/78

Use Case (Continued)

Better to create fewer use cases

20 use cases for a large system

50 use cases would be the maximum for alarge system

Can nest use cases, if needed


14/78

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


15/78

Use Case Relationships

Communicates

Connect an actor to a use case

Includes

Use case contains a behavior that is common tomore than one use case.

The common use case is included in other usecases.

Dotted arrow points toward common use case.


16/78

What is an Relationship?

A connection between two use cases

Indicates a use case that is used (invoked) byanother use case

Links to general purpose functions, used bymany other use cases


17/78

Use Case Relationships (Continued)

Extends

A different use case handles variations orexceptions 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.


18/78

What is an Relationship?

A connection between two use cases

Extends a use case by adding new behavior oractions

Specialized use case extends the general usecase


19/78

2005 Pearson Prentice Hall

Use Case Relationships


20/78


21/78


22/78

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.


23/78

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.


24/78

Data Flow Diagrams


25/78

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

DataFlow

The LevelsRules

The Procedure for Constructing DFDs

The Document Flow Diagram


26/78

What is a Data Flow Diagram?

Known as DFDs

A way to model a real world situation

They are the interface between the realworld activities and an understanding

of how this can be converted into a

computer system.


27/78

Why do we use DFDs?

It is a way of taking the physical viewand converting it into a logical view.

The physical view - all documents

involved

The logical view - the data they

contain

Their main purpose is tocommunicate with the user, the

analysts understanding of the scope

of the required system


28/78

Levelling

DFDs are expanded or decomposedinto levels.

Separating each process into sub

processes Uncovers more and more detail


29/78

ConventionsBalancing

Process at lower level should have identicaldata flows if they flow out of a process

Modelling Data Stores

Only use DATA STORES used within thisprocess on the diagram

Numbering

1 - 1.1 - 1.1.1

1.2 - 1.2.1

Labels

Should carry as much meaning as possible


30/78

Decomposition and Abstraction

Decomposition - Divide and

subdivide into manageable size

problems

Abstraction - Concentrate on the

important issues and ignore the

irrelevant


31/78

The ElementsThe four main elements of DFDs

notationData 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


32/78

Process and Data Stores

A process is made up of

Data Stores

Process Number

Destination (Place

or Name)

Process description

Should be descriptive,

starting with a verb.

M1Can be M for manual or D

for computer base data

stores.

Name of Store


33/78

Outside Entity

Is anything outside the system that isof interest to the system. Can be a

person, a company or anothersystem.

Outside entity shows the Name

and a lowercase alpha character

is used to uniquely identify it.

If an outside entity isrepeated for the purpose of

neat layout a line is added

across the top.

Customer

a

Customer

a


34/78

DataFlow

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.


35/78

The Levels

Context - Overview - contains onlyone process

Level 1 - Utilises all four elements

Level 2 - A breakdown of a level 1process

Level 3 - A breakdown of a level 2

process There is no rule as to how many

levels of DFD that can be used.


36/78

RulesSequence 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 UnderstandHard to know where to stop

Rule of Thumb

If there are more than 8 data flows break itProcess of Identifying major Processes


37/78

The Procedure for

Constructing DFDs

Draw a document flow diagramof the current situation

Draw a systems boundaryaround the agencies that are

part of the system Draw a Context Diagram

Identify processes in the system

Complete the level 1 Current

Physical DFD


38/78

The Document Flow Diagram

The task of modelling a businesssituation can be daunting at first. It is

best to start with something simplesuch as a document flow diagram.

Production

Planning

Stock Control

FactoryDesign

Purchasing

Supplier

Stock

NoteWithdrawal

Production

Plan PurchaseOrder

Delivery Note

Material Requirements List

Bill ofMaterials

Supplier Details Update Form

DeliveryNote


39/78

The Context Diagram

You decide which agencies are to bepart of the system that you areexamining.

These agencies fall inside the systemboundary and are reduced to one box inthe centre.

This is a Context Diagram

ProductionPlanning

Stock Control

Factory

Design Purchasing

Supplier

Stock

NoteWithdrawal

ProductionPlan

Delivery Note

Material Requirements List

Bil l of Materials

Supplier Details Update Form

DeliveryNote

MaintainStock System

a b

c

d

e

(Lejk & Deeks)


40/78

All data flows going into thesystem must be received by aprocess.

All data flows going out of thesystem must be generated byprocess.

The first task is therefore toidentify these processes:

Stock clerk

Maintain

1

2

3

Stock clerk

Stock clerk

planned call-off

Maintainstock cards

Preparematerial reqmnts

list


41/78

Draw the external entities and

data stores.

Production

Stock clerk

Maintain

aBill of materialsM1

1

2

3

Stock clerk

Stock cardsM2

Stock clerk

planned call-off

Maintainstock cards

Preparematerial reqmnts

list

Planning

Supplier

b

Factory

c

Purchasing

d


42/78

State Transition Diagrams

Dynamic Modelling


43/78

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


44/78

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


45/78

Dynamic modelling

Events

states

state diagrams

conditions

operations


46/78

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


47/78

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


48/78

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


49/78

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 itsassets 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.


50/78

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


51/78

Condition that characterises the state:

alarm = on,

and

target time


52/78

Events accepted in the state:

event action next state

current time = target time + 20s reset alarm normal

button pushed (any button) reset alarm normal


53/78

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 todifferent events

The transition fires

An event that has no transition is ignored

A sequence of events corresponds to a path throughthe graph


54/78

State Transition DiagramIdle

Dial tone

do : Sound dial tonedo : Sound dial tone

Connecting

do : f ind connectiondo : f ind connection

ringing

do : ring belldo : ring bell

Connected

Disconnected

Busy tone

do : slow busy tonedo : slow busy tone

Fast busy tone

do : play fast busy tonedo : play fast busy tone

Time out

do : sound loud beepdo : sound loud beep

Recorded message

do : Play messagedo : Play message

Dialling

off-hook

routed

called phone answ ers/connect line

called phone hangs up/disconnect line

on-hook

time-out

digit (n)time-out

message done

digit (n)

valid numberinvalid number

trunk busy

on-hook/disconnect line

number busy


55/78

Initial/final States

The previous example is a continuous loop

Most situations will have an initial and final state

Chess game

White's turn

Black's turn

white wins

Black wins

Draw

Start

Whitemoves

Blackmoves

checkmate

stalemate

stalemate

Checkmate


56/78

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


57/78

Traffic light

North/south may go straight

East/west may turn right

North/south may turn right

East/west may go straight

time-out[no carsin N/S right lanes]

time-out[no carsin E/W right lanes]

time-out

time-out[cars in N/S right lanes]

Time out[cars in E/W

right lanes]

Time-out

State Transition Diagram With

Conditions


58/78

Operations

Attached to state

Performed in response to the state

Attached to a transition

Performed in response to the event


59/78

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.

e

ep

oneca


60/78

Idle

Dialtone

do:Sounddialtone

Connecting

do:findconnection

ringing

do:ringbell

Connected

Disconnected

Busytone

do:slowbusytone

Fastbusytone

do:fastbusytone

i

:l

d:l

Dialling

off-hook

routed

calledphoneans/connectline

calledphonehan/disconnectline

on-hook

tie-out

digit(n)

time-out

digit(n)

validnumber

invalidnuber

trunkbusy

on-hook/disconnectline

numberbusy


61/78

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.


62/78

The Class Diagram

Class name

Attributes

methods

May be completed

during design

phase

Completed during

the design phase


63/78

Associations Between

Classes

Student

name

ID

major

GPA

credit_hr

Course

name

number

credits

prereqs

takes+

All Course objects participate

One or more Student in a Course


64/78

Cardinality Constraints

* Zero or more

+One or more

Zero or one

1..4

All objects of the class participate in the

association (total)

Explicit cardinality


65/78

Examples

Course

Student

Professor

takes

teaches

All Course objects have aprofessor and at least 1

student

+

1*

In any semester a professor

will teach zero or more

courses

0..

6

Students may take up to 6 courses


66/78

Professor Course

Student

takes

teaches

Examples

1

+

0..

6

and top to bottom

Associations read from left to right


67/78

Relationship Attributes

Employee

name

ss_num

salary

Company

name

works for

+

Bad salary as an attribute precludes the possibility

of an employee working for more than one company

works for

salary

+

Better model salary as a relationship attribute


68/78

Role

Relationships

Person

name

ss_num

address

child of

child

parent

Role

identifiers

2

*

Every person has 2 parents

and zero or more children


69/78

Ternary Relationships

Project Programmer

Language

assigned

+

1

*

Every project is

assigned a team of 1or more programmers

and written in 1

language


70/78

Aggregation

Colemans Notation

Aggregate Class Name

Component

1

Component

2

Component

3

* + 3

Multiplicity of each

component

Aggregation models the has-a

relationship


71/78

Aggregation

UML Notation

Aggregate Class

Component

1

Component

2

Component

3

*+

3


72/78

Example of Aggregation

Consider the Ternary Relationship Project-Programmer-Language

Project

Language

Programmer

uses*

assigned+

*

A project has-a language and

a team of one or more

programmers assigned to it


73/78

Q lifi ti


74/78

Qualification

Example

Directory File

contains

*

A directory contains zero or more files

Multiplicity can be removed by the qualifierfile name which

uniquely identifies a single file.

Q lifi ti


75/78

Qualification

Directory FileFilename

Multiplicity is removed by the qualifier

Generalization and


76/78

Generalization and

Specialization

Circle

areaperimeter

Rectangle

area

perimeter

Shape

area

perimeter

Classes having the same attributes may be generalized to a common

ancestor class


77/78

Generalization and Specialization

Vehicle

Land Vehicle Air VehicleWater Vehicle

A sea plane travels in the air and on water


78/78

Generalization and Specialization

An empty triangle indicates that someobjects 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

Documents

Req Modeling