Presentation is loading. Please wait.

Presentation is loading. Please wait.

SYSTEM ANALYSIS AND DESIGN SAFAA S.Y. DALLOUL. DESIGN THE PROGRAM.

Similar presentations


Presentation on theme: "SYSTEM ANALYSIS AND DESIGN SAFAA S.Y. DALLOUL. DESIGN THE PROGRAM."— Presentation transcript:

1 SYSTEM ANALYSIS AND DESIGN SAFAA S.Y. DALLOUL

2 DESIGN THE PROGRAM

3 UNIT 8: SYSTEM ACQUISITION STRATEGY Introduction Moving from Logical to Physical Process  Models  The Physical DFD Designing Programs  Top-down Modular Approach Structure Chart  Syntax Module Library Loop Conditional Line Data Couple Control Couple Off-Page Connector On-Page Connector  Building the Structure Chart  Types of Structure Charts  Steps in Building the Structure Chart

4 INTRODUCTION

5  Program design - creating instructions for the programmers  The top-down, modular approach - begin with the “big picture” and gradually add detail  Program design document – all structure charts and specifications needed by programmers to implement the system

6 MOVING FROM LOGICAL TO PHYSICAL PROCESS

7  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 Models

8 MOVING FROM LOGICAL TO PHYSICAL PROCESS  The physical DFD contains the same components as the logical DFD, and the same rules apply The Physical DFD Add implementation referenceDraw a human-machine boundary Add system-related data stores, data flows, and processes to the model Update the data elements in the data flows Update the metadata in the CASE repository to include physical characteristics. 5 steps to convert to the physical DFD

9 MOVING FROM LOGICAL TO PHYSICAL PROCESS  There are 5 steps to perform to make the transition to the physical DFD 1) Add implementation reference: using the existing logical DFD, place the way in which the data stores, data flows, and processes will be implemented in parentheses below each component. The Physical DFD

10 MOVING FROM LOGICAL TO PHYSICAL PROCESS  There are 5 steps to perform to make the transition to the physical DFD 2) Draw a human-machine boundary: draw a line to separate the automated parts of the system from manual parts. The Physical DFD

11 MOVING FROM LOGICAL TO PHYSICAL PROCESS  There are 5 steps to perform to make the transition to the physical DFD 3) Add system-related data stores, data flows, and processes to the model (components that have little to do with the business model). The Physical DFD

12 MOVING FROM LOGICAL TO PHYSICAL PROCESS  There are 5 steps to perform to make the transition to the physical DFD 4) Update the data elements in the data flows: update the data flows to include system related data elements. The Physical DFD

13 MOVING FROM LOGICAL TO PHYSICAL PROCESS  There are 5 steps to perform to make the transition to the physical DFD 5) Update the metadata in the CASE repository to include physical characteristics. The Physical DFD

14 MOVING FROM LOGICAL TO PHYSICAL PROCESS The Logical DFD

15 MOVING FROM LOGICAL TO PHYSICAL PROCESS The Physical DFD

16 DESIGNING PROGRAMS

17  Resist temptation to write code to quickly  System quality is enhanced with top-down, modular design  Program design document is the final deliverable for this task

18 DESIGNING PROGRAMS  Think about giving someone directions to your house.  It is best to first orient the person to the general location.  Then you can become more detailed in your instructions. Top-down Modular Approach

19 DESIGNING PROGRAMS  Directions can be communicated in modules, so each module can change without affecting the rest of direction Top-down Modular Approach

20 STRUCTURE CHART

21  Important program design technique  Shows all components of code in a hierarchical format  Sequence  Selection  Iteration

22 STRUCTURE CHART  Syntax  Building the Structure Chart  Types of Structure Charts  Steps in Building the Structure Chart

23 STRUCTURE CHART  Denotes “logical piece of program”  Has a number and a name.  It is a control module if it calls other modules below it.  It is a subordinate module if it is controlled by a module at a higher level.  Syntax |Module

24 STRUCTURE CHART  Donates a logical piece of program that is repeated within the structure chart.  Has a name and a number  Multiple instance within the diagram  Syntax |Library

25 STRUCTURE CHART  Communicates that a module(s) is repeated.  It is drawn using a curved arrow  It is placed around lines on one or more modules that are repeated  Syntax |Loop

26 STRUCTURE CHART  Communicates that subordinate modules are invoked by the control module based on some conditions  It is drawn using a diamond.  Includes modules that are invoked based on some condition  Syntax |Conditional Line

27 STRUCTURE CHART  Communicates that data is being passed from one module to another  Contains an arrow and an empty circle  Names the type of data that is being passed  Syntax |Data Couple

28 STRUCTURE CHART  Can be passed up or down  Has a direction that is donated by the arrow  Syntax |Data Couple

29 STRUCTURE CHART  Communicate that a message or a system flag is being passed from one module to another.  Contains an arrow and filled in circle  Syntax |Control Couple

30 STRUCTURE CHART  Names the message or flag that is being passed  Shown be passed up, not down  Has a direction that is denoted by the arrow.  Syntax |Control Couple

31 STRUCTURE CHART  Identifies when parts of the diagram are continued on another page of the structure chart  It is denoted by the hexagon  Has a title  It is used when the diagram is too large to fit everything on the same page.  Syntax |Off-Page Connector

32 STRUCTURE CHART  Identifies when parts of the diagram are continued somewhere else on the same page of the structure chart.  It is denoted be the circle  Has a title  Syntax |On-Page Connector

33 STRUCTURE CHART  It is used when the diagram is too large to fit everything in the same spot on a page.  Syntax |On-Page Connector

34 STRUCTURE CHART  Processes in the DFD tend to represent one module on the structure chart Afferent processes – provide inputs to system Central processes – perform critical system operations Efferent processes – handle system outputs  The DFD leveling can correspond to the structure chart hierarchy  Building the Structure Chart

35 STRUCTURE CHART  Transaction Structure – control module calls subordinate modules, each of which handles a particular transaction  Types of Structure Charts

36 STRUCTURE CHART  Types of Structure Charts

37 STRUCTURE CHART  Transform Structure - This structure has a control module that calls several subordinate modules in sequence after which something “happens.”  These modules are related because together they form a process that transforms some input into an output.  Many afferent processes  Types of Structure Charts

38 STRUCTURE CHART  Transform Structure - This structure has a control module that calls several subordinate modules in sequence after which something “happens.”  Few efferent processes  Higher up levels of structure chart  Using inputs to create a new output  Types of Structure Charts

39 STRUCTURE CHART  Types of Structure Charts

40 STRUCTURE CHART  Identify top level modules and decompose them into lower levels  Add control connections  Add couples  Review and revise again and again until complete  Steps in Building the Structure Chart

41 STRUCTURE CHART  The following figure is an example about structure chart

42 SAFAA S.Y. DALLOUL SAFAADALLOUL.WORDPRESS.COM


Download ppt "SYSTEM ANALYSIS AND DESIGN SAFAA S.Y. DALLOUL. DESIGN THE PROGRAM."

Similar presentations


Ads by Google