Process Modeling

COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 1

COMP3110/6311Modeling Processes with Data Flow Models

COMP3110/6311

© Dr Clive Boughton Slide 1© L. JohnsBoast & Dr Clive Boughton Slide 1


Process Modeling

We will adopt elements of Structured Analysis and Design to model processes–Data Flow Diagrams• To show the flow of data through processes

– Data Dictionary• That contains definitions of data together with accuracy,

units of measure, range etc.

– Structured Language• To describe processes using a concise set of terms that

enhance clarity and understanding.• Also may include, equations, tables, charts & diagrams.

– Decision Tables and/or Trees• To clearly indicate decision processing when language

becomes too convoluted or difficult to follow.


Data Flow Diagrams (DFD)


DFD Elements

PROCESS

DATAFLOWS

• Identify processes that transform input data into output data

• Mechanical, human or software functionality• Processes should be named with a short action clause

● Dataflows indicate the content and direction of flow of information (or materials) to and from processes, stores and terminators.

● Treat them as pipelines along which single or groups of data/material items of known content and nature can flow.

● Their names reflect their content nouns or adjectives.● They do not contain or represent dynamic behaviour no

verbal names.


DFD Elements

TERMINATOR

STORE• Stores represent dataflows that are frozen for an

indeterminate time.• The information/materials they represent can be

accessed at any time and in any order.• Nouns and/or adjectives should be used sometimes

plural.

• Terminators represent things that are external to the system, but which are important because they provide &/or receive system input and output.


A primitive network

ExternalEntity

PrimitiveProcess

InternalStore

DataFlow


Data Flow Diagram Decomposition

SUBPROCESSES OF PROCESS 1.1

PROCESS

1.1.2

PROCESS

1.1.1

PROCESS

1.1.3

SUBPROCESSES OF PROCESS 1

PROCESS

1.2

PROCESS

1.1

PROCESS

1.3STORE-B

INPUT-AINPUT-AA

MAJOR PROCESSESOR SUBSYSTEMS

SYSTEM CONTEXTActuator

SoftwarePackage

Human

SensorPhysical

Environment

THESYSTEM

0

INPUT

OUTPUT

PROCESS

2

PROCESS

1

PROCESS

4

PROCESS

3

STORE-A

INPUT-A

OUTPUTINPUT-B

INPUT-AAINPUT-AB

STORE-A

NOTE:• Inputs & Outputs BALANCE.• Dataflows CAN BE

GROUPED.• Dataflows MAY BE SPLIT.• Stores CAN BE

DUPLICATED.• UNIQUE Process

NUMBERING.• Dataflows/Stores DEFINED IN

DD.

INPUT---------------------------

Data Dictionary


Contents of a Set of DFDs for a System

• A readable summary of what is supposed to be done.• Dataflows & Stores which are fully defined in the

Data Dictionary.• Process and dataflow type that is largely

determined by the scope of the problem to be analysed.

● Terminators usually shown only at the context level, but may be also shown at other levels for convenience.

• Defers issues concerned with initialisation and termination assumes steadystate operation of the system.• Omission of processing of trivial errors.


Example – Make a Pizza

MakePizza

HotPepper

Tomatoes

Salami

Mushrooms

Cheese

Capsicum

Onions

Pizza

Flour

Milk


Make a Pizza – More Detail

PreparePizzaBase

1.2

ChopVegetables

1.3

GrateCheese

1.1

SliceSalami

1.4

AssemblePizza

1.6

CookPizza

1.5

MilkFlour

Capsicum

Onions

Mushrooms

Cheese

HotPepper

Tomatoes

ChoppedVegetables

Salami

SlicedSalami

AssembledPizza

PizzaBase Grated

Cheese

Pizza

Making a pizza requires several separate activities,all of which can be done concurrently, onebyonein no particular order, or several at the one time.

MakePizza

1

HotPepperTomatoes

Salami

Mushrooms

Cheese

Capsicum

Onions

Pizza

Flour

Milk


Characteristics of DFDs

PreparePizzaBase

1.2

ChopVegetables

1.3

GrateCheese

1.1

SliceSalami

1.4

AssemblePizza

1.6

CookPizza

1.5

