Requirements Modeling with Data Flow Diagrams CEN5016 Software Engineering © Dr. David A. Workman School of EE and CS University of Central Florida January 30, 2007

(c) Dr. David A. Workman2 Formal DFDs Symbol Vocabulary –External Interfaces: data portals defined at the system boundary; interfaces where external data enters or leaves the system.; used to define interfaces with other systems that supply or consume data transformed by the system being modeled –Processes (functions): functional nodes that transform data carried by in-flows into data defined by out-flows; no data flows or flow components pass thru unchanged –Stores: internal system data storage areas or devices; data enters and leaves unchanged. –Data Flows: conduits or channels or some other transport mechanism for data; composite or atomic “infopks.” External Interface Process Nodes Store sourcesink

January 30, 2007(c) Dr. David A. Workman3 Formal DFDs Context Diagram (Level - 0 DFD) The SYSTEM External Interface External Interface External Interface External Interface Level 0: McDonalds Restaurant See ‘Notes’ Page A B C D E F G

January 30, 2007(c) Dr. David A. Workman4 Formal DFDs Level 1: The first level System decomposition. Process 1.0 Process 2.0 Process 4.0 Process 5.0 Process 3.0 Store D C A B u v x y z = (x,y) r s t r = (s,t) F E G w See ‘Notes’ Page p z

January 30, 2007(c) Dr. David A. Workman5 Formal DFDs Level 2 : The first level System decomposition. Process 1.1 Process 1.2 Process 1.3 Process 1.5 Process 1.4 Store A B u y r 1.0 : Process Refinement Aua ua ub ubc ubd

January 30, 2007(c) Dr. David A. Workman6 Formal DFDs Level 0 (Context Diagram) Level Level 2

January 30, 2007(c) Dr. David A. Workman7 Formal DFDs External Interface Process Nodes Rule: External Interfaces MUST ONLY be connected (via flows) to Process Nodes. Store Process Nodes Process Nodes Rule: Stores can only connect to Process Nodes on the same diagram; the same process may store and retrieve data from a given store, but the producing and consuming processes may be different. Stores should be introduced on highest level diagram where they are needed. External Interface Store Process Nodes Process Nodes Rule: Process nodes can connect by data flows to other processes, stores, or external interfaces. Although the same Process node and some other given node can be connected by both in-flows and out-flows, these flows must transmit different data.

January 30, 2007(c) Dr. David A. Workman8 Formal DFDs PRINCIPLES –All in-flow data to a process must be transformed in some way. The label and composition of out-flows from a process must be distinct from any in-flows (and other out-flows). Out-flow labels should reflect the effect of the process that produced them (e.g. “in-flow: hungry customer out-flow: satisfied customer”) –Although technically permitted, if the only purpose of a process node is to repackage constituents of composite in-flows to form out-flows, then the following notation should be used. Process Nodes X X Not Permitted Splitting flows X a b Merging of flows X a b

January 30, 2007(c) Dr. David A. Workman9 Formal DFDs PRINCIPLES –The sum of all data flows entering a DFD, as defined by External Sources, must equal the sum of all data flows leaving a DFD, as defined by the External Sinks. The system defined by a DFD must not “add” information nor “delete” information - it only transforms it (and/or replicates it). –The sum of all data flow components entering a Process must equal the sum of the data flow components leaving a Process. This takes into account the fact that some data flows can be composite flows made up of more basic or primitive data elements. –Stores act as “buffers” or “repositories” of information. They do not alter data in any way. Once again, any data flowing into a Store must be retrievable without change from the Store as an out-flow, either as it was entered, or in the form of its components, ad in the case of composite in-flows. Component in-flows and composite out-flows are equally permissible. A Store should always have at least one in-flow and at least one out-flow. If this is not the case, then it probably should be modeled as an External Interface. –A DFD is complete and consistent if it is possible to track or traces every infopak that enters the System through an External Interface as part of an in-flow from its point of entry, through the Processes that manipulate it, and finally to the infopaks it has functionally affected as out-flows (or components of out-flows) leaving an External Interface.

January 30, 2007(c) Dr. David A. Workman10 Example: MacDonald’s MacDonald’s Restaurant (Customer Service) Dumpster Resturant Supplies Customers CONTEXT DIAGRAM Trash (consumed supplies) Supplies & Food Hungry Customers (with Money) Satiated Customers (with eaten Food and no Money) Bank Cash Receipts

