Modelling: Review. Modelling Information Systems. Models in analysis and design. Process Modelling. Modelling perspectives

Transcription

1 Modelling: Review IMS100 Systems Analysis and Design Topic Review of Process Modelling 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 Models in analysis and design in to model a, the s 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 Modelling Information Systems Three aspects of information s are typically modelled: data e.g. entity relationship diagrams, data structure diagrams process e.g. function decomposition, structure charts, data flow diagrams behaviour e.g. entity life history diagrams, state transition diagrams Modelling perspectives Process Modelling The Organisation Data Behaviour Process Process modelling graphically represents the processes which act on data to: capture manipulate store distribute data between the and its environment and between components 1

2 Data Flow Diagrams Model the flow of data into, through, and out of an information Represent an information as a network of communicating processes show the processes that change or transform data show the movement of data between processes 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 Components of a DFD Process Process data flow data store calculate price loan application represents the work performed which changes data transforms incoming data flows into outgoing data flows has a unique number and name Products source/sink Suppliers calculate price 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 loan application 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

3 Source/Sink (External Agent) Example Data Flow Diagram represents an entity in the environment with which the communicates a source if it is an origin of data coming into the a sink if it is a destination for data leaving the Suppliers Customers 1 check 1 Sales create purchase Stock file purchase Suppliers Process Modelling Using DFDs Process Modelling Using DFDs Data Flow Diagrams generally do not show : DFDs show the set of possible paths through the processing that occurs within a from the viewpoint of what happens to the data flows 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 Levelling of DFDs Levelling ofdfds Levelling creates a hierarchical decomposition of the processing within the Context diagram Context diagram Level 0 diagram Level 1 diagrams Level diagrams... Level n diagrams Level zero diagram Diagram 1 (for Process 1 in the Level 0 diagram) 3

4 Logical and Physical DFDs Data Flow Diagrams may focus on either: the physical view of the s processing OR the logical view of the s processing Physical DFDs represent a particular way of implementing the processes and data in a they are technology dependent they show how the processing takes place and how the data is implemented Logical DFDs represent what a must do regardless of how it is implemented they are technology independent they show what processing and data movements must occur in a they show the essential aspects of a Using Logical and Physical DFDs physical DFDs help s analysts become familiar with how a business or operates physical DFDs help s analysts understand and document problems with existing s users can relate to physical DFDs more readily because they contain implementation details: landmarks e.g. people or roles, actual locations implementation details can be removed from physical DFDs use names for data flows and data stores which indicate their content, not their physical form or location AZ104 form.1 Bill checks form checked AZ104 form Master File use names for processes that indicate what, not how.1 valid Sales 4

5 Eliminate physical processes that refer to physical activities only and do not transform data daily mail delivery Open mail opened mail Retrieve mail mail Register mail registered mail Remove any data stores that are implementation dependent transactions transactions Transaction file Update master file Master file customer Record customer received customer employee details employee details Employees Avoid arbitrary sequencing consider the implications for processing cycles of showing data stores.1. A.1.3 B Sales Produce customer invoice customer invoice only show this sequence if process B requires data produced by process A OR valid Produce customer invoice customer invoice Logical and Physical DFDs an example physical DFD for part of an processing Physical DFDs Logical DFDs AZ4- form reject reject..1.1 Orders clerk..1.1 Check checked forms valid Sorted file Sort into number..1. Check stock available Stock file a logical DFD derived from the physical DFD above Products accepted Run the program..1.3 Complete processed filled View How processing is What the does implemented Processes Actual sequence Essential sequence Naming Forms, locations, Underlying data and people/roles activities Data flows Excess/duplicated data Only essential inputs for implementation and outputs of the needs processes 5

6 References Hoffer, J.A., George, J.F. and Valacich (1999) nd ed., Modern Systems Analysis and Design, Benjamin/Cummings, Massachusetts - Chapter 8 Whitten, J.L., Bentley, L.D., and Dittman, K.C., (001) 5th ed., Systems Analysis and Design Methods, Irwin, Burr Ridge, Illinois - Chapters 5,8 6