MilkFlour

Capsicum

Onions

Mushrooms

Cheese

HotPepper

Tomatoes

ChoppedVegetables

Salami

SlicedSalami

AssembledPizza

PizzaBase Grated

Cheese

Pizza

MakePizza

1

HotPepperTomatoes

Salami

Mushrooms

Cheese

Capsicum

Onions

Pizza

Flour

Milk

Dataflows must berelevant to process.

Name processes in terms oftransforming inputs into outputs.

Dataflows do not represent control.

Dataflows are not process activators.View dataflows as pipelines overwhich materials/information move.

Name dataflows by substance & characteristic.


Dataflow Grouping

MakePizza

1

Pizza BaseIngredients

Toppings

Pizza

PreparePizzaBase

1.2

ChopVegetables

1.3

GrateCheese

1.1

SliceSalami

1.4

AssemblePizza

1.6

CookPizza

1.5

Cheese

ChoppedVegetables

Salami

SlicedSalami

AssembledPizza

PizzaBase Grated

Cheese

Pizza


Vegetables

Dataflows are best grouped when they havethe same class or temporal characteristics.

DDEs:-Pizza Base Ingredients = Flour + MilkToppings = Vegetables + Cheese + SalamiVegetables = Tomatoes + Capsicum + Mushrooms + Hot Pepper + Onions


Dataflow and Process Abstraction

PreparePizzaBase

1.2

ChopVegetables

1.3

GrateCheese

1.1

SliceSalami

1.4

AssemblePizza

1.6

CookPizza

1.5

Cheese

ChoppedVegetables

Salami

SlicedSalami

AssembledPizza

PizzaBase Grated

Cheese

Pizza


Vegetables

Make Coffee

1.7

CoffeeBeans

Sugar

Water

Coffee

MakePizza

1


Ingredients

Pizza

DDEs:-Ingredients = Vegetables + Cheese + Salami + Coffee Beans + Sugar + Water

Good dataflow groupingbegets good functionalgrouping & vice-versa.

Apply proper abstraction to dataflow groupingsas well as functional groupings. Avoid the ad hoc.


Dos and Don'ts of DFDs

Accept Payment

5

Payment

OverPayment

UnderPayment

BillAmount

Don’t show possible outcomesof a process as split data flows.

Do label data flows according tocontent and define any possibleoutcomes in the data dictionary.

Example:Accepted Payment =[Over Payment | Under Payment]

Accept Payment

5

Payment

AcceptedPayment

BillAmount


Dos and Don'ts of DFDs continued

Accept Payment

5

BillAmount

Payment

Payment = Bill Amount

Payment < Bill Amount

Payment > Bill Amount

Don’t show control processingon data flows.

Do label data flows according to contentand show control processing insidefunctional primitives with outcomesdefined in the data dictionary.

Example:Accepted Payment =[Over Payment | Exact Payment | Under Payment]

Accept Payment

5

Payment

AcceptedPayment

BillAmount



Don’t loop Do describe iterative processingwithin functional primitives.

Repeat until no further input:Read Vegetable Order from Customer Orders;Select Vegetables according to the Vegetable Order:Chop up all the selected vegetables;Collect the Chopped Vegetables togetherand pass them on;

ChopVegetables

1.3

Vegetables

VegetableOrder

GetNextOrder

1.7

NextVegetable

Order

VegetableOrder

Request

ChoppedVegetables

Vegetables

Customer Orders

ChopVegetables

1.3

Vegetables

VegetableOrder

ChoppedVegetables



TakeCustomer

Order

2

Order

Standard Menu

AcceptedOrder

CustomerRequest

TakeCustomer

Order

2

Order

Standard Menu

AcceptedOrder

Don’t use dataflows asProcess activation signals

Do describe control eventswithin functional primitives.

Whenever a customer indicates the intention to order:Go to the customer prepared to take an Order;When necessary check the Order with Standard Menu;If .....Then ..........Place Accepted Order with any other Customer Orders.



● Don’t draw too many process bubbles on a DFD● Use the Miller Factor (7 plus/minus 2) wisely● Too many bubbles may indicate:

• Too little composition.• System is too large.