January 30, 2007(c) Dr. David A. Workman11 Example: MacDonald’s Customers 1.0 Take Order Computer System New Food order 2.0 Deliver Order Clean Trays Prepared Food Drink Dispenser Receipt | Order status Order Queries Satisfied Customer Utensils Hungry Customer with Food Hungry Customer Processed Hungry Customer 3.0 Eat Food Trash Waste Bin Dirty Trays Used Tray 5.0 Dump Trash Open Full Bag Open Empty Bag Dumpster Tied Full Bag 4.0 Wash Trays Helper See ‘Notes’ Page Restaurant Supplies & Food Empty Bags Empty Bag Restaurant Supplies

January 30, 2007(c) Dr. David A. Workman12 Example: MacDonald’s Customers Take Order New Food order Deliver Order Clean Trays Order status Order Queries Satisfied Customer Hungry Customer with Tray of Food Hungry Customer Hungry Customer with Order# Eat Food Trash Dirty Trays Used Tray Dump Trash Open Full Bag Open Empty Bag Dumpster Tied Full Bag Wash Trays See ‘Notes’ Page Prepared Food Utinsels, Napkins Condiments, Drinks Supplies Empty Bag Fill Tash Bags Supplies Cooked items Computer Order Processing System

January 30, 2007(c) Dr. David A. Workman13 DFDs => OO Design Booch Methodology for Transforming DFDs into OO Design 1.External Interfaces become boundary objects in the OO Design 2.Data Flows become entity objects or object attributes in the OO Design 3.Stores are modeled as Container objects (perhaps single objects). 4.Process Bubbles at Level 1 are modeled as control objects. 5.Process Bubbles at levels > 1 are modeled as methods of some class.

Dynamic Behavior Specification with OO Control Flow Diagrams COP 4331 OO Processes for Software Systems Development © Dr. David A. Workman School of EE and CS University of Central Florida Revised: September 26, 2005

January 30, 2007(c) Dr. David A. Workman15 Hierarchical Flow of Control main A::One()A::Two()A::Three() B::One() C::One() B::Two() D::One() E::Two() E::One()D::Three() D::Two() Use Case #1 Use Case #3 Use Case #2

January 30, 2007(c) Dr. David A. Workman16 Example: Money Class Money Char sign Int dollars Int cents Money(); Money(ifstream&); Money(char,int,int); getSign():char getDollars():int; getCents():int; operator-() :Money; operator-(Money):Money; operator+(Money):Money; operator==(Money):bool; operator<(Money):bool; operator>(Money):bool; operator<=(Money):bool; operator>=(Money):bool; Extract(ifstream&)=>TokenError Insert(ostream&); operator>>(ifstream&,Money&) operator<<(ostream&,Money&) #Get(ifstream&) #Put(ostream&); -toInt(Money):int -toMoney(int):Money Money(fin) Extract(fin) Get(fin) Money() Money(char,int,int) getSign() getDollars() getCents() boolean operators() * binary operators() toInt(Money)toMoney(int) * Insert(fout) Put(fout) operator>>(fin) operator<<(fout) TokenError Initially make public

January 30, 2007(c) Dr. David A. Workman17 Example: Simulator – Part 1 Main() Conversation() Student:: Student() Players() Event() SpeakMsg() Conversation ::Initialize() Student ::Initialize() EventMgr ::postEvent() Student ::AcceptQuestion() Student ::NameOf() Players ::setAgent() Agent ::Get() Student ::Get() * * Players ::getAgent() Players ::getOther() Student ::NameOf() Players ::~Players() * ifstream:: >> string Student:: Extract() *

January 30, 2007(c) Dr. David A. Workman18 Example: Simulator – Part 2 Main() Conversation:: Simulate() Event:: <<() Agent:: Put() Student:: Put() Student:: Insert() Student:: Dispatch() Conversation:: PutState() EventMgr:: moreEvent() EventMgr:: getNextEvent() Event:: getRecvr() Event:: getMsg() Message:: ~Message() Conversation:: WrapUp() Conversation:: ~Conversation() Student:: ~Student() Agent:: <<() Message:: <<() Message:: Insert() Message:: Put() 2 Student:: AcceptAnswer() SpeakMsg:: getHandler() Student:: doAnswer() Student:: doQuestion() StringMsg() Event() EventMgr ::postEvent()