SYSTEM ANALYSIS AND DESIGN SAFAA S.Y. DALLOUL

DESIGN THE PROGRAM

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

INTRODUCTION

 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

MOVING FROM LOGICAL TO PHYSICAL PROCESS

 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

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

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

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

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

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

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

MOVING FROM LOGICAL TO PHYSICAL PROCESS The Logical DFD

MOVING FROM LOGICAL TO PHYSICAL PROCESS The Physical DFD

DESIGNING PROGRAMS

 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

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

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

STRUCTURE CHART

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

STRUCTURE CHART  Types of Structure Charts

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

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

STRUCTURE CHART  Types of Structure Charts

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

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

SAFAA S.Y. DALLOUL SAFAADALLOUL.WORDPRESS.COM