● Don’t draw too many trivial DFDs● Lots of DFDs with only a few bubbles may indicate:

• Too much partitioning• A very small system

● Do draw DFDs that contain a high degree of functional abstraction


De Marco conventions for Data Store Access

STORE

PROCESS

STORE

PROCESS

STORE

PROCESS

READ ONLY

READ AND THEN WRITE

UPDATE (NET FLOW)


Essential Environment

System ContextShows essential external entities with whichthe system (isolated as a single process) mustcommunicate information or material items.

Yourdon refers to the Context Diagramas the Environmental Model.

MANAGEPIZZABAR

0

FOOD STORAGE

CUSTOMER

Ingredients

Payment

DeliveredOrder

Order


Essential Behavior

Customer Orders

MakePizza

1

Toppings

Pizza

TakeCustomer

Order

2

PrepareBeverage

3

Order

Standard Menu

AcceptedOrder

Pizza Order

BeverageOrder

Beverage

Delivered Order

BeverageIngredients

IssueBill

4

Customer Orders Standard Menu

AcceptedOrder

Prices

BillAcceptPayment

5

Payment

Cash Register

AcceptedPayment


DFD-0Shows major essential processesthat must be performed by the system on the inputs/outputsreceived/produced by the externalenvironment.

Yourdon refers to DFD0 andall the supporting DFDs etc.as the Behavioral Model.


Data Dictionary (DD)


The Data Dictionary – Purpose

● Maintain an ordered list of rigorous definitions for:

● Data Flows and Data Stores● Elementary components of Data Flows and Stores● Data Store Relationships

• Definitions should include:● Name (including aliases)● Description of meaning (usually as commentary)● Data attributes (value range, units, rate, accuracy)● Composition (grouped or primitive)


Data Dictionary – Summary

● The DD should contain a definition for every Data Flow and Data Store shown on the set of DFDs.

● All known properties of each Data Flow and Data Store should be included with it’s dictionary definition.

● Constructing the DD is essential to creating a specification that has the properties of being consistent and unambiguous.

● DD construction can be tedious so it is important to adopt an incremental approach.


Process Specifications (PSpec)


Process Specifications Purpose

● To describe what a primitive process must accomplish.

● Descriptions must explain what has to be done to (data) inputs in order to produce the resultant (data) outputs.

● Statements must be• Readable• Verifiable• Understandable• Precise• Succinct


Process Specifications & DFDs

The DFD structure

• IS NOT a specification.• IS a logical layout.


PROCESS

1.1.2

PROCESS

1.1.1

PROCESS

1.1.3

SUBPROCESSES OF PROCESS 1

PROCESS

1.2

PROCESS

1.1

PROCESS

1.3STORE-B

INPUT-AINPUT-AA


SYSTEM CONTEXTActuator

SoftwarePackage

Human

SensorPhysical

Environment

THESYSTEM

0

INPUT

OUTPUT

PROCESS

2

PROCESS

1

PROCESS

4

PROCESS

3

STORE-A

INPUT-A

OUTPUTINPUT-B

INPUT-AAINPUT-AB

STORE-A


Process Specifications (PSpec)

Process Specification

NAME:

(Data) I/O:

Description:

TextualGraphicalTabularMathematical


PROCESS

2

PROCESS

1

PROCESS

4

PROCESS

3

STORE-A

A PSpec can occur anywherewithin the DFD structure.

It is not usual for processes shown onDFD0 to become PSpecs unless the system is small ( say < 20 Pspecs in all)


Process Specifications continued


PROCESS

1.1.2

PROCESS

1.1.1

PROCESS

1.1.3

STORE-A

PSpec 1.1.1

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PSpec 1.1.3

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PSpec 1.1.2

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

PSpecs are functional primitives typically containing aprecise description of just one function that the system is required to perform.

All of the PSpecs together must contain an unambiguousspecification of all of the functional requirements ofthe system.

PSpecs typically occurlower down in the DFDstructure.


Writing Process SpecificationsDescribe functionality within PSpecs using● Structured Language

● Restricted set of English (Japanese, Korean, Indian etc.) verbs.

● Sequence, Selection, Iteration constructs● Mathematical Equations and Identities

● Algebraic expressions● Standard mathematical notation

