COMP3110/6311

COMP3110/6311 ModelingProcesseswithDataFlowModels

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide1 [Link]&DrCliveBoughtonSlide1

ProcessModeling
WewilladoptelementsofStructuredAnalysisand Designtomodelprocesses DataFlowDiagrams
Toshowtheflowofdatathroughprocesses

DataDictionary
Thatcontainsdefinitionsofdatatogetherwithaccuracy, unitsofmeasure,rangeetc.

StructuredLanguage
Todescribeprocessesusingaconcisesetoftermsthat enhanceclarityandunderstanding. Alsomayinclude,equations,tables,charts&diagrams.

DecisionTablesand/orTrees
Toclearlyindicatedecisionprocessingwhenlanguage becomestooconvolutedordifficulttofollow.
COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams DrCliveBoughtonSlide2

DataFlowDiagrams(DFD)

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide3

DFDElements
PROCESS

Identifyprocessesthattransforminputdataintooutput data Mechanical,humanorsoftwarefunctionality Processesshouldbenamedwithashortactionclause

DATAFLOWS

Dataflowsindicatethecontentanddirectionofflowof information(ormaterials)toandfromprocesses,stores andterminators. Treatthemaspipelinesalongwhichsingleorgroupsof data/materialitemsofknowncontentandnaturecanflow. Theirnamesreflecttheircontentnounsoradjectives. Theydonotcontainorrepresentdynamicbehaviourno verbalnames.

DrCliveBoughtonSlide4

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DFDElements
STORE

Storesrepresentdataflowsthatarefrozenforan indeterminatetime. Theinformation/materialstheyrepresentcanbe accessedatanytimeandinanyorder. Nounsand/oradjectivesshouldbeusedsometimes plural.

TERMINATOR

Terminatorsrepresentthingsthatareexternaltothe system,butwhichareimportantbecausetheyprovide &/orreceivesysteminputandoutput.

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide5

Aprimitivenetwork

External Entity

Primitive Process

Data Flow

Internal Store
COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams DrCliveBoughtonSlide6

DataFlowDiagramDecomposition
SYSTEM CONTEXT Actuator
2

MAJOR PROCESSES OR SUBSYSTEMS

OUTPUT Software Package

0

Human

PROCESS

PROCESS STORE-A INPUT INPUT-A

3 4

THE SYSTEM

PROCESS

Sensor

Physical Environment

INPUT-B

PROCESS INPUT-AA INPUT-AB

1.1.1

OUTPUT

Data Dictionary
1.2

1.1.2

INPUT-AA INPUT-A
1.1

PROCESS

PROCESS

PROCESS

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

PROCESS
1.1.3

NOTE:

STORE-A

PROCESS

STORE-B

1.3

PROCESS SUBPROCESSES OF PROCESS 1.1 SUBPROCESSES OF PROCESS 1

Inputs&OutputsBALANCE. DataflowsCANBE GROUPED. DataflowsMAYBESPLIT. StoresCANBE DUPLICATED. UNIQUEProcess NUMBERING. Dataflows/StoresDEFINEDIN DD.

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide7

ContentsofaSetofDFDsforaSystem
Areadablesummaryofwhatissupposedtobe done. Dataflows&Storeswhicharefullydefinedinthe DataDictionary. Processanddataflowtypethatislargely determinedbythescopeoftheproblemtobe analysed. Terminatorsusuallyshownonlyatthe contextlevel,butmaybealsoshownatother levelsforconvenience. Defersissuesconcernedwithinitialisationand terminationassumessteadystateoperationof thesystem. Omissionofprocessingoftrivialerrors.
COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams DrCliveBoughtonSlide8

ExampleMakeaPizza
Tomatoes Hot Pepper Milk

Salami Mushrooms Cheese Onions Capsicum Flour Make Pizza Pizza

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide9

MakeaPizzaMoreDetail
Makingapizzarequiresseveralseparateactivities, allofwhichcanbedoneconcurrently,onebyone innoparticularorder,orseveralattheonetime.
Cheese Flour
1.2
Hot Pepper

Milk
1.1

Tomatoes Salami Mushrooms Cheese Onions

Milk

Mushrooms

Capsicum

Prepare Pizza Base Pizza Base

Grate Cheese

Make Pizza

Pizza

Onions Hot Pepper

1.3

Grated Cheese
1.6

Chop Vegetables

Flour

Chopped Vegetables

Capsicum

Assemble Pizza Assembled Pizza Sliced Salami

1.5

Tomatoes
1.4

Slice Salami Salami Pizza

