Data Flow Diagrams: more details. Recall: Specifications What are specs? Specs and UP. Brief Review: Specs. Things to recall about specs

Transcription

1 Data Flow Diagrams: more details Source: Bertrand Portier, IBM, Recall: Specifications What are specs? Why are they important? Today we look more carefully at: Data Flow Diagrams Used in Structured A way to specify But back to specs for a bit Specs and UP UP has requirements which includes specs UP also handles specs by iterative feedback Remember the diagram-drawing exercise? So UP doesn t go all out to put all detailed specs on a single paper document Remember the diagram-drawing exercise So why should we discuss specs at all? cuz they re important However they re done Whatever they re called Brief Review: Specs An early phase of a typical waterfall model De-stressed in UP RUP does have supplementary specifications artifact For example let s see a RUP diagram (I also noticed EUP and AUP diagrams on Web Enterprise Unified Process and Agile Unified Process They re of the same genre) Things to recall about specs Specs must be (per Schach) Understandable by a client Correct and detailed enough to lead to a correct product Remember the diagram-drawing exercise? "The specification document is a contract between client and developer" - (Schach, 5th ed. section 11.1, 4th section 10.1) Some things that can be in the specs (see next slide) 1

2 What s in Specs? "The specification document is a contract between client and developer" - (Schach, 5th ed. section 11.1, 4th section 10.1) Some things that can be in the specs (see next slide) delivery deadline reliability (e.g. frequency of crashes) acceptance criteria administrative specs functional specs What is systems analysis? An MIS term (MIS?) "A process followed to determine what the system does..." (Introduction to and Design, I. T. Hawryszkiewycz, Prentice Hall, 1994, p. 14.) "Once systems analysis is completed, system design commences." (Hawryszkiewycz) Definitions vary from source to source Clarity is important: More about specs "All dogs must be kept on a leash in the park" Some Definitions Definitions do vary from source to source Corresponds roughly to specs "Data flow diagrams (DFD) are widely used by systems analysts to graphically illustrate information systems." (C. Parker and T. Case, Management Information Systems, 1993, p. 90.) Data Flow Diagrams Used for specs but not using that term Used for systems analysis which are similar to specifications Since Data Flow discussions call it systems analysis, let s do that here too Another characterization "Data flow diagrams (DFD) are widely used by systems analysts to graphically illustrate information systems." - (C. Parker and T. Case, Management Information Systems, 1993, p. 90.) 2

3 What are DFDs like? DFD's are a "semi-formal" technique Techniques may be informal semi-formal formal informal - written documents semi-formal - based on graphical languages formal - math (e.g. Z) What is UML? The Four Building Blocks of a DFD Data Source or Destination (or "external entities" - Hawryskiewycz) Data Flow Data Transforming Process Data Store (part of the system, not an input or output) What is a method? Hard drive? Flash drive? Message? Web hyperlink? Using Data Flow Diagrams Make bubbles showing data stores, sources, and destinations, and transformers Make arrows showing data flows between stores, sources, destinations, and transformers (See e.g. Schach, 5th ed. Figures 11.1, 11.2, 4th ed and 10.2) Examples of the Four Building Blocks Let s take a retail sales example Data sources and destinations They are outside the system Ebay s sellers inventory descriptions Ebay s customers (which are which?) Anything else? a retail sales example Data flows an order a receipt Examples of the Four Building Blocks credit-worthiness of a customer an order a receipt credit-worthiness of a customer information about a product information about a product 3

4 Examples of the Four Building Blocks a retail sales example Data transformation processes square root function order processing software anything else? Please write down a transformation or two for later Examples of the Four Building Blocks a retail sales example Data stores What is the difference: Data stores, vs. data sources and destinations? Inventory database File of customer credit ratings? Customer addresses? Customer credit card numbers? Anything else? Connecting the Building Blocks Together (See e.g. Schach, Fig. 11.2, or 10.2 in 4th ed.) Make bubbles for data stores, sources, and destinations, and transformers Make arrows showing where data flows (among stores, sources, destinations, and transformers) Now redo it, simplifying as needed so there is just one transformer This is a basic Data Flow Diagram (DFD) Being semi-formal (semi-formal: using a welldefined graphical language) Let s look at the above things again, but this time let s draw symbols and label them (with the things) on the next slide Structured Systems Analysis Using DFD Do-it-yourself...in 9 easy steps! Step 1: Draw the basic DFD... then, elaborate more and more until "done"... resulting in a much more elaborate DFD (Later steps e.g. define the data structures to use) (So, systems analysis can include design) 4

