process modeling
DESCRIPTION
Process modellig in software engineeringTRANSCRIPT
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 2
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 3
Data Flow Diagrams (DFD)
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 4
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 5
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 6
A primitive network
ExternalEntity
PrimitiveProcess
InternalStore
DataFlow
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 7
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 8
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 9
Example – Make a Pizza
MakePizza
HotPepper
Tomatoes
Salami
Mushrooms
Cheese
Capsicum
Onions
Pizza
Flour
Milk
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 10
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 11
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 12
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
Pizza BaseIngredients
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 13
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
Pizza BaseIngredients
Vegetables
Make Coffee
1.7
CoffeeBeans
Sugar
Water
Coffee
MakePizza
1
Pizza BaseIngredients
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 14
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 15
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 16
Dos and Don'ts of DFDs continued
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 17
Dos and Don'ts of DFDs continued
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 18
Dos and Don'ts of DFDs continued
● 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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 19
De Marco conventions for Data Store Access
STORE
PROCESS
STORE
PROCESS
STORE
PROCESS
READ ONLY
READ AND THEN WRITE
UPDATE (NET FLOW)
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 20
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 21
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
Pizza BaseIngredients
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 22
Data Dictionary (DD)
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 23
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)
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 24
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 25
Process Specifications (PSpec)
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 26
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 27
Process Specifications & DFDs
The DFD structure
• IS NOT a specification.• IS a logical layout.
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 28
Process Specifications (PSpec)
Process Specification
NAME:
(Data) I/O:
Description:
TextualGraphicalTabularMathematical
MAJOR PROCESSESOR SUBSYSTEMS
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)
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 29
Process Specifications continued
SUBPROCESSES OF PROCESS 1.1
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 30
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 31
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 32
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 33
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).
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 34
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 35
PSpec Examples continued
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.
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?
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 36
PSpec Examples continuedNAME: Take Customer OrderI/O: Order: input
Standard Menu: inputTable Identity: inputAccepted Order: output
Assumptions:• Standard Menu is available to customer(s).• Customer(s) at a single table has indicated readiness to order.
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 37
PSpec Examples continued
NAME: Take Customer OrderI/O: Order: input
Standard Menu: inputTable Identity: inputAccepted Order: output
Assumptions:• Standard Menu is available to customer(s).• Customer(s) at a single table has indicated readiness to order.
Description:For each customer at a table, obtain and record in writing:
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.
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 38
PSpec Examples continued
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:
an Order consisting of:an (individual) Pizza Order and/oran (individual) Beverage Order
Verify Order against Standard Menu.
Produce Accepted Order as a record of Table Identity + {Order}.Store Accepted Order with other Customer Orders.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 39
PSpec Examples continued
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 40
PSpec Examples continued
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 41
Process Specifications
REMEMBER!!
Process Specifications are NOT PROGRAMS
Structured Language should be chosen appropriately for the particular system being specified
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 42
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.
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 43
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
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 44
Decision Tree example
Credit_Limit Payment_History Payment < $100 Credit_Decision
exceeded
not exceeded
good
bad
yes
no
Allow
Refuse
Refer toManagement
Allow
COMP3110/6311 Structured Analysis & Design – Data Flow Diagrams © Dr Clive Boughton Slide 45
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.