Cook Pizza

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide10

CharacteristicsofDFDs
Dataflows are not process activators. View dataflows as pipelines over which materials/information move.
Flour Cheese Milk
1.2 1.1

Name dataflows by substance & characteristic.

Tomatoes Salami Mushrooms Cheese Onions

Hot Pepper

Milk

Mushrooms

Capsicum

Prepare Pizza Base Pizza Base

Grate Cheese

Make Pizza

Pizza

Onions Hot Pepper

1.3

Grated Cheese
1.6

Chop Vegetables

Chopped Vegetables

Flour

Assemble Pizza Assembled Pizza Sliced Salami

1.5

Capsicum

Tomatoes

Name processes in terms of transforming inputs into outputs.

Salami

1.4

Slice Salami

Cook Pizza Pizza

Dataflows do not represent control.

Dataflows must be relevant to process.

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide11

DataflowGrouping
Pizza Base Ingredients Cheese

Dataflows are best grouped when they have the same class or temporal characteristics.
Pizza Base Ingredients

1.2

Prepare Pizza Base Pizza Base

1.3 1.6

1.1

Grate Cheese

Vegetables
Pizza

Grated Cheese

Make Pizza Toppings

Chop Vegetables

Chopped Vegetables

Assemble Pizza Assembled Pizza Sliced Salami

1.5

1.4

Slice Salami Salami

Cook Pizza Pizza

DDEs:Pizza Base Ingredients = Flour + Milk Toppings = Vegetables + Cheese + Salami Vegetables = Tomatoes + Capsicum + Mushrooms + Hot Pepper + Onions

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide12

DataflowandProcessAbstraction
Apply proper abstraction to dataflow groupings as well as functional groupings. Avoid the ad hoc.
Pizza Base Ingredients
1.2
Pizza Base Ingredients

Cheese

Prepare Pizza Base

Pizza

1.1

Grate Cheese Pizza Base

Make Pizza Ingredients

Vegetables
1.3

Grated Cheese
1.6

Coffee Beans Sugar

Chop Vegetables

Chopped Vegetables

Assemble Pizza Assembled Pizza

1.7

Good dataflow grouping begets good functional grouping & vice-versa.

Make Coffee Water

Coffee

1.4

Sliced Salami
1.5

Slice Salami Salami Pizza

Cook Pizza

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

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide13

DosandDon'tsofDFDs
Bill Amount

Accept Payment
Payment

Over Payment Under Payment

Dont show possible outcomes of a process as split data flows.

Bill Amount

Do label data flows according to content and define any possible outcomes in the data dictionary.
Accepted Payment

Accept Payment
Payment

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

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide14

DosandDon'tsofDFDscontinued
Bill Amount Payment < Bill Amount

Accept Payment
Payment

Payment = Bill Amount

Dont show control processing on data flows.

Payment > Bill Amount

Bill Amount

Do label data flows according to content and show control processing inside functional primitives with outcomes defined in the data dictionary.
Accepted Payment

Accept Payment
Payment

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

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide15

DosandDon'tsofDFDscontinued
Dont loop Do describe iterative processing within functional primitives.

Vegetables

1.3
Chop Vegetables

Chopped Vegetables

Vegetables

1.3
Chop Vegetables

Chopped Vegetables

Vegetable Order

Vegetable Order Request

Vegetable Order

1.7
Get Next Order Next Vegetable Order Vegetables

Customer Orders

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 together and pass them on;

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide16

DosandDon'tsofDFDscontinued
Dont use dataflows as Process activation signals
Customer Request
2

Do describe control events within functional primitives.

Take Customer Order

Accepted Order

Take Customer Order

Accepted Order

Order Standard Menu

Order Standard Menu

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/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide17

DosandDon'tsofDFDscontinued

DontdrawtoomanyprocessbubblesonaDFD
UsetheMillerFactor(7plus/minus2)wisely Toomanybubblesmayindicate: Toolittlecomposition. Systemistoolarge.

DontdrawtoomanytrivialDFDs

DodrawDFDsthatcontainahighdegreeof functionalabstraction

LotsofDFDswithonlyafewbubblesmayindicate: Toomuchpartitioning Averysmallsystem

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide18

DeMarcoconventionsforDataStoreAccess
PROCESS

READ ONLY
STORE

PROCESS

READ AND THEN WRITE

STORE

PROCESS

UPDATE (NET FLOW)

STORE

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide19

EssentialEnvironment

FOOD STORAGE Ingredients

System Context
0

MANAGE PIZZA BAR Payment Delivered Order Order