5 Do a DFD, using Step 1 again: draw the basic DFD only one (1) transformation process (Later, elaborate more and more until "done" e.g. redraw it with more transformers) E.g. Schach Figs 11.3 & 11.4 (4th ed and 10.4) Result is a more detailed DFD Elaboration process is called leveling Building from the top level DFD (cont.) One part may be replaced by a more complex diagram Any part may be replaced (including data flows) This process can continue e.g. Fig (10.4 4th ed.) Number the elements in the base ( context ) diagram Now, take the transformer and replace it with more stuff (& draw a new DFD diagram) Number the new elements 4.1, 4.2, etc. if you replaced 4 The DFD can get quite large (much bigger than one 8 1/2 x 11 sheet of paper) The Top Level DFD - notes Recall: Top level DFD has One (1) data transformation process (rounded rectangle) Top level DFD is also called a context diagram What then? Building from the top level DFD (cont.) One part may be replaced by a more complex diagram Number the new elements 4.1, 4.2, etc. if you replaced 4 The DFD can get quite large But the process must eventually end Why? Building from the top level DFD What Next? Leveling: elaborate DFD until done "Elaborate" - provide details about; make more complex See Figure 11.3 (4th ed. 10.3) - parts of Fig correspond to sections of Fig Thus, one part may be replaced by a more complex diagram Building from the top level DFD (cont.) One part may be replaced by a more complex diagram But the process must eventually end Why? (otherwise the DFDs would get to the level of e.g. adding numbers) 5

6 "Leveling" of DFDs II Leveling: convert a DFD into a more detailed DFD Expand by using DFD to explain details of one block with more than one block includes replacing >1 block with more detailed blocks Start with the top level DFD Has one data transformation process Describe a process in English You could try it on an example How to Level Use the parts of the description to identify parts of the expansion Example: process is called "Process an Order" Description: "After getting the order from the customer, collect the payment and give a receipt, and package the order" Subprocesses might then be: Get order from customer, Process payment, Produce receipt for customer, Package product for customer (we could try an example) Make sure to number the parts Leveling process 5.3 yields processes 5.3.1, 5.3.2, etc. (You could try your own now ) "Leveling" of DFDs II Start with the top level DFD Has one data transformation process A primary leveling activity is to level a process (rounded rectangle) That s where the complexities tend to lie Give the high level boxes a number N Give its lower level constituent boxes numbers N.x # Step 2: Determine what to computerize Note that the DFD makes no assumptions about computerization # (E.g. a data store could be on dvd or in a pile of papers!) Example? The Lowest Level How detailed does it have to get? Point 1: The number scheme breaks down if you get too detailed (What use is section ??!) Point 2: Useless to model simple arithmetic operations (add, multiply, etc.) You could do it, but it would make the analysis less understandable, not more Step 3: Describe the data that flows in detail No need to write actual declarations though Example? 6

7 Step 4: Describe the processes Give the control flow, for example Use e.g. a decision tree, decision table, or flow chart Example? (consider the need for conditionals, such as for quantity discount) (If in doubt on example, go with the decision tree) Step 7: Describe I/O Input screens, printouts, etc. Could try an example Step 5: Describe the Data Stores Note that the DFD makes no assumptions about computerization! (E.g. a data store could be on dvd or in a pile of papers) Give data declaration, box names on a paper form, etc. (it's pretty close to declarations in actual code but not quite) Could try an example Step 8: Describe quantities Frequencies of reports How often data is input, how much data Could try an example or two Step 6: Describe the "Physical Resources" File names What kind of storage medium (disk, tape drive, paper...) File format Could try an example Do it now for something in your diagram Step 9: Hardware Requirements How big the hard disk must be How powerful the computer Could try an example 7

8 More Comments Name one step that's more like design than specs (Possible Supplementary Material) DFD's -- for Specs and Design Data Flow analysis deals with specs and design For specifications: Use "logical DFDs" For designs: Use "physical DFDs" See Hawryszkiewycz Fig 7.8 Exercise: For some of the DFD's we have seen/made: are their logical components there? are their physical components? Note: the specifications phase should use - logical DFDs, not physical DFDs How could a tool help make DFDs? 8