Functional Modeling-Software Requirement-Lecture Slides, Slides of Software Project Management

Download Functional Modeling-Software Requirement-Lecture Slides and more Slides Software Project Management in PDF only on Docsity!

1

Functional Modeling

Lecture # 34

2

Recap

• We had talked about object-oriented

static modeling in quite detail

• We had developed a OO static model

of the Banking System to gainunderstanding

4

Today’s Topics

• Today we’ll start our discussion on

functional modeling or function-oriented modeling

• We’ll apply this to our Banking

System case study also

• First, let us review the three principles

of modeling

5

Principles of Modeling

• Partitioning• Abstraction• Projection

7

Function-oriented Modeling

• Function-oriented modeling is based

on the concept of functions orprocesses, so they become the mostimportant element in this approach

• The functional model describes

computations within a system, i.e.,what happens

8

Function-oriented Modeling

• What is a function or a transform or

process?

• Each function is a sequential activity that

potentially may execute concurrently withother functions

• The functional model specifies the result of

a computation without specifying how orwhen they are computed

10

Asynchronous Function

• An asynchronous function can be

activated by another object or functionto perform some action

11

Asynchronous State-Dependent

Function

• An asynchronous state-dependent

function is usually a “one-shot” action,which is executed during a transitionfrom one state to another state

• This function is activated by a control

transformation

13

Periodic State-Dependent Function

• A periodic function is activated at regular

intervals to perform some action

• The frequency with which a specific

function is activated is applicationdependent

• This function is activated by a control

transformation

14

Functional Modeling

• Non-interactive programs, such as

compilers, usually are used forcomputations. The functional model is themain model for such programs

• On the other hand, databases often have a

trivial functional model, since their purposeis to store and organize data, not totransform it

16

Data Flow Diagrams

• Data flow diagrams are composed of

data on the move, transformations ofdata into other data, sources anddestinations of data, and data in staticstorage

• Data flow diagrams show the flow of

data through a system

17

Observations About DFDs

• All names should be unique• A DFD is not a flow chart• Suppress logical decisions• Do not become bogged down in details

19

Data Stores

Data is often stored for later use.

look-upsensor

data

sensor #

report required

sensor #, type,location, age sensor data

sensor number

type,location, age

20

Data Flow Diagramming:

Guidelines

• All icons must be labeled with

meaningful names

• The DFD evolves through a number

of levels of detail

• Always begin with a context level

diagram (also called level 0)