Shows essential external entities with which the system (isolated as a single process) must communicate information or material items.

Yourdon refers to the Context Diagram as the Environmental Model.

CUSTOMER

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide20

EssentialBehavior
Pizza Base Ingredients Payment Toppings
5

Customer Orders

Standard Menu Prices

4

Accepted Order

Make Pizza Pizza Bill

Accept Payment Accepted Payment Cash Register Pizza Order

Issue Bill

Delivered Order Customer Orders Beverage

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

Take Customer Order

Accepted Order

Beverage Order
3

DFD-0
Prepare Beverage

Order Standard Menu Beverage Ingredients

Shows major essential processes that must be performed by the system on the inputs/outputs received/produced by the external environment.

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide21

DataDictionary(DD)

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide22

TheDataDictionaryPurpose

Maintainanorderedlistofrigorous definitionsfor:

DataFlowsandDataStores ElementarycomponentsofDataFlowsandStores DataStoreRelationships Name(includingaliases) Descriptionofmeaning(usuallyascommentary) Dataattributes(valuerange,units,rate,accuracy) Composition(groupedorprimitive)

DrCliveBoughtonSlide23

Definitionsshouldinclude:

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DataDictionarySummary

TheDDshouldcontainadefinitionforevery DataFlowandDataStoreshownontheset ofDFDs. AllknownpropertiesofeachDataFlowand DataStoreshouldbeincludedwithits dictionarydefinition. ConstructingtheDDisessentialtocreatinga specificationthathasthepropertiesofbeing consistentandunambiguous. DDconstructioncanbetedioussoitis importanttoadoptanincrementalapproach.
DrCliveBoughtonSlide24

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

ProcessSpecifications(PSpec)

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide25

ProcessSpecificationsPurpose

Todescribewhataprimitiveprocessmust accomplish. Descriptionsmustexplainwhathastobe doneto(data)inputsinordertoproduce theresultant(data)outputs. Statementsmustbe

Readable Verifiable Understandable Precise Succinct
DrCliveBoughtonSlide26

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

ProcessSpecifications&DFDs
SYSTEM CONTEXT Actuator
2

MAJOR PROCESSES OR SUBSYSTEMS

OUTPUT Software Package

0

Human

PROCESS

PROCESS STORE-A INPUT INPUT-A

3 4

THE SYSTEM

PROCESS

Sensor

Physical Environment

INPUT-B

PROCESS INPUT-AA INPUT-AB

1.1.1

OUTPUT

1.1.2

INPUT-AA INPUT-A
1.1 1.2

PROCESS

PROCESS

PROCESS

PROCESS
1.1.3

TheDFDstructure

STORE-A

PROCESS

STORE-B

1.3

ISNOTaspecification. ISalogicallayout.

PROCESS SUBPROCESSES OF PROCESS 1.1 SUBPROCESSES OF PROCESS 1

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide27

ProcessSpecifications(PSpec)
MAJOR PROCESSES OR SUBSYSTEMS
2

PROCESS

A PSpec can occur anywhere within the DFD structure.

PROCESS STORE-A

PROCESS
3

Process Specification NAME: (Data) I/O: Description:

PROCESS

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

Textual Graphical Tabular Mathematical

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide28

ProcessSpecificationscontinued
All of the PSpecs together must contain an unambiguous specification of all of the functional requirements of the system. PSpec 1.1.2 ~~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~

PSpec 1.1.1 ~~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~

1.1.2 1.1.1

PROCESS

PROCESS

PSpecs typically occur lower down in the DFD structure.

1.1.3

STORE-A

PROCESS

PSpec 1.1.3
SUBPROCESSES OF PROCESS 1.1

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

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

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide29

WritingProcessSpecifications
DescribefunctionalitywithinPSpecsusing StructuredLanguage RestrictedsetofEnglish(Japanese, Korean,Indianetc.)verbs. Sequence,Selection,Iterationconstructs MathematicalEquationsandIdentities Algebraicexpressions Standardmathematicalnotation DecisionTables/Trees Forsimplificationofcomplexdecision makingprocesses. GraphsandCharts Expressingproperties/relationships

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide30

StructuredLanguageGuidelines
Choosearestrictedsetofsuitableverbs.

Constructsimpleratherthancompoundsentences.

Preferabletoselectasetofactionwordswithwhich thecustomer/userisfamiliar. Whenpossible,obtaintheseverbsfromtheoriginal requirementsdocument(suchastheOCD). Ensurethatallsuchtermsareusedconsistently. Createaglossarytryandlimitittolessthan100 terms. Avoidusingimpreciseverbsorgeneralisedentity names.

