Documenting Systems Using Dataflow Diagrams
Total Page：16
File Type：pdf, Size：1020Kb
Dataflow Diagrams – Documentation Guide
General Rules:
Professional Teams developing systems produce details and complete document in all areas covered.
The period involved in SAD means that you may not be able to document in the details required. In particular the detail required for the data dictionary. It is important to convey all the important datastores and process descriptors.
Try to provide the important parts of the DFD components.
View the different styles portrayed in the guides and samples. Try and pick out areas that enhance your report.
Ultimately it takes several years to produce a sufficient DFD library which can be utilized whenever building new systems.
Technical or bulky material should be moved to the appendix.
Web based or small scale systems may not need the level of details in the data dictionary section.
Larger systems - most of the detailed material should be moved to the appendix so as not to divert the reader from the general theme of your system report.
Make a professional judgment.
Documenting in details helps maintain standards and procedures particularly when there are a number of people working on developing the system.
Section indicated in red need to be added. Example: A Toy Sales Order Entry & Processing System
Below is the typical documentation (requirements specifications) for a toy sales order entry processing system and are not based this toy system on any real-world accounting system. The specification provided is only a sub-section of a complete system and therefore are incomplete. They are given as illustrations only. They consist of:
Context diagram Levelled logical dataflow diagrams Relation specifications for a Relational Database Specifications for the dataflows Process descriptions in raw prolog code. (Prolog is a relational language. The code is given here, since prolog code is generally easily grasped). The code given here, with very minor changes, should be executable.
“We are talking about a very small firm that considers orders from customers for one item. You should be able to add a lot more to the model provided as you wish. The situation considered is rather unrealistic, but it makes important points about specifications for an accounting system and its documentation.
NOTE : Sample Style Content Page
Section Description Page 1 Dataflow Diagrams: 1.1 Context Diagram: (Sales Order Entry & Processing System) 1.2 Events List: (Sales Order Entry & Processing System) 1.3 Level 0 Logical Dataflow Diagram: 1.3.1 Sales Order Entry & Processing System 1.4 Level 1 Logical Dataflow Diagram: 1.4.1 Sales Order Entry Sub-system 1.4.2 Sales Order Processing Sub-system 2. DATA DICTIONARY 2.1 Datastore List: 2.2 Dataflow Specifications 2.3 Process Specifications: 2.4 Example of Mini Spec (related code). 1 Dataflow Diagrams:
1.1 Context Diagram: (Sales Order Entry & Processing System)
Figure: Context Diagram
1.2 Events List: (Sales Order Entry & Processing System)
1.3 Level 0 Logical Dataflow Diagram:
1.3.1 Sales Order Entry & Processing System
1.4 Level 1 Logical Dataflow Diagram:
1.4.1 Sales Order Entry Sub-system
1.4.2 Sales Order Processing Sub-system
Figure: Level 1 Dataflow Diagram (Sales Order Processing Subsystem) 2. DATA DICTIONARY (part 1)
2.1 Datastore List:
Syntax: tableName(attribute1, attribute2,...... )
2.1.1
salesorder(CustomerName, CustomerAddress, Item, Quantity, ….)
priceList(Item, Price)
customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit)
inventoryMaster(Item, QuantityOnHand)
salesOrderMaster(CustomerName, Item, Quantity, OrderPrice)
billOfLading(CustomerName, Item, Quantity)
openInvoices(CustomerName, Item, Quantity, OrderPrice)
customer(CustomerName, CustomerAddress)
Optional - Datastore Specifications found in Appendix X1:
NOTE : Datastores are used to develop the table requirements of the system. Each datastore may generate several related tables. 2.2 Dataflow Specifications
Syntax: dataflowName(attribute1, attribute2,.....)
2.2.1
order(CustomerName, CustomerAddress, Item, Quantity)
pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
weDontSell(CustomerName, CustomerAddress, Item)
sorryBadCredit(CustomerName, CustomerAddress)
approvedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
sorryNotInStock(CustomerName, CustomerAddress, Item)
acceptedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
billOfLading(CustomerName, CustomerAddress, Item, Quantity)
invoice(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
Optional - Dataflow Specifications found in Appendix X2:
NOTE : Dataflows are used to develop the data entry forms and output forms required by the system. Each dataflow will require its own form view. 2.3 Process Specifications:
2.3.1
Process Specifications found in Appendix X3:
NOTE : Process descriptions are used to develop validation rules, macros, functions or code required by the system. Each process will require its own description.
2.4 Data Structure and Elements:
Example of Mini Spec (related code).
MINI SPEC – PRICE ORDER
2.3.1
priceOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)
/* Orders are priced by multiplying the quantity ordered by the price for the item on the price list */ if order(CustomerName, CustomerAddress, Item, Quantity), priceList(Item, Price), orderPrice is Price * Quantity.
/* We don't sell the item ordered by the customer if such item is not on the price list */ weDontSell(CustomerName, CustomerAddress, Item) if order(CustomerName, CustomerAddress, Item, Quantity), not priceList(Item, - ). /* A customer order for an item is approved if the order is priced and the account balance after the order is less than the credit limit */ approvedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) if pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice), customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit), NewBalance is Balance + OrderPrice, NewBalance < CreditLimit.
/* A customer order is rejected on account of bad credit if the order is priced and the account balance after the order exceeds the credit limit for the customer */ sorryBadCredit(CustomerName, CustomerAddress) if pricedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice), customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit), NewBalance is Balance + OrderPrice, NewBalance >= CreditLimit.
/* A customer order is accepted if it is approved and the quantity on hand of the item ordered is at least as much as the quantity ordered */ acceptedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) if approvedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice), inventoryMaster(Item, QuantityOnHand), QuantityOnHand >= Quantity.
/* A sales order is prepared if a customer order is accepted */ salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice) if acceptedOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice),
/* A bill of lading is prepared if a sales order is prepared */ billOfLading(CustomerName, CustomerAddress, Item, Quantity) if salesOrder(CustomerName, CustomerAddress, Item, Quantity, OrderPrice).
/* An open invoice is prepared if a bill of lading is prepared */ openInvoices(CustomerName, Item, Quantity, OrderPrice) if billOfLading(CustomerName, CustomerAddress, Item, Quantity).
/* A customer's account is updated by adding the order price to the current balance in the account if open invoice is prepared */ updateCustomerAccountsForInvoices if openInvoices(CustomerName, Item, Quantity, OrderPrice), retract(customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit)), NewBalance is Balance + OrderPrice, assert(customerMaster(CustomerName, CustomerAddress, NewBalance, CreditLimit)). DOCUMENTING DATA DICTIONARY (part 2)
When documenting the Data Dictionary Structures and Elements try to utilize some of the following style.
1. DATA DICTIONARY
Provide an overview or a lookup table for datastore, dataflow and process descriptors.
1.1. Data Store Descriptors
1.1.1. orders
2
Content: ORDERS = {ORDER} Description: **the orders for books placed by customers Inputs: 1.1 Log Order Outputs: 1.2 Check Stock Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly status: Disk / Paper ledger / Written Report
1.1.2. stocks
3
Content: STOCKS = {STOCK} Description: **the books the company retails 1.2 Check Stock Inputs: 1.4 Update Stock 1.2 Check Stock Outputs: 1.5 Check Pending Orders Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly status: Disk / Paper ledger / Written Report Follow suit with all remaining datastores. Hyperlink the data store structures to the entry in 1.3 Data Structures for the list of data attributes.
1.2. Data Flow Descriptors
1.2.1. order
Name:
Content: date+@order#+CUSTOMERDETAIL+1{OITEM} Description: an order placed by a customer Source: Process Data Store 1.1 Log Order 1 Orders
Destination: Process Data Store 1.2 Check Stock 1 Orders
Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly status: Disk / Paper ledger / Written Report
1.2.2. stock
Name:
Content: @isbn+title+AUTHOR+cost+sale+SUPPLIER+level Description: Source: Process Data Store incomplete incomplete
Destination: Process Data Store incomplete incomplete
Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly status: Disk / Paper ledger / Written Report 1.2.3. customer
Name:
Content: @customer#+CUSTOMERDETAIL+creditlevel Description: Source: Process Data Store Incomplete incomplete
Destination: Process Data Store incomplete incomplete
Read: Live / daily / weekly / monthly Write: Live / daily / weekly / monthly status: Disk / Paper ledger / Written Report
Follow suit with all remaining dataflows.
1.3. Data Structures:
Data Structures: General Description ADDRESS house#+street+town+county+postcode AUTHOR fname+sname CUSTOMERDETAIL nametitle+sname+fname+ADDRESS+tel+fax+email OITEM title+qty SUPPLIER sname+ADDRESS
Follow suit with all remaining data structures.
1.4. Data Elements
Data Elements: Cost currency £ County 1{char}20 usually from [A..Z|a..z|0..9| ,-] Cate date dd/mm/yy Fname 1{char}20 house# 1{char}3 usually numeric but can from from subset [0..9|A..Z|a..z] Isbn 10{char}10 format #-######-##-# where each # = [0..9] level integer minimum value 0 Nametitle 2{char}4 [Mr|Mrs|Ms|Miss|Dr|Prof] order# 1{char}4 numeric characters each [0...9] Postcode 7{char}7 format $$# %$$ where $=[A..Z] #=[1..99] and %=[0..9] Qty integer minimum value 1 sale currency £ Sname 1{char}30 Street 1{char}20 usually from [A..Z|a..z|0..9| ,-] Title 1{char}20 usually from [A..Z|a..z|0..9| ,-] Town 1{char}20 usually from [A..Z|a..z|0..9| ,-]
Follow suit with all remaining data elements.
1.5. Process Descriptors
Provide all process descriptors as follows.
DATA DICTIONARY: PROCESS DESCRIPTORS
2.1 match stock and order item
Name:
Description: validating that order lines can be met from present stock dataflow new order from data store 1. new orders. Data Inputs: dataflow stock order from data store 2. stocks. dataflow complete order to process 2.2 record sale dataflow noofitems to process 2.3 deduct stock Data Outputs: dataflow incompleteorder to process 2.4 create pending order dataflow itemdetails to process 2.5 create purchase order Variables: Mini-Spec: REPEAT GET next ORDERITEM IF MATCH ORDERITEM.title with any STOCKCARD.title IF STOCKCARD.level