Data Flow Modelling II

Plan

• Introduction

• Structured Methods– Data Flow Modelling– Data Modelling– Relational Data Analysis

• Feasibility

• Maintenance

Ten Guidelines1. Don’t expect to get it right first time – draw one to throw away*2. Draw a Document Flow Diagram to establish the context3. Check that you have identified all input and output document flows4. Always draw a context diagram – it clarifies the context5. Read through the system description noting candidate processes and data stores6. Identify the External Entity that ‘starts’ the whole system process7. Build the diagram one process at a time adding data stores as required8. For each process identify the main output, all inputs and other outputs9. For each process clearly mark any data flows that go to, or come from, nowhere10. Once the processes are complete check through your work and tidy up loose ends11. 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)

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?

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

Example Context (Big John’s)

Delivery Note

Purchase Order

Payment

Purchase Invoice

Sales Invoice

Sales Order

Sales Delivery Note

Payment

bwholesaler

Big John’s Store

aretailer

Supply goods to retailer by ordering from wholesaler

Example (Big Johns)

Group by Function

• Lejk and Deeks suggest grouping processes by Function

• This often makes the diagram less complex

Example (Big Johns)

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

DFD Levelling

(Lejk and Deeks, 2002)

Level 1 Diagram

(Lejk and Deeks, 2002)

Level 2 Diagram for Process 1

(Lejk and Deeks, 2002)

Level 2 Diagram for Process 4

(Lejk and Deeks, 2002)

How many levels do we need?

(Lejk and Deeks, 2002)

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

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

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

Structured English

• Normal text is too ambiguous or too verbose

• Has three logical constructs– Sequence– Selection– Iteration

Sequence

• A list of actions performed in logical order– Example

1. Go to lecture room2. Find seat at back3. Read paper4. Check watch5. Listen to lecturer (5 mins max)6. Check watch7. Check watch8. Yawn9. Leave

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

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

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

Iteration Example

REPEAT1. Draw on Desk

2. Check watch

3. Yawn

UNTIL Lecture Finished

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

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

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

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

Logicalisation – why?

• Logicalisation helps to view the system without these factors

• We can now see the wood not the trees

Logicalisation – how? (1)

• Rationalise Data Flows– Replace documents with data

• Examples– Delivery Note Delivery Details– Delivery Note (copy) Delivery Details

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

Logicalisation – how? (3)

• Rationalise Processes– Remove people and places– Change experts into external entities– Remove processes that simply move data

around within themselves

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

Level 1 Diagram - Physical

(Lejk and Deeks, 2002)

Level 1 Diagram - Logical

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

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.

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

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.