Simplesentencesaremoresuccinctandless ambiguousthancompoundones. Usemathematicalnotationfreely. Restrictobject/subjectofasimplesentenceto(data) I/Ooranynecessarylocalterms.

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide31

StructuredLanguageGuidelinescontinued
Includesequence,selection&iteration constructs. Sequence Thenaturalorderofstatements (sentences)withinaPSpec. APSpecshouldbereadfromtopto bottom. Selection
IFTHENELSE CASE(WHEN)DO REPEATUNTIL DOWHILE

Iteration

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide32

StructuredLanguageGuidelinescontinued
Developpreconditionsbyisolatingthefollowing

Developpostconditionsbyisolatingthefollowing

Necessaryavailabilityofparticularinputs. Relationshipsbetween(fieldsof)differentinputsor conditionsofelementswithinaninput. Relationshipsbetween(fieldsof)inputsandelementsof (data)stores. Relationshipsbetween(elementsof)differentstoresor conditionsofelementswithinastore

ParticularoutputsthatwillbegeneratedfromthePSpec. Relationshipsbetweenoutputvaluesandinputvalues. Relationshipsbetweenoutputvaluesandvalues(of elements)instoreswithwhichtheprocesscommunicates. Alterationstostores(Additions,Modifications,Deletions).

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide33

ProcessSpecification(PSpec)Examples
This maybe a first attempt at writing a process specification. NAME: I/O: TakeCustomerOrder Order: input StandardMenu: input AcceptedOrder: output Assumptions: StandardMenuisavailabletocustomer(s). Customer(s)atasingletablehasindicated readinesstoorder. Description: Repeatuntilallcustomersattablehavemade their(individual)Order: Obtainfromeachcustomerorarepresentative: Thetypeofpizza(s)hewantstoorder RecordinwritingasPizzaOrder Thetypeofbeverage(s)hewantstoorder RecordinwritingasBeverageOrder. VerifyOrderagainsttheStandardMenu. Recordthetablenumber(oritsposition)together withcustomerOrder(s)andplacewithother CustomerOrdersasanAcceptedOrder.

Customer Orders

Take Customer Order

Accepted Order

Order Standard Menu

What is wrong with this PSpec? Can it be improved?

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide34

PSpecExamplescontinued
NAME: I/O: TakeCustomerOrder Order: input StandardMenu: input AcceptedOrder: output Assumptions: StandardMenuisavailabletocustomer(s). Customer(s)atasingletablehasindicated readinesstoorder. Description: Repeatuntilallcustomersattablehavemade their(individual)Order: Obtainfromeachcustomerorarepresentative: Thetypeofpizza(s)hewantstoorder RecordinwritingasPizzaOrder Thetypeofbeverage(s)hewantstoorder RecordinwritingasBeverageOrder. VerifyOrderagainsttheStandardMenu. Recordthetablenumber(oritsposition)together withcustomerOrder(s)andplacewithother CustomerOrdersasanAcceptedOrder.

? ?

Are these the only inputs & outputs?

Including some preconditions in this way is very helpful. This part of the PSpec is confusing & ambiguous. Here it would seem that the pizza & beverage order are merely an output. The DD definition for Order suggests otherwise.

Where from?

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide35

PSpecExamplescontinued
This attempt is better. NAME: I/O: TakeCustomerOrder Order: input StandardMenu: input TableIdentity: input AcceptedOrder: output Assumptions: StandardMenuisavailabletocustomer(s). Customer(s)atasingletablehasindicated readinesstoorder. Description: Foreachcustomeratatable,obtainandrecordin writing: anOrderconsistingof: an(individual)PizzaOrderand/or an(individual)BeverageOrder VerifyOrderagainstStandardMenu. ProducetheAcceptedOrderbyrecordingthe TableIdentitytogetherwithalltheverified (individual)customerOrder(s)fromthetable. PlaceAcceptedOrderwithotherCustomerOrders.

TABLE_IDENTITIES Table_ Identity

2

Customer Orders

Take Customer Order

Accepted Order

Order Standard Menu

Can this PSpec be improved further?

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide36

PSpecExamplescontinued
NAME: I/O: TakeCustomerOrder Order: input StandardMenu: input TableIdentity: input AcceptedOrder: output Assumptions: StandardMenuisavailabletocustomer(s). Customer(s)atasingletablehasindicated readinesstoorder. Description: Foreachcustomeratatable,obtainandrecordinwriting: anOrderconsistingof: an(individual)PizzaOrderand/or an(individual)BeverageOrder VerifyOrderagainstStandardMenu. ProducetheAcceptedOrderbyrecordingthe TableIdentitytogetherwithalltheverified (individual)customerOrder(s)fromthetable. PlaceAcceptedOrderwithotherCustomerOrders. Remember: Writesuccinctsentences Makespecificationstechnology free. TouseDDnotation The underlined wording can be reduced without loss of meaning. Ambiguity and implied technology!

