1. Data Flow Modelling II

2. Plan Introduction Structured Methods –Data Flow Modelling –Data Modelling –Relational Data Analysis Feasibility Maintenance

3. Ten Guidelines 1.Don’t expect to get it right first time – draw one to throw away* 2.Draw a Document Flow Diagram to establish the context 3.Check that you have identified all input and output document flows 4.Always draw a context diagram – it clarifies the context 5.Read through the system description noting candidate processes and data stores 6.Identify the External Entity that ‘starts’ the whole system process 7.Build the diagram one process at a time adding data stores as required 8.For each process identify the main output, all inputs and other outputs 9.For each process clearly mark any data flows that go to, or come from, nowhere 10.Once the processes are complete check through your work and tidy up loose ends 11.Check each process for consistency (what comes out must have gone in) 12.Check against the context for consistency (* But don’t throw it away)

4. Remember Primary Output –What is the result of the process completing its job? Where does it go? Inputs –What information does the process need in order to do its job? Where doe sit come from? Other outputs –What information is required by other processes?

5. Remember Check for consistency against Context Check that what comes out went in Check that all necessary detail has been included –I.E. show your diagram to a manager/end user of the existing system

6. Example Context (Big John’s) Delivery Note Purchase Order Payment Purchase Invoice Sales Invoice Sales Order Sales Delivery Note Payment b wholesaler Big John’s Store a retailer Supply goods to retailer by ordering from wholesaler

7. Example (Big Johns)

8. Group by Function Lejk and Deeks suggest grouping processes by Function This often makes the diagram less complex

9. Example (Big Johns)

10. DFD Levelling DFDs are a communication tool –They should be easy to follow for both skilled systems analyst and customer Too much detail adds complication –but detail is necessary Levelling is a way of achieving detail without adding complication –Different diagrams show different levels of abstraction

11. DFD Levelling (Lejk and Deeks, 2002)

12. Level 1 Diagram (Lejk and Deeks, 2002)

13. Level 2 Diagram for Process 1 (Lejk and Deeks, 2002)

14. Level 2 Diagram for Process 4 (Lejk and Deeks, 2002)

15. How many levels do we need? (Lejk and Deeks, 2002)

16. Guidelines A large number of Data Flows into a process? –Certainly indicates lower level of details –Maybe should split the process Large number of processes (more than 7)? –Should merge processes at current level –Implies lower level detail

17. How do we know when to stop? Each Process will have a description Size of Description? –DeMarco estimates that a 1-page “mini-spec” is sufficient detail –Also suggests basing decision on number of inputs and outputs Inputs/outputs Overall number

18. Elementary Process Descriptions Used to describe the processes One is required for every process May be developed using: –Structured English –Decision Trees/Tables –Flow Charts

19. Structured English Normal text is too ambiguous or too verbose Has three logical constructs –Sequence –Selection –Iteration

20. Sequence A list of actions performed in logical order –Example 1.Go to lecture room 2.Find seat at back 3.Read paper 4.Check watch 5.Listen to lecturer (5 mins max) 6.Check watch 7.Check watch 8.Yawn 9.Leave

21. Selection Used where there is a selection of possible actions and that taken depends on the truth value of a condition IF…THEN…ELSE CASE

22. Selection Example –IF (have pen AND can be bothered) –THEN write notes –ELSE read newspaper Make sure process has appropriate outputs for each alternative action

23. Iteration When a set of actions is repeated a number of times, this number being determined by the truth value of a condition REPEAT…UNTIL WHILE FOR each

24. Iteration Example REPEAT 1.Draw on Desk 2.Check watch 3.Yawn UNTIL Lecture Finished

25. Problems There is a danger that we can get too formal Remember that this is supposed to aid communication There may be a need to write in structured English and then convert that into more regular English There is a trade-off between formality and understandability Try developing EPDs for Big John’s Store

26. Current Physical System We now have a model of the current physical system which is: –Complete –Accurate –Clear We now have to think about the system purely in terms of its process

27. Structured Analysis + Design Existing System ERD Repository Existing Physical System DFD New System ERD Repository New Logical System DFD Convert to Logical View User Requirements Technical Options + Constraints New Physical System

28. Logicalisation – why? Systems Evolve over time –Some processes become redundant, but are still present –Ad-hoc development causes processes to become tightly coupled –Some Process descriptions depend on hardware These factors obscure our view of the system

29. Logicalisation – why? Logicalisation helps to view the system without these factors We can now see the wood not the trees

30. Logicalisation – how? (1) Rationalise Data Flows –Replace documents with data Examples –Delivery Note  Delivery Details –Delivery Note (copy)  Delivery Details

31. Logicalisation – how? (2) Rationalise Data Stores –Remove duplication of data –Remove or rename stores that hold physical documents Examples –Orders, Invoices and Delivery Notes –In trays are good candidates for removal

32. Logicalisation – how? (3) Rationalise Processes –Remove people and places –Change experts into external entities –Remove processes that simply move data around within themselves

33. Logicalisation – how? (4) Reconstruct DFD –Lower level processes will be radically different –These changes must be reflected at top level –New external entities may have been introduced effect the context of the system

34. Level 1 Diagram - Physical (Lejk and Deeks, 2002)

35. Level 1 Diagram - Logical

36. Structured Analysis + Design Existing System ERD Repository Existing Physical System DFD New System ERD Repository New Logical System DFD Convert to Logical View User Requirements Technical Options + Constraints New Physical System

37. References Whiteley, D. (2004) Introduction to Information Systems, Palgrave, 2004. Lejk, M. and D. Deeks (2002) Systems Analysis Techniques, Addison Wesley 2002 Mason, D. and L. Willcocks (1994), Systems Analysis, Systems Design, Alfred Waller, 1994.

38. References Yeates, D. and T. Wakefield (2004) Systems Analysis and Design, FT/Prentice Hall 2004 Gane, C. and T. Sarson (1979) Structured Systems Analysis, Prentice Hall, 1979 Eva, M (1994) SSADM Version 4: A users guide, McGraw hill, 1994

39. References DeMarco, T. (1979) Structured Analysis and System Specification, Yourdon, 1979 Royce, W. (1970) Managing the development of large software systems, In: Proceedings of IEEE WESCON, 1970 pp1-9.