1. System Development And Analysis

2. MOVING FROM LOGICAL TO PHYSICAL PROCESS MODELS Analysis phase – focus on logical processes and data flows Design phase – create physical process models showing “how” the final system will work Physical process models convey the “system view” of the new system

3. The Physical Data Flow Diagram The physical DFD contains the same components as the logical DFD, and the same rules apply There are five steps to perform to make the transition to the physical DFD

4. New Logical to New Physical System Design Some design investigate alternate ways to implement the system by drawing a boundary to identify those processes that are to be automated The automation boundary can be drawn on high and low level DFD or on a class diagram

5. Steps to Create the Physical Data Flow Diagram Metadata is data about data

6. The Physical Data Flow Diagram (to remind you)

7. Dividing into Computer Subsystem Architecture design then continues with DFDs in automation boundary and uses out put from database design and user procedure design to produce a structure chart Logically connected processes are grouped in to computer subsystem These sub system usually involve one transaction(similar function) or some connected transactions and become transaction program or batch suites program. The most common method for grouping DFD processes is to follow through on kind of input, which usually identifies a part of a business process see example on page 400

8. The Structure Chart Describes functions and sub-functions of each part of system Shows relationships between modules of a computer program Simple and direct organization –Each module performs a specific function –Each layer in a program performs specific activities Chart is tree-like with root module and branches

9. The Structure Chart Purpose A structure chart is a hierarchy chart with arrows showing the flow of data and control information between the modules. Structure charts are used as design tools for functionally decomposing structured programs.

10. Structure Chart Conventions Structure chart uses a number of conventions to describe system operations The most common conventions specify the execution sequence and parameter passing between modules

11. Coupling & Cohesion Module coupling –Measure of how module is connected to other modules in program –Goal is to be loosely coupled (independent) Module cohesion –Measure of internal strength of module –Module performs one defined task –Goal is to be highly cohesive

12. Coupling & Cohesion coupling is a measure of how independent or inter-dependent modules are –has the module everything it needs or does it depend on any other module(s) to complete its task? cohesion is a measure of how much the internal elements logically belong together –has the module nothing more than it needs to do one task well, or does it contain extra undesirable elements? –does it have more than one role?

13. Types of cohesion Functional - best type of cohesion –all the module’s elements are necessary for the single, specific task –module contains all elements required for the task, and no more –“single minded” modules Sequential –the elements are related by sequence: the output from one is the input for some other –e.g. the 3 modules: calc_gross_pay, calc_deductions, calc_net_pay Communicational –all of the elements in a module operate on the same input data or produce the same output data

14. Types of cohesion Procedural –the elements make up a single control sequence; usually occurs if flowcharting has been used as a design technique Temporal –the elements are all executed at the same time (e.g. initialisation or close down) Logical –the elements perform a set of logically related tasks e.g. different types of error handling Coincidental - the weakest type of cohesion –no significant relationship between the elements of a module, they are simply bundled together by coincidence producing “scatterbrained” modules

15. Cohesion

16. Hints for achieving Functional Cohesion write down a sentence describing the purpose of each function and then analyse it if it cannot be phrased without a comma or more than one verb it probably has sequential or communicational cohesion if it contains words concerning time (first, next, then, after, when, etc) then it probably has sequential or temporal cohesion if the verb is not followed by a simple, single noun then it probably has logical binding e.g. edit all data words such as initialise, clean up, etc suggest temporal cohesion

17. Coupling Normal coupling –one module calls another with no parameter passing nor return values (i.e. no data communication) –e.g.clearScreen Data coupling –data is passed between modules –achieved via parameter passing and/or return values –simple example:  date day of week 

18. Coupling Stamp Coupling unnecessary data passed between modules e.g. whole personnel record sent to calc_age module when only the date of birth is needed makes the called module do more than it needs to makes it less reusable in programs with different record structures

19. Coupling Control Coupling one module passes a piece of information intended to control the internal logic of another -this may be data or a flag procedure PrintRec is begin Display Name (name, sex);..... end PrintRec; procedure DisplayName (in : name, sex) is begin if sex = m then print Mr. else print Ms print the name end DisplayName;

20. Coupling Common (global) coupling - very undesirable –communication via shared or global data –Suppose modules A, B & C each access some global data. Module A reads it and then invokes B, which alters it incorrectly. Later C reads it, attempts to process it, fails, and the program crashes. Apparent cause is module C, actual cause is module B. Content (pathological) coupling the highest and worst degree of coupling, occurring when either: –one module makes use of data or control information held within another module, or –one module branches into the middle of another (gotos!)

21. Types of Coupling

22. Elements in Structure Chart