The underlined wording can be replaced with DD notational constructs. The circled word supports an implied technology.

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide37

PSpecExamplescontinued
NAME: I/O: Take Customer Order Order: Standard Menu: Table Identity: Accepted Order: input input input 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/or an (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/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide38

PSpecExamplescontinued
FormulatePSpecssuchthat thefunctionalitydescribedis applicabletoaparticular categoryofobjects. NAME: I/O: AssemblePizza PizzaBase: ChoppedVegetables: GratedCheese: SlicedSalami: AssembledPizza: input input input input output

Pizza Base
1.6

Grated Cheese

Description: LaythePizzaBaseflat. ProduceAssembledPizzabyarrangingthevarious ingredientsonthePizzaBaseasfollows:

Chopped Vegetables

Assemble Pizza Assembled Pizza

Sliced Salami

Spread<Chopped>Tomatoevenly(onPizzaBase); SprinkleGratedCheeseevenly(onPizzaBase); If then otherChoppedVegetablesareavailable spreadthemevenly(onPizzaBase)

ThedescriptioninthisPSpec isapplicabletoalltypesof pizzaassembledwithinthe contextofthisenterprise.

PlaceSlicedSalami(onPizzaBase)suchthatslices donotoverlap.

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide39

PSpecExamplescontinued
NAME: I/O: IssueBill Prices: AcceptedOrder: Bill: input input output

Customer_Orders

Standard_Menu Prices
4

Accepted Order

Assumption: AbillforAcceptedOrderhasnotalready beenissued. Description: FetchAcceptedOrderfromCustomerOrders. ForeachOrderwithinAcceptedOrder: ExtractPricesfromtheStandardMenu. CalculatetheTotalPrice. RecordtheTotalPrice(withtheOrder). CalculatetheTotalAmountas (TotalPrice). ConstructBillasarecordof: {Order+Totalprice}+TotalAmount. IssueBillaspartofDeliveredOrderfor TableNumbershownonAcceptedOrder.

Bill

Issue Bill

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide40

ProcessSpecifications

REMEMBER!!

Process Specifications are NOT PROGRAMS

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

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide41

PSpecsasDecisionTables/DecisionTrees
Whenwrittendescriptionsbecometoodifficultto followbecauseofcomplexdecisionlogicthen useaDecisionTable/Treetoexpressthelogic moreclearly. DecisionTables/Treesareconstructedwhen variouscombinationsofinputstoadecision makingprocessresultindifferingactions.

Input-1 Value-1 Value-1 Value-2 Value-2 Value-1

Input-2 Value-1 Value-2 Value-3 Value-1 Value-3

Input-3 Value-1 Value-1 Value-2 Value-2 Value-1

Result-1 X

Result-2

Result-3

X X X X

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide42

Decisiontableexample
WRITTEN DESCRIPTION If Credit_Limit is not exceeded then Allow Credit else (Credit_Limit is exceeded) If Payment_History is bad then Refuse Credit else if Payment_History is good and Purchase < $100 then Allow Credit else Refer to Manager

DT inputs and their combined values which determine resulting action Credit_Limit is exceeded Payment_History is good Purchase < $100 Allow Credit

Y Y Y X

Y Y

N N N N Y N N N Y X X

N N Y

N N Y

N Y X X

DT outputs as actions resulting from combinational values of inputs

Refuse Credit Refer to Manager X

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide43

DecisionTreeexample
Credit_Limit Payment_History Payment < $100 Credit_Decision

yes good no exceeded

Allow

Refer to Management

bad

Refuse

not exceeded

Allow

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide44

ProcessSpecificationSummary
PSpecsarethemostimportantcomponentofthe DeMarcoModel. ThereisnoadvantageintrivialisingPSpecs. BepreparedtowriteandrewritePSpecsinorder toreducethepossibilityofmisinterpretationand theconsequentintroductionoferrors. Sometimesitisworthwhilewritingtheequivalent ofPSpecsforeveryprocessbubblethisleadsto goodabstraction. UseofformalspecificationsinPSpecsis worthwhile.

COMP3110/6311StructuredAnalysis&DesignDataFlowDiagrams

DrCliveBoughtonSlide45