System Development And Analysis

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 modules 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

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

• 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

• Control Coupling
• one module passes a piece of information intended
  to control the internal logic of another -this
  may be data or a flag

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

36
An Example of Transaction Analysis eSale
37
An Example of Transaction Analysis eSale
38
(No Transcript)
39
(No Transcript)
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

44
(No Transcript)
45
(No Transcript)
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

55
Required DFD's For Structure Chart
56
Self Study Main Text Ch16