MCS 401

Software Engineering
Mr. G.W. Nkabinde
[email protected]

04/27/24 MCS 401 Software Engineering 1

 Course Info
Instructor
Mr. G.W. Nkabinde
Class Time
Mon 10:30 – 12:20
Thurs: 10:30 – 12:20
Location: Lab 1 & Lab 2

Textbook: Advanced Software Engineering

04/27/24 MCS 401 Software Engineering 2

 Lecture 2:
Structured System Analysis
and Structured Design
(SSA/SD)

04/27/24 MCS 401 Software Engineering 3

 Structured analysis and design
 “Structured analysis is a set of techniques and
graphical tools that allow the analyst to
develop a new kind of system specification
that are easily understandable to the user.
Analysts work primarily with their wits, pencil
and paper.” [Kendall 1996]

04/27/24 MCS 401 Software Engineering 4

Introduction
 The SSA/SD method was developed in the
1970s.
 Originated at about the same time as JSP,
 Evolved from data processing, sequential
problems
 Top-down strategy based on functional
decomposition, considering information flow
and data structure

04/27/24 MCS 401 Software Engineering 5

 This method has been used extensively by many
organization and also had significant influence on
other methods.
 Consists of two separated but related techniques:

1. Structured System Analysis: the solution

(based on problem)
2. Structured Design: its implementation (based
on solution)

04/27/24 MCS 401 Software Engineering 6

 The people who have contributed to the
development of this method include
 Larry
Constantine
 Edward Yourdon
 Tom De Marco

 Others have extended this method in order

to model different circumstances

04/27/24 MCS 401 Software Engineering 7

  Philosophy of structured analysis and design
 Analysts attempt to divide large, complex

problems into smaller, more easily handled

ones. “Divide and Conquer”
 Top-Down approach

 Functional view of the problem.

 Analysts use graphics to illustrate their

ideas whenever possible

04/27/24 MCS 401 Software Engineering 8

Tools / Techniques Used
 SSA/SD is a more general method than
JSP or JSD in the sense that it involves
both analysis and design activities

 SSA/SD uses Data Flow Modeling for

analysis and Structure Charts for the
design

04/27/24 MCS 401 Software Engineering 9

04/27/24 MCS 401 Software Engineering 10
  SSA/SD representation
 functional
 data-modelling
 structural

 SSA/SD process
 Transaction analysis
 Transform analysis
 System integration

04/27/24 MCS 401 Software Engineering 11

Structured system analysis
 Producing the DFDs requires practice:
 Begin to identify operations by considering the I/O (normally
well defined in requirements)
 Work inward from these, or outward from the centre
 Label carefully (plain, precise language; avoid jargon)
 Don’t try to handle exceptions and error conditions yet (they
tend to obscure the rest of the model)
 Don’t use flowcharts (DFDs model the system, whereas
flowcharts show the operation of an implementation)
 In any case, be prepared to revise, and start again rather than
attempting to correct a wrong model.

04/27/24 MCS 401 Software Engineering 12

Structured design (SD)
 Transaction Analysis – separates the components of a
large design into a network of co-operating subsystems:
 by identifying the transactions involved in problem
 by grouping transaction-related DFD components
 by organizing modules into a set of structure charts
 by producing a structure chart of complete system •
 Transform Analysis – deals with sequence of steps
needed to perform a processing operation on a set of
data.
 System integration – combines each of the subsystems
into one complete system design

04/27/24 MCS 401 Software Engineering 13

04/27/24 MCS 401 Software Engineering 14
04/27/24 MCS 401 Software Engineering 15
 After SSA has produced a set of DFDs, there are three
steps to turn the design into structure charts (from which
the system can be implemented):

1. Transaction analysis
 divides the system into tractable units

2. Transform analysis
 converts units into structure charts

3. System integration
 recombines charts by linking units together

04/27/24 MCS 401 Software Engineering 16

A transaction has five basic components:

 1. event in the system’s environment that causes