● Decision Tables/Trees● For simplification of complex decision

making processes.● Graphs and Charts

● Expressing properties/relationships


Structured Language Guidelines– Choose a restricted set of suitable verbs.

• Preferable to select a set of action words with which the customer/user is familiar.

• When possible, obtain these verbs from the original requirements document (such as the OCD).

• Ensure that all such terms are used consistently.• Create a glossary try and limit it to less than 100

terms.• Avoid using imprecise verbs or generalised entity

names.– Construct simple rather than compound sentences.

• Simple sentences are more succinct and less ambiguous than compound ones.

• Use mathematical notation freely.• Restrict object/subject of a simple sentence to (data)

I/O or any necessary local terms.


Structured Language Guidelines continuedInclude sequence, selection & iteration constructs.– Sequence

● The natural order of statements (sentences) within a PSpec.

● A PSpec should be read from top to bottom.

– SelectionIF THEN ELSECASE (WHEN) DO

– IterationREPEAT UNTILDO WHILE


Structured Language Guidelines continued– Develop preconditions by isolating the following

• Necessary availability of particular inputs.• Relationships between (fields of) different inputs or

conditions of elements within an input.• Relationships between (fields of) inputs and elements of

(data) stores.• Relationships between (elements of) different stores or

conditions of elements within a store– Develop postconditions by isolating the following

• Particular outputs that will be generated from the PSpec.• Relationships between output values and input values.• Relationships between output values and values (of

elements) in stores with which the process communicates.• Alterations to stores (Additions, Modifications, Deletions).


Process Specification (PSpec) Examples

TakeCustomer

Order

2

Order

Standard Menu

AcceptedOrder

Customer Orders

NAME: Take Customer OrderI/O: Order: input

Standard Menu: inputAccepted Order: output

Assumptions:• Standard Menu is available to customer(s).• Customer(s) at a single table has indicated readiness to order.

Description:Repeat until all customers at table have madetheir (individual) Order:

Obtain from each customer or a representative:The type of pizza (s)he wants to order

Record in writing as Pizza OrderThe type of beverage (s)he wants to order

Record in writing as Beverage Order.

Verify Order against the Standard Menu.Record the table number (or it’s position) togetherwith customer Order(s) and place with other Customer Orders as an Accepted Order.

What is wrong with this PSpec?

Can it be improved?

This maybe a first attempt atwriting a process specification.


PSpec Examples continued


Standard Menu: inputAccepted Order: output


Description:Repeat until all customers at table have madetheir (individual) Order:

Obtain from each customer or a representative:The type of pizza (s)he wants to order

Record in writing as Pizza OrderThe type of beverage (s)he wants to order

Record in writing as Beverage Order.

Verify Order against the Standard Menu.Record the table number (or it’s position) togetherwith customer Order(s) and place with other Customer Orders as an Accepted Order.

This part of the PSpec isconfusing & ambiguous.Here it would seem thatthe pizza & beverage orderare merely an output.The DD definition for Ordersuggests otherwise.

Including some preconditions in this way is very helpful.

?

?

Are these the onlyinputs & outputs?

Where from?


PSpec Examples continuedNAME: Take Customer OrderI/O: Order: input

Standard Menu: inputTable Identity: inputAccepted Order: output


Description:For each customer at a table, obtain and record inwriting:

an Order consisting of:an (individual) Pizza Order and/oran (individual) Beverage Order

Verify Order against Standard Menu.

Produce the Accepted Order by recording theTable Identity together with all the verified(individual) customer Order(s) from the table.Place Accepted Order with other Customer Orders.

This attempt is better.

Can this PSpec beimproved further?

TakeCustomer

Order

2

Order

Standard Menu

AcceptedOrder

Table_Identity

TABLE_IDENTITIES Customer Orders




Standard Menu: inputTable Identity: inputAccepted Order: output


Description:For each customer at a table, obtain and record in writing:



Produce the Accepted Order by recording theTable Identity together with all the verified(individual) customer Order(s) from the table.Place Accepted Order with other Customer Orders.

Remember:• Write succinct sentences• Make specifications technology

free.• To use DD notation

Ambiguity and impliedtechnology!