23. Basic Building Blocks in SC Rectangular box –A rectangular box represents a module –It is always annotated with the name of the module it represents Example

24. Basic Building Blocks in SC Module invocation arrow –An arrow connecting two modules (rectangular boxes) –It represents the control passing from one module to another Example

25. Basic Building Blocks in SC Data flow arrow – To represent the data passes from one modulo to the other in the direction of arrow –Small arrow appears alongside the modulo invocation arrow –It is annotated with the corresponding data name Example

26. Basic Building Blocks in SC Library Modules – To represent frequently called modules –When a module is invoked by many other modules it is treated as a library module –It is denoted by a rectangle with double edges Example

27. Basic Building Blocks in SC Decision –To represent a selection out of many options –It is denoted by a diamond symbol –One module out of several modules connected with the diamond symbol is invoked depending on the condition attached to the diamond symbol Example

28. Basic Building Blocks in SC Iteration – To represent a repetition when two or more modules are invoked repeatedly –It is denoted by a control flow with loop Example

29. A Simple Structure Chart for the Calculate Pay Amounts Module

30. Structure Chart Symbols

31. Structure Chart for Entire Payroll Program

32. Developing a Structure Chart Two strategies are know for transforming DFD into a structure chart Transaction analysis –Uses system flow chart and event table inputs –Upper-level modules developed first –Identifies each transaction supported by program Transform analysis –Uses DFD fragments for inputs –Computer program “transforms” inputs into outputs –Charts have input, calculate, and output sub-trees

33. Transaction Analysis Transformation analysis is suitable for transforming central system, which is characterized by identical processing steps for each data items Transaction analysis is suitable for transaction-driven system which is characterized by several possible paths are to be traversed through the DFD depending on the input data item The number of bubbles on which the input data to the DFD are incident defines the number of transactions However, some transactions may not require any input data

34. Transaction Analysis Identify a transaction by tracing the path from an input data to output data All traversed bubbles belong to the transaction These bubbles is to be mapped to a module in the structure chart There will be root module under which all modules identifying transactions will be drawn Every transaction carries a label identifying its functionality A transaction can be refined to its more detailed level (sub- modules)

35. An Example of Transaction Analysis: eSale

40. Transform Analysis Based on the idea that computer program “transforms” input data into output data Structure charts developed with transform analysis usually have 3 main subtrees –Input subtree to get data –A calculate subtree to perform logic –An output subtree to write the results Can create it rearranging elements from –DFD fragment for an event (e.g. “create new order”) –The detailed DFD for that event E.g. see next two slides for “create new order” DFD fragment, and its corresponding detailed DFD

41. Transformation Analysis Transform analysis identifies the primary functional components and high level input and outputs for these components There are three steps in the transformation analysis: First step. –Divide the DFD into three parts Afferent branch –The input portion that transform input data from physical (e.g. reading from a source) to logical (storing into a table) Efferent branch –The output portion that transform output data from logical form (e.g. output from a process) to physical form (e.g. display the result) Central Transform –The remaining portion of the DFD

42. Transformation Analysis Second step. –Derive the structure chart by drawing on module for each of the afferent branch, central transform, and the efferent branch –They are drawn below a module called the root module which invokes these modules Example

43. Transformation Analysis Third step. –Refine the structure chart by adding sub modules required by each of the high-level functional components –Factoring Process of breaking functional components into subcomponents is called factoring The factoring process should be repeated until all bubbles in the DFD are represented in the structure chart

46. High-Level Structure Chart for the Order-Entry Subsystem After Transaction Analysis

47. Steps to Create a Structure Chart from a DFD Fragment Determine primary information flow –Main stream of data transformed from some input form to output form Find process that represents most fundamental change from input to output Redraw DFD with inputs to left and outputs to right – central transform process goes in middle Generate first draft of structure chart based on redrawn data flow

48. The Create New Order DFD Fragment

49. Decomposed DFD for Create New Order

50. Rearranged Create New Order DFD

51. First Draft of the Structure Chart for Create New Order (Figure 10-14)

52. Steps to Create a Structure Chart from a DFD Fragment ( continued ) Add other modules –Get input data via user-interface screens –Read from and write to data storage –Write output data or reports Add logic from structured English or decision tables Make final refinements to structure chart based on quality control concepts

53. The Structure Chart for the Create New Order Program (Figure 10-15)

54. Structure Chart vs. Flow Chart SC – Identify different modules of the software FC - Identify the control of execution of a program SC - Represent data interchange among different modules FC – Technique to represent the flow of control SC – Not able to depict ordering of tasks FC – Depicts the ordering of tasks

56. Self Study Main Text Ch:16