the transaction to occur
 2. stimulus that is applied to the system to inform it
about the event
 3. activity that is performed by the system as a
result of the stimulus
 4. response that is generated in terms of output
from the system
 5. effect that this has on the environment of the
system

04/27/24 MCS 401 Software Engineering 17

Example
 1. event: student ‘signs up’ for bank account
 2. stimulus: information about student, university,
date of opening account, grant source, etc.
 3. activity: add account details to bank records
 4. response: free gifts to student, chequebook,
debit card, bank statements
 5. effect: student can spend money

Later regrouping of transactions in the system

structure may be as simple as combining with a
case statement.

04/27/24 MCS 401 Software Engineering 18

Step 2: Transform analysis
 • Goal is to find a module’s core function:
 – take DFD model of the problem and transform it
into hierarchical structure
 1. First, identify the central transform in the DFD:
 • central transform lies at the centre of the input and
output data flows • sometimes the central transform
must be created, by adding an extra bubble
 2. DFD is ‘picked up’ by central transform so other
functions hang from it
 • central transform forms the main body of the
module
04/27/24 MCS 401 Software Engineering 19
 3. First-cut Structure Chart is formed
 Bubbles replaced by blocks
 Arrows redrawn to show invocations:
 – they describe flow of data in DFD, but they show
flow of control (procedure calls) in Structure Chart
 Data flows added as side arrows (data
couples)

04/27/24 MCS 401 Software Engineering 20

Transform analysis
 Initial transform makes one-to-one mapping of process
bubbles to subprograms
 Central transform is chosen to be the most abstract of the
process bubbles
 • Least abstract bubbles tend to be closest to the I/O –
mapped to the lower levels of the Structure Chart
 • Need to create a central transform for a procedure that
organizes sequencing of calls to subprocedures (which
is not obvious from a single-level DFD)
 • First-cut Structure Chart requires further refinement to
produce a good design

04/27/24 MCS 401 Software Engineering 21

Step 3: System integration
Finally, last step combines all separate charts from the transaction and
transform analyses:

04/27/24 MCS 401 Software Engineering 22

04/27/24 MCS 401 Software Engineering 23
04/27/24 MCS 401 Software Engineering 24
 Analysis Tools Design Tools

Data Flow Model Plus Complementary Data Flow Model Plus Complementary
tools such as tools such as

Data Dictionary Data Dictionary

Structured English Pseudocode
Decision Trees and Tables Normalization
Entity – Relationship Model Structure Chart

04/27/24 MCS 401 Software Engineering 25

Guidelines for using SSA/SD

 The structured System Analysis and

Structured Design process consists of the
following steps.

04/27/24 MCS 401 Software Engineering 26

Structured System Analysis Steps

1. Construct an initial top level (level 1) Data

Flow Diagram (DFD)

2. Decompose the DFD obtained in (1) to

lowest level and write suitable Data
Dictionary and Process Specification
(also called P-Specs or Mini-Specs)

04/27/24 MCS 401 Software Engineering 27

Structured Design Steps
3. Use Transaction Analysis to divide the DFD
obtained in (2) above into a set of smaller
interrelated DFD’s
Each DFD in this set models a transaction.

4. Perform Transform Analysis on each

DFD Produced in (3) in order to produce a
Structure Chart for each transaction

04/27/24 MCS 401 Software Engineering 28

Structured Design Steps (cont.)

5. Combine the Structure Chart obtained in

(4) to produce a structure chart that models
the overall design of the software system.

04/27/24 MCS 401 Software Engineering 29

Illustration
 Step 1 and 2: Data Flow Modeling

04/27/24 MCS 401 Software Engineering 30

Step 3: Transaction Analysis

04/27/24 MCS 401 Software Engineering 31

 Step 4: Transform Analysis

04/27/24 MCS 401 Software Engineering 32

 Step 5: Combine Structure Charts

04/27/24 MCS 401 Software Engineering 33

 Questions
04/27/24 MCS 401 Software Engineering 34