Structure Systems Analysis

& Design

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

Structured Systems Analysis
and Structured Design SSA/SD
• SSA/SD provides an example of a significantly broader approach than that of JSP
to the activities involved in software design.
• foundation for this approach by Larry Constantine and Ed Yourdon, in association
with their coworkers at IBM
• As a design method, this one is really a composite of two separate but related
techniques.
• The first is Structured Systems Analysis,
• which is concerned with the modeling of problem-related features of a system (often
termed ‘analysis’), making use of a set of descriptive forms that can also be used for
architectural design.
• The second is Structured Design,
• which in turn is oriented towards the solution-related aspects (detailed design).

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

Representation forms for SSA/SD
• Representations for Structured Systems Analysis
• DFDs provide a problem-oriented and functional viewpoint
• elaborating this where necessary by using child DFDs in order to provide the
necessary levels of detail.
• The functional viewpoint provided through the use of DFDs can be
augmented (improved) by means of more detailed descriptions in the form of
‘process specifications’, or ‘P-Specs’ (sometimes termed ‘mini-specs’).
• A P-Spec is a textual description of the primitive process that is represented
by a bubble in a DFD
• P-Spec will summarize the process in terms of its title, a description of the
input/output data flow relating to the process, and the procedural tasks that
it performs
• A data dictionary can also be used to record the information content of data
flows. This typically includes descriptions of all of the data forms

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

DFD

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

P-Spec / mini spec

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

Data dictionary

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

Representations used for Structured Design
• the Structured Design activities mostly make use of only one
significant form of diagrammatical notation called the Structure Chart
• Structure Chart is a program-oriented form of description in the call-
and-return style.

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

Data dictionary

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya
SWE2004-FALL 2018-19 Faculty:S.SreeDharinya
SWE2004-FALL 2018-19 Faculty:S.SreeDharinya
The SSA/SD process
• The five basic steps,
• 1. Construct an initial DFD to provide a top-level description of the problem
(the ‘Context Diagram’).
• 2. Elaborate this into a layered hierarchy of DFDs, supported by a data
dictionary.
• 3. Use Transaction Analysis to divide the DFD into tractable units.
• 4. Perform a Transform Analysis on the DFD created for each transaction, in
order to produce a Structure Chart for that transaction.
• 5. Merge the resulting Structure Charts to create the basic implementation
plans, and refine them to include any necessary error-handling, initialization,
and other exceptions.

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

Transformation Diagram for Structured Systems Analysis and
Structured Design
Requirement
Document

Transformation of
1. Construct
viewpoint (Creation
initial DFD
of model)

Data Flow Diagram

2. Refine DFD Refinement of

and expand viewpoint

Data Flow Diagrams

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

 3. Transaction Refinement of
Analysis viewpoint

Data Flow Diagrams

Optionally add
central
transform Transformation of
4. Transform viewpoint (add
Analysis decisions about
invocation)
Structure Chart

5. Merge and Refinement of

Refine viewpoint

Structure Chart
SWE2004-FALL 2018-19 Faculty:S.SreeDharinya
Steps 1 and 2: Structured Systems Analysis
• The objective of the Structured Systems Analysis steps is
• to produce a functional specification that describes what the system is to do.
• context diagram contains the data flows described that are external to the
system.
• there are two commonly used strategies
• Top-down functional decomposition
• the ‘traditional’ approach, in which first the context diagram is divided into a set of
‘functional’ subtasks
• Event-partitioning
• a technique in which the thread of actions associated with each event is identified and
used to form a simple bubble in the DFD.

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

A Context diagram

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

Some of the useful practices that are recommended by De Marco and
Page-Jones

• begin the task of identifying operations by considering the inputs and

outputs
• work inwards from these, if appropriate, otherwise outwards from
the centre;
• label carefully
• don’t try to handle exceptions and error conditions at this stage,
• don’t flowchart (DFDs are used to model the system, whereas a
flowchart models the operations of the machine that will eventually
be used to implement the system).

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

Step 3: Transaction Analysis
• The main purpose of the actions of this step is to separate the
components of a large design into a network of cooperating
subsystems,
• The Transaction Analysis is concerned with architectural design
• Its process part is concerned with the identification of transactions.

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

• A transaction is usually considered to have five basic components:
• the event in the system’s environment that causes the transaction to occur;
• the stimulus that is applied to the system to inform it about the event;
• the activity that is performed by the system as a result of the stimulus;
• the response that this generates in terms of output from the system;
• the effect that this has upon the environment.

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

Step 4: Transform Analysis
• The first action of the designer is to identify the operation or ‘bubble’
that acts as the central transform in the DFD.
• The central transform is the bubble that lies at the centre of input and
output data flow – where these are considered to have their most
abstract form

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

Transform analysis

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

• A major distinction between the DFD and the Structure Chart is that
the DFD is non-sequential and describes the structure of the problem,
while the structure chart describes a solution in terms of a hierarchy
of program units.

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

• Constructing SSA & SD for SafeHome security
system

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

 Context Diagram : Single Bubble

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya

SWE2004-FALL 2018-19 Faculty:S.SreeDharinya
SWE2004-FALL 2018-19 Faculty:S.SreeDharinya
SWE2004-FALL 2018-19 Faculty:S.SreeDharinya
SWE2004-FALL 2018-19 Faculty:S.SreeDharinya