The circled word supportsan implied technology.

The underlined wordingcan be replaced with DDnotational constructs.

The underlined wordingcan be reduced withoutloss of meaning.



NAME: Take Customer Order

I/O: Order: inputStandard Menu: inputTable Identity: inputAccepted Order: output

Assumptions:-• Standard Menu is available to customer(s).• Customer(s) at a single table is/are ready to order.

Description:For each customer at a table, obtain and record:



Produce Accepted Order as a record of Table Identity + {Order}.Store Accepted Order with other Customer Orders.



AssemblePizza

1.6

ChoppedVegetables

SlicedSalami

AssembledPizza

GratedCheesePizza

Base

NAME: Assemble Pizza

I/O: Pizza Base: inputChopped Vegetables: inputGrated Cheese: inputSliced Salami: inputAssembled Pizza: output

Description:Lay the Pizza Base flat.

Produce Assembled Pizza by arranging the variousingredients on the Pizza Base as follows:

Spread <Chopped>Tomato evenly (on Pizza Base);Sprinkle Grated Cheese evenly (on Pizza Base);

If other Chopped Vegetables are availablethen spread them evenly (on Pizza Base)

Place Sliced Salami (on Pizza Base) such that slicesdo not overlap.

Formulate PSpecs such thatthe functionality described isapplicable to a particularcategory of objects.

The description in this PSpecis applicable to all types ofpizza assembled within thecontext of this enterprise.



IssueBill

4

Customer_Orders Standard_Menu

AcceptedOrder

Prices

Bill

NAME: Issue Bill

I/O: Prices: inputAccepted Order: inputBill: output

Assumption:A bill for Accepted Order has not alreadybeen issued.

Description:Fetch Accepted Order from Customer Orders.

For each Order within Accepted Order:Extract Prices from the Standard Menu.Calculate the Total Price.Record the Total Price (with the Order).

Calculate the Total Amount as � (Total Price).Construct Bill as a record of:

{Order + Total price} + Total Amount.Issue Bill as part of Delivered Order forTable Number shown on Accepted Order.


Process Specifications

REMEMBER!!

Process Specifications are NOT PROGRAMS

Structured Language should be chosen appropriately for the particular system being specified


PSpecs as Decision Tables/Decision Trees

Input-1 Input-3Input-2 Result-1 Result-2 Result-3

Value-1

Value-2

Value-3

Value-1Value-1

Value-1Value-1

Value-2Value-2

Value-1Value-3

Value-2 Value-1 Value-2

Value-1

X

X

X

X

X

– When written descriptions become too difficult to follow because of complex decision logic then use a Decision Table/Tree to express the logic more clearly.

– Decision Tables/Trees are constructed when various combinations of inputs to a decision making process result in differing actions.


Decision table exampleWRITTEN DESCRIPTION

If Credit_Limit is not exceededthen

Allow Creditelse (Credit_Limit is exceeded)

If Payment_History is badthen

Refuse Creditelse if Payment_History is good

and Purchase < $100then

Allow Creditelse

Refer to Manager

Credit_Limit is exceeded

Payment_Historyis good

Purchase < $100

Y NY Y Y

Y Y Y Y

Y Y Y Y

X

N N N

N N N N

N N N N

Allow Credit

Refer to Manager

Refuse Credit

X

X X

X X X X

DT inputs and their combined valueswhich determine resulting action

DT outputs as actions resultingfrom combinational values of inputs


Decision Tree example

Credit_Limit Payment_History Payment < $100 Credit_Decision

exceeded

not exceeded

good

bad

yes

no

Allow

Refuse

Refer toManagement

Allow


Process Specification Summary

• PSpecs are the most important component of the DeMarco Model.• There is no advantage in trivialising PSpecs.• Be prepared to write and rewrite PSpecs in order

to reduce the possibility of misinterpretation and the consequent introduction of errors.• Sometimes it is worthwhile writing the equivalent

of PSpecs for every process bubble this leads to good abstraction.• Use of formal specifications in PSpecs is

worthwhile.

Date post:	02-Nov-2014
Category:	Documents
Upload:	deepanshu-rawat
View:	17 times
Download:	1 times

Process Modeling

Documents