1. 3.1 Topic 3 MODELLING IN INFORMATION SYSTEMS DEVELOPMENT; PROCESS MODELLING IMS9001 - Systems Analysis and Design

2. 3.2 Modelling in information systems development  Why do we do it?  Communication and understanding  Simplification  all models are simplifications of the real world: they omit some features and emphasise others  this is called “abstraction”  Representation  a model is a simulation: it is made from something which represents reality  Partitioning and level of detail

3. 3.3 Modelling: for whom?  System users and sponsors  e.g compare with someone who wants a house built for them  Other systems analysts  e.g. compare with an architect planning a housing estate  Designers  e.g. compare with an architect planning the layout and design of rooms in a house  Other technical staff - programmers, database builders, systems administrators, etc  e.g. compare with the plumbers, electricians, bricklayers, etc working on a house

4. 3.4 Models in analysis and design  in order to model a system, the systems analyst must choose an appropriate modelling form in terms of its:  audience  purpose  degree of abstraction (simplification)  form of representation  level of partitioning  level of detail

5. 3.5 Data Process Behaviour These three perspectives are typically modelled. Modelling Information Systems

6. 3.6 The requirements specification document  Must be communicated to key stakeholders  Should contain:  Functions and services the system should provide  Non-functional requirements  Constraints affecting the system’s development and operations  Information about other systems the system must interface with  System models are used to help understand the existing system and describe the proposed system

7. 3.7 Process Modelling  process modelling graphically represents the processes which act on data to  capture  manipulate  store  distribute data between the system and its environment and between system components

8. 3.8 Data Flow Diagrams  Model the flow of data into, through, and out of an information system  Represent an information system as a network of communicating processes  show the processes that change or transform data  show the movement of data between processes

9. 3.9 Data Flow Diagrams (DFDs)  a well-known technique  easily understood  a good communication tool  used to model both manual and automated processes  described in Chapter 5 and 8 of the text book Whitten, Bentley and Dittman

10. 3.10 2 calculate price loan application Products Suppliers Process data flow data store source/sink Components of a DFD

11. 3.11 Gane & SarsonDeMarco Alternative sets of symbols  process  data flow  data store  source/sink

12. 3.12 2 calculate price Process  represents the work performed which changes data  transforms incoming data flows into outgoing data flows  has a unique number and name

13. 3.13 Naming processes  name each process using a verb and a noun phrase: "calculate price" "validate customer details" "accept supplier delivery”  the name of a process should describe what the process does  avoid vague names such as "process data”  the number of a process is an identifier.. it does not indicate the sequence of processing

14. 3.14 loan application Data Flow  represents data in motion  describes a "packet" of data or data that move together  may consist of many individual, related elements that move together to the same destination

15. 3.15 2 validate customer order customer order valid customer order invalid customer order Naming data flows  name each data flow using a noun or noun phrase  the name should describe the contents and should include as much information as possible about the data flow

16. 3.16 Data Store  represents a collection of data flows at rest  has a unique name which should describe the contents of the data store  may represent many different types of physical locations of data  may be a temporary or a permanent repository of data Sales Orders

17. 3.17 data flows to and from a data store can remain unlabelled if all attributes in the store are moving, i.e. if an entire data packet (or packets) is going into or out of the data store 2 check sales order Sales orders 3 produce weekly sales totals sales order weekly sales totals Data stores

18. 3.18 Suppliers Source/Sink (External Agent)  represents an entity in the environment with which the system communicates  a source if it is an origin of data coming into the system  a sink if it is a destination for data leaving the system

19. 3.19 Source/Sink (External Agent)  data flows connecting the external agents to the processes within the system represent the interface between the system and its environment  external agents are outside the system and define its boundaries  an external agent may be both a source and a sink  what a sink does with data it receives from the system and how a source produces data which it inputs to the system are outside the boundary of the system and are not shown on the data flow diagram

20. 3.20 1 edit sales order Sales orders 2 create purchase order sales order Customers Suppliers purchase order 1 Example Data Flow Diagram

