1. R.J.Peglar@ staffs.ac.uk Process Model

2. R.J.Peglar@ staffs.ac.uk Contents Provide definitions Explain the components and representations Introduce a step by step procedure for creating Data Flow Diagrams. Introduce Structured English (elementary process descriptions)

3. R.J.Peglar@ staffs.ac.uk What is a Process Model? (a.k.a. Data Flow Model) A method of representing the Processes within a system. What it must DO – its “Processes” / ”Activities” / ”Functions” The representation methods we will look at are Context Diagram, Data Flow Diagrams, Structured English (Other methods include the use of UML diagrams)

4. R.J.Peglar@ staffs.ac.uk What is a Data Flow Model? A Data Flow Model (DFM) defines the passage of data through a system’s processes. The DFM comprises of a consistent set of hierarchical Data Flow Diagrams (DFD) and associated documentation. The top level DFD is named ‘Context Diagram’.

5. R.J.Peglar@ staffs.ac.uk Uses of Data Flow Modelling Used in systems analysis in order to: understand the flows of data around the system define processes that transform or manipulate data identify the sources and recipients of data outside the system show where data is held in the system aid communication between user and analyst form the basis of function definition and event identification

6. R.J.Peglar@ staffs.ac.uk DFM Versions Three versions of the DFM may be produced: Current physical DFM Logical DFM Required system DFM

7. R.J.Peglar@ staffs.ac.uk Hierarchy (1) Different levels of complexity (Zoom). May be up to 4 levels. Highest level is one Context Diagram (sometimes called a Level 0 DFD) Next level down consists of one Level 1 DFD which provides an overview of the system (typically 6 processes) Each process in a Level 1 DFD has its own Level 2 DFD in which describes the process in more detail. Some complex systems may require Level 3 DFDs for certain level 2 processes. Each lowest level process has an Elementary Process Description

8. R.J.Peglar@ staffs.ac.uk Elementary process desc. Elementary process desc. Elementary process desc. Elementary process desc. Hierarchic Data Flow Diagrams (2) Context Diagram Level1 DFD Level2 DFD Level3 DFD Elementary process desc. Elementary process desc. Elementary process desc. Elementary process desc. Elementary process desc.

9. R.J.Peglar@ staffs.ac.uk Components of Data Flow Diagrams Data Flow Diagrams consist of four components External Entities Data Flows Processes Data Stores.

10. R.J.Peglar@ staffs.ac.uk Data Flow Diagram Conventions process name n.n.n location data flow name datastore nameDn external entity name (use data flow name or list items of data)

11. R.J.Peglar@ staffs.ac.uk External Entity a person, organisation, department, computer system or anything else which either sends data into a system (sometimes called a source) or which receives data from a system (sometimes called a sink) but which for the purposes of the project in question are outside the scope of the system itself. External entities (in the SSADM scheme) are represented as ovals containing the name of the external entity and a unique alphabetic identifier

12. R.J.Peglar@ staffs.ac.uk Data Flow A data flow represents data which may travel from one element of a DFD to another. Data Flows are represented by arrows which are labelled with a simple meaningful name. A data flow should always begin or end at a process.

13. R.J.Peglar@ staffs.ac.uk Context Diagram The highest level DFD. all the complexities of the internal workings of a system are hidden from view by representing the entire system as one black box process. This receives input data flows from External Entities and transmits output data flows to External Entities.

14. R.J.Peglar@ staffs.ac.uk Processes Transformations which change incoming data flows into outgoing data flows. Processes are represented as rectangles which contain a simple description of the process. Each process has a unique reference number. In the early stages of data flow modelling it is possible to show where in the organisation the process takes place but this information will be removed when the DFD is ‘logicalised’

15. R.J.Peglar@ staffs.ac.uk Data Store A repository for data. A data store is represented by an open ended rectangle containing the name of the data store (usually a plural noun e.g. ‘orders’) Each data store has a unique reference number prefixed by the letter D (you may also use T for a ‘transient’ data store during initial modelling)

16. R.J.Peglar@ staffs.ac.uk Drawing DFDs – How to Establish the major inputs and outputs of the system, their sources, recipients and represent them in a ‘context diagram’ Establish processes which handle data flows on their arrival into the system, and generate output data flows Identify the data stores which are required to link the input and output processes, i.e. the data stores which need to be read from and written to Rationalise the Level 1 DFD so that it includes maximum 7 processes (combine and/or split processes if necessary). For each level 1 process draw a level 2 DFD and if necessary draw any level 3 DFDs required. Review the entire DFD set against the identified requirements and re-draft if necessary.

17. R.J.Peglar@ staffs.ac.uk Drawing DFDs (2) Choose meaningful names for processes, flows, stores, and terminators. Number the processes. Redraw the DFD as many times as necessary. Avoid overly complex DFDs. Make sure the DFD is internally consistent and consistent with any associated DFDs.

18. R.J.Peglar@ staffs.ac.uk Uses of DFDs Drawing DFDs helps the analyst understand the system. DFDs can be used as a communication when discussing the system with others. They are simple enough for users to understand so can help in validating the analysts understanding and in checking functionality of the proposed system.

19. R.J.Peglar@ staffs.ac.uk Naming Conventions Note that the process is named or described with a single word, phrase, or simple sentence. For most DFD models it is sufficient to say that a good name will generally consist of a verb-object phrase such as VALIDATE INPUT or COMPUTE TAX RATE. The flows named. The name represents the meaning of the packet that moves along the flow. A corollary of this is that the flow carries only one type of packet, as indicated by the flow name. The systems analyst should not name a dataflow APPLES AND ORANGES AND WIDGETS AND VARIOUS OTHER THINGS (though there can exceptions to this convention: it is sometimes useful to consolidate several elementary data flows into a consolidated flow). Thus, one might see a single data flow labeled VEGETABLES instead of several different data flows labeled POTATOES, BRUSSEL SPROUTS, and PEAS. This would be documented in the data dictionary.

20. R.J.Peglar@ staffs.ac.uk DFDs with different symbols….

21. R.J.Peglar@ staffs.ac.uk Elementary Process Description Describes the detail of what happens – used by the programmers Must only be for the lowest level processes Variety of methods for description: Narrative Structured English / pseudo-code Decision trees Decision charts

22. R.J.Peglar@ staffs.ac.uk Summary What is meant by a Process or Data Flow Model What information it contains Its hierarchical structure Why it is used How to create one

23. R.J.Peglar@ staffs.ac.uk More information See http://yourdon.com/strucanalysis/wiki/index.ph p?title=Chapter_9 http://yourdon.com/strucanalysis/wiki/index.ph p?title=Chapter_9 A very full treatment of DFDs But note that the symbols are different to the ones we will use

24. R.J.Peglar@ staffs.ac.uk More Information(2) www.efsa.unsa.ba/~nijaz.bajgoric/cware/pds/i sd/chap09.ppt Note that the use of the term ‘level 0 dfd’ referred to here would be what is known s ‘level 1’ in SSADM notation. Such inconsistent terminology is not unusual in SA&D where very similar things are often referred to by different names!