21. 3.21 Guidelines for Drawing DFDs  each object on a data flow diagram must have a unique name  each process must have at least one data flow coming in (input) and at least one data flow going out (output)  the inputs to a process are different from the outputs of that process  a process must be able to build its outputs using only the information in its input data flows plus any constant information

22. 3.22 Guidelines for Drawing DFDs data flows are permitted: between 2 processes from a data store to a process from a process to a data store from a source to a process from a process to a sink

23. 3.23 Guidelines for Drawing DFDs see page 287 in Hoffer, George and Valacich data flows are NOT permitted: between 2 external agents between 2 data stores from an external agent to a data store

24. 3.24 Guidelines for Drawing DFDs registered application valid application 2 validate application 13 register application reject assess application approved application APPLICATIONS1 Omit any processing required to handle trivial rejects (i.e. where no work needs to be undone): show the possibility of trivial rejects with a data flow labelled reject which has no destination indicated

25. 3.25 Guidelines for Drawing DFDs  data flows can diverge when duplicate "packets" of data are sent to different parts of the system 2 produce customer invoice 1 validate sales order 3 generate shipping slip valid sales order customer invoice shipping slip sales order

26. 3.26 Process Modelling Using Data Flow Diagrams data flow diagrams generally do not show :  the flow of control (i.e. triggers and controls on processes)  the particular implementation sequence (only the input and output data flows should determine the processing sequence shown)  the timing of processing  DFDs show the set of possible paths through the processing that occurs within a system from the viewpoint of what happens to the data flows

27. 3.27 1 check sales order Sales orders 2 create purchase order sales order Customers Suppliers purchase order 1 2 Stock file Example Data Flow Diagram

28. 3.28 Process Modelling Using DFDs DFDs show the set of possible paths through the processing that occurs within a system from the viewpoint of what happens to the data flows

29. 3.29 Process Modelling Using DFDs Data Flow Diagrams generally do not show : the flow of control (i.e. triggers and controls on processes) the particular implementation sequence (only the input and output data flows should determine the processing sequence shown) the timing of processing

30. 3.30 Levelling Data Flow Diagrams  any "real" system is too large to represent as a single data flow diagram  the solution is to decompose the system into a hierarchy of levels of processing  the process model of the system then consists of a set of levelled data flow diagrams  levelling of DFDs improves their readability and usefulness as a communication tool

31. 3.31 Levelling of DFDs  Context diagram  Level 0 diagram  Level 1 diagrams  Level 2 diagrams .  Level n diagrams Levelling creates a hierarchical decomposition of the processing within the system

32. 3.32 Context Diagram  the highest level data flow diagram is the context diagram: it shows the interaction of the system with its environment in terms of data flows; it defines the boundary of the system (the scope of the system)  only the data flows which leave the system and the data flows which come from outside the system are shown  the entire system is represented as a single process  all external agents (sources and sinks) are shown  no data stores are shown: they are inside the boundary of the system

33. 3.33 Example Context Diagram Inventory System Suppliers Sales Order System Warehouse sales order goods unavailable notice purchase order supplier delivery shipping slip checked supplier invoice Accounts Department goods returned

34. 3.34 Level Zero Diagram  the level zero data flow diagram is the diagram at the level immediately below the context diagram  it "expands" the single process on the context diagram to show the major, high- level processes (or functions) within the system

35. 3.35 Level Zero Diagram  all external agents (sources and sinks) are included because the level zero diagram, like the context diagram, represents the entire system  the number of each process ends in.0 which corresponds to the level of the diagram: e.g. 1.0, 2.0, 3.0 etc. often just 1, 2, 3 etc. are used

36. 3.36 Example Level Zero Diagram Monitor Stock levels Suppliers Order Entry System Warehouse sales order out of stock notice purchase order supplier delivery shipping slip checked supplier invoice Accounts Department Fill Sales Orders Accept Deliveries 1.0 2.0 3.0 Stock file

37. 3.37 Levelling DFDs 1 2 3 1.1 1.2 Context diagram Level zero diagram Diagram 1 (at Level 1)

38. 3.38 Level 1 diagrams  a set of data flow diagrams is created at Level 1  there is one Level 1 diagram for each of the processes at Level zero  each diagram decomposes a Level zero process into several processes

39. 3.39 Level 1 and lower level diagrams  each Level 1 diagram and diagrams at lower levels (e.g. Level 2, Level 3) show only a part of the processing  Level 1 processes are numbered 1.1, 1.2, 1.3, and 2.1, 2.2, 2.3 etc  that part is shown in more detail than on the Level zero diagram  no external agents are shown on a Level 1 or lower diagrams, as the entire system is not being represented

40. 3.40 Example Level zero diagram CUSTOMERS SALES ORDERS INVENTORY p.o. number product order qty p.o. invoice delivery qty customer invoice Product details product qty Customer details product holding product order qty product holding product delivered qty product order qty Record and Invoice Sales 1 Maintain Product Inventory 2 SUPPLIERS

41. 3.41 Example Level 1 diagram Customer details Product details product qty SALES ORDERS customer credit status product qty product INVENTORY product holding available qty INVOICES customer invoice Check Customer Credit 1.1 Record Sales Demand 1.3 Check Stock Available 1.2 Create Sales Invoice 1.4

42. 3.42 1.34.2 1.1.11.1.23.2.13.2.2 Context Level 0 Level 1 Level 2 1234 1.11.22.12.23.13.24.14.3 Levelling of DFDs

43. 3.43 Guidelines for Levelling DFDs External communication:  external agents represent entities in the environment of our information system  external agents are outside the scope of our information system  we do NOT model interactions between external agents  we do NOT allow external agents to interact directly with data stores

44. 3.44 Guidelines for Levelling DFDs  numbering: when a process is decomposed, its diagram is given the same number as that process  balancing of levelled DFDs: all data flows entering and leaving a process must appear on the corresponding diagram which decomposes that process  external agents: are only included on the two diagrams which represent the entire system, i.e. the context and level zero diagrams

45. 3.45 the access to data stores across levels of diagrams must be consistent: the direction of accesses must match and all accesses on higher level diagrams must appear on corresponding lower level diagrams a data store is first shown on the highest level diagram where it is accessed by more than one process it can then appear on all lower level diagrams where it is accessed Guidelines for Levelling DFDs

46. 3.46 the access to data stores across levels of diagrams must be consistent: 2 1 1.1 1.2 1.3 Guidelines for Levelling DFDs

47. 3.47 How many levels should be in a set of DFDs?  each diagram usually has between 3 and 7 processes  level the diagrams until bottom level or primitive processes are reached: primitive processes have only 1 or 2 inputs and outputs, and cannot be further decomposed as a data flow diagram Guidelines for Levelling DFDs

48. 3.48  partition processes to minimise the data flows between them  partition processes to form cohesive, related groups of activities  not all parts of the system may need to be decomposed to the same level Guidelines for Levelling DFDs

49. 3.49 Payroll System Line Manager Employment System Successful Applicant Position Spec Decision Acknow- ledgement An example - Context Diagram Position Address Applicant name Position Applicant

50. 3.50 An example - Level zero diagram Position Spec Unsuccessfuls file Evaluation results Accept Applic- ation Decision Successful Applicant Acknow- ledgement Ackn’d Appn Line Manager Applicant Address Position Applicant name Applicant Payroll System Position 1 2 Evaluate Applicants

51. 3.51 Level 1- Diagram 1 Applicant name Verify for Complete- ness Acknow- ledge Application Acknow- ledgement Acknowledged Application Verified Application Position Address 1.2 1.1

52. 3.52 Position Spec Unsuccessfuls fileEvaluation results Successful Applicant Ackn’d Appn unqualified applicant Decision Qualified applicant Decision Level 1 - Diagram 2 2.1 2.22.3 Screen Applicants Reject Unsuitables Schedule Evaluation

53. 3.53 References  HOFFER, J.A., GEORGE, J.F. and VALACICH (2005) Modern Systems Analysis and Design, (4th edition), Pearson Education Inc., Upper Saddle River, New Jersey, USA. Chapter 7  WHITTEN, J.L., BENTLEY, L.D. and DITTMAN, K.C. (2001) 5th ed., Systems Analysis and Design Methods, Irwin/McGraw-HilI, New York, NY. Chapter 8