Principles of Structured System
Development
(CSA2821 – Diploma Course)
Dr. Ernest Cachia
Department of Computer Science & A. I.
Who should you be?
People equipped with the following:
A basic interest in the field of software
development as a whole
A basic awareness of traditional programming
methods
Receptive to new ideas (even willing to try
them out)
Able to impose discipline on your thoughts
and actions, even on what might seem trivial
© 2003 - Dr. Ernest Cachia
Slide 2
Structured Specification
A possible generic definition:
“A pre-defined set of steps aimed at producing
an efficient description of what is to be done.”
A possible s/w-oriented definition:
“A set of clear and un-ambiguous guidelines,
tools and methods to aid in the production of a
valid and usable description of what a
software system is to achieve.”
© 2003 - Dr. Ernest Cachia
Slide 3
I/O requirements of specification
Input to specification:
A complete feasibility study
A confident understanding of user
requirements (usually in abstract form)
Output from specification:
Graphic (and textual were necessary)
descriptions of all system aspects
Feed-back of any system-forced constraints
© 2003 - Dr. Ernest Cachia
Slide 4
Some specification properties
If carried out MUST precede design
Will aid the design process
Must be structured to correctly specify
user needs
Should contain no embellishments
Should predominantly be graphic
Should be easily and clearly understood
Should make provisions for prototyping
© 2003 - Dr. Ernest Cachia
Slide 5
How does specification help?
Forces one to better and more
comprehensively analyse a situation
Forces the analyst (i.e. the person producing a
description of the system) to interface more
closely and seriously with the system
user(s) (i.e. bridges the gap between the supplier’s
and the customer’s fields of knowledge)
Offers the ideal starting point for sound
system design
© 2003 - Dr. Ernest Cachia
Slide 6
S/w specification until recently
User requirements took second-stage to
actual system implementation
Specification was never taken seriously
“Seasoned” programmers felt degraded
when asked to specify what they thought
they already knew well
Quite often systems were specified after
their implementation (often bug-driven)
© 2003 - Dr. Ernest Cachia
Slide 7
Reasons for specification neglect
Previous personal nature of software
Previous software system size
Previous software system demands
Warped ideas about specification being
a tool for people who can’t think well (give
the poor guys something to help organise their
thoughts with)
Basic laziness and “cross-your-fingersand-hope” attitude
© 2003 - Dr. Ernest Cachia
Slide 8
Structured specification Tools
Graphic:
Data Flow Diagrams (DFDs)
Finite State Machines (FSMs)
Data Structure Diagrams (DSDs)
Etc.
Textual:
Natural language (eg. English)
Structured Natural Language
Program syntax
Etc.
© 2003 - Dr. Ernest Cachia
Slide 9
The “Analyst”
Someone with the ability to capture user
and system needs at different levels
Someone who can envisage a system
from different aspects (points of view)
Someone who can communicate ideas
on a non-technical basis
Someone who can save (or cost) an
organisation a lot of effort and money
© 2003 - Dr. Ernest Cachia
Slide 10
The importance of specification
(1/2)
Requirements
56%
Designing
27%
“Other”
10%
Coding
7%
© 2003 - Dr. Ernest Cachia
• Distribution of s/w errors
Slide 11
The importance of specification
(2/2)
Requirements
82%
Designing
13%
Coding
1%
• Error rectification costs
© 2003 - Dr. Ernest Cachia
“Other”
4%
Slide 12
The Specification Process
Generally referred to as Systems
Analysis
Systems Analysis:
“A problem solving technique that
decomposes a system into its component
pieces for the purpose of studying how well
those component parts work and interact to
accomplish their purpose” [J. L. Whitten]
© 2003 - Dr. Ernest Cachia
Slide 13
Visual Flow of System Analysis
The issue
Business Case
Feasibility Study
Scope, budget,
schedule, resources, etc.
The development
team
Ideas, structure,
reports, etc.
Decision Analysis
© 2003 - Dr. Ernest Cachia
Authorisation and
Problem definition
Statement of
Requirements
Problem Analysis
Physical factors
Finalised system
Refinements,
objectives
priorities, etc
Requirements
Analysis
Slide 14
© 2003 - Dr. Ernest Cachia
Slide 15
The Model-Driven Approach
Structured Analysis
Process-centred
Information Engineering
Data-centred
Object-Oriented Analysis
Both process and data-centred (i.e. objectcentred)
© 2003 - Dr. Ernest Cachia
Slide 16
The Accelerated Analysis Approach
Discovery Prototyping
Involves the use of cheap and fast partial
implementation of certain system features
Prototypes allow system stakeholders to
learn about the final system
Rapid Architecture
Based on reverse engineering principles
Don’t re-invent the wheel – understand its
function and improve on it!
© 2003 - Dr. Ernest Cachia
Slide 17
System Planning
Moving on to System Planning
© 2003 - Dr. Ernest Cachia
Slide 18
What is (and isn’t) System Planning
A formal definition: “An outline, sketch, or
layout of the form or structure of a work.” Random House College Dic. (1972) – modified by author
Software system planning: “transforming
what is required to be done (i.e. the task)
into a blueprint of how a solution is to be
achieved” - Autor (1997)
System planning does not guarantee
correctness or uniqueness of a particular
solution
© 2003 - Dr. Ernest Cachia
Slide 19
Goal of Software System Planning
To obtain the smoothest possible
transition from “what is” to “how is” a
solution obtained
Offer tools (graphic) and guidelines to
facilitate problem comprehension and its
transition to “how” to plan its construction
Offer some sort of criteria by which to
gauge the quality of a specific solution
© 2003 - Dr. Ernest Cachia
Slide 20
How Does System Planning Help?
Better s/w system understandability
Improved system reliability
Better s/w system flexibility
Longer system durability (effective use)
Smoother s/w development process
Better end-user efficiency
© 2003 - Dr. Ernest Cachia
Slide 21
Effort Associated with System
Planning
More thought (re. the s/w system)
More discipline (both thought & actions)
Training in the use of specific tools
Training in the use of specific techniques
© 2003 - Dr. Ernest Cachia
Slide 22
The situation till very recently
Little or no requirements specification
Little or no system specification
Only cosmetic system architecture design
System planning was more a “forced”
activity than recognised need
Difficult system component integration
Primitive (usually empirical) testing
Large maintenance costs (~75%)
© 2003 - Dr. Ernest Cachia
Slide 23
How Did We Get Here?
Historical evolution (good programmers
are not necessarily good designers)
The nature of software has radically and
rapidly changed (and is constantly
changing) to reflect changes in our
society
Plain laziness and human (sometimes)
rebellious nature
© 2003 - Dr. Ernest Cachia
Slide 24
Know your enemy (meaning task)
Clear your mind of pre-conception as to
which model your system is to follow
Never try to force a design on to a model
Leave “how” to as later on as possible
“What” should lead to “how” not vice-versa
© 2003 - Dr. Ernest Cachia
Slide 25
Major thrusts of System Planning
System simplification
Natural Hierarchical system structure
Graphic tools (methods)
Design elaboration (overall & detailed)
Design solution evaluation
© 2003 - Dr. Ernest Cachia
Slide 26
System Simplification
Divide & conquer (Julius Caesar)
– Identify “isolatable” tasks within a larger one
– Tackle smaller tasks at different levels of design
– Design the right relationship between tasks
– Design system structure using tasks as blocks
Black-Box concept (also Mr. J. Caesar)
– Clearly defined I/O
– Clearly defined function
– Internals may be ignored (at that given point)
© 2003 - Dr. Ernest Cachia
Slide 27
Hierarchical System Organisation
Very old concept (even older than J. C.)
Permeates our whole existence
Tantamount to nature itself
e.g.
– The Universe: Galaxies, star-clusters, solar
systems, planets, land masses, continents,…
sub-atomic particles, and who knows what else!
– Company structures
– Government establishments
– Society, etc.
© 2003 - Dr. Ernest Cachia
Slide 28
Graphic Tools
A picture is (can be) worth a thousand
words - this is a physiological fact that
has to do with brain evolution
Examples of graphic tools for design
and specification include
Structure Charts (SCs)
Data Flow Diagrams (DFDs)
Structure Diagrams (SDs)
(Good old) Flow Charts (FCs)
© 2003 - Dr. Ernest Cachia
Slide 29
Design Elaboration
Definitely requires a precise well-defined
problem statement (i.e. a good
specification)
Guidelines and general strategies by
which to smoothly transit from
specification representations to design
ones
Will progress through different levels
© 2003 - Dr. Ernest Cachia
Slide 30
Design Solution Evaluation
Software is by nature prone to intense
subjectivity
Subjective entities are very difficult to quantify
of qualify (criteria might vary)
Any design solution can only be evaluated
with respect to the specification of the
problem being solved
A good design has definite demonstrable
properties
© 2003 - Dr. Ernest Cachia
Slide 31
Summary
Structured design attempts to impose
some form of discipline on activities that
were traditionally ad hoc (i.e. haphazard)
The main aspects of structured design:
– force the problem to guide the solution
– improving system understandability
– use of system modeling tools
– use of strategies to move from “what” to “how”
– provide criteria by which to evaluate system
quality
© 2003 - Dr. Ernest Cachia
Slide 32
The “Designer”
Risks…
Never heard of him/her (no job title)
No specific job description
Can take on different meanings
(depending on the background or
interest of who tackles it)
Is generally considered to be either an
analyst or a programmer
© 2003 - Dr. Ernest Cachia
Slide 33
The way one treats design (1/2)
Should be associated with experienced
programmers more than with analysts
– Programmers deal in terms of code so they
should be in a better position to apply design to
specific parts of the software system
– Analysts deal in terms of strategies and general
software system layouts so their idea of design
is usually very generic
Should be approached as objectively as
possible
© 2003 - Dr. Ernest Cachia
Slide 34
The way one treats design (2/2)
Should ALWAYS be taken very seriously
Should ALWAYS precede coding
Should NEVER be bound to a specific
form of coding (eg. a particular
programming language)
Should be used to help simplify matters
rather than show how complicated a
system is
© 2003 - Dr. Ernest Cachia
Slide 35
Identifying “sick” software
It’s unreliable (numerous bugs or breaks
down often)
It’s difficult to manage and maintain
It’s difficult to alter
It’s not that good an aid to your work
efforts and/or productivity
It’s difficult to come to terms with
© 2003 - Dr. Ernest Cachia
Slide 36
The main phases in the software
development process
1. Specifying the requirements of the
system
2. Specifying the system itself
3. Designing the system
4. Implementing the system
5. Testing the system
6. Maintaining the system
© 2003 - Dr. Ernest Cachia
Slide 37
Implications from development
The more time you invest in thinking
about and planning your software the
less time you will spend testing and
maintaining it
The amount of thought effort spent on
coding should be very minimal
The earlier (in the development process)
an error is detected the it costs to rectify
© 2003 - Dr. Ernest Cachia
Slide 38
Some graphic examples of s/w
development effort spread
Specification
10%
Designing
15%
Requirements
10%
Coding
20%
Testing
45%
© 2003 - Dr. Ernest Cachia
Slide 39
Some graphic examples of s/w
development cost spread
Coding 7%
Designing 5%
Testing 15%
Specification 3%
Requirements 3%
Maintenance 67%
© 2003 - Dr. Ernest Cachia
Slide 40
What is “un-maintainable”
An un-maintainable systems is one that is:
Difficult to comprehend
Difficult to assess its requirements impact
Difficult to test (“fully”)
Difficult to change any of its aspects
Difficult to establish which parts need to be
changed
Has confusing (mis-matching) documentation
© 2003 - Dr. Ernest Cachia
Slide 41
Basic design elements
Consider such elements as...
The module
The data
The relationships
Apply to them the basic principles of...
 Abstraction
Formality
 Divide and conquer
 Hierarchical ordering
© 2003 - Dr. Ernest Cachia
Slide 42
The module
Abstract entity (not necessarily a procedure)
Completely non-hardware dependent
entity
Self-contained entity
Fully (fromally) defined entity (both
functional and structural)
Entity to localise system functionality
Basic “non-decomposable” entity
© 2003 - Dr. Ernest Cachia
Slide 43
Module attributes
Name or meaningfull identification
Input (required data)
Output (produced data)
Function (converting input to output)
Communication details (interfacing)
Mechanics (internal actions)
Internal data (data used solely by module)
© 2003 - Dr. Ernest Cachia
Slide 44
Module example
…….
Module interface
Module implementation
(aka Module body)
© 2003 - Dr. Ernest Cachia
The module
Slide 45
Various module implementations
In Pascal: Procedure, function, unit
In C: Function
In Modula-2: Module interface and its
implementation
In English: Paragraph, section, chapter
In drawings: Quadrilateral, circle, specific
symbols, etc.
In Assembly: Routines
In human thought: Module!
© 2003 - Dr. Ernest Cachia
Slide 46
The data
Abstract entity
Internal or external (to module) entity
Share-able entity
Decompose-able entity
Completely non-hardware dependent
entity
Communicate-able
© 2003 - Dr. Ernest Cachia
Slide 47
Data attributes
Name or meaningfull identification
Type
Structure
Nature (control or information-driven)
Location(s)
Passage (source-destination)
© 2003 - Dr. Ernest Cachia
Slide 48
Data examples
(a)
Module A
destination co-ordinates
Module B
completion signal
Module X
(b)
count, index: integer;
temp_xcoords: array[1..10] of integer;
temp_ycoords: array[1..10] of integer;
complete: boolean;
© 2003 - Dr. Ernest Cachia
Slide 49
Various data representations
In programming languages: Declarations,
implicit use, explicit naming conventions,
etc.
In natural languages: Facts, principles,
subjects, quantities, values, measures,
etc.
In drawings: Text, directed arcs, specific
symbols, etc.
In human thought: Data!
© 2003 - Dr. Ernest Cachia
Slide 50
The relationships
Abstract entities
Completely non-hardware dependent
entities
Qualifiable entities
Highly structure-dependent entities
Data-passage related entities
Basic “non-decomposable” entity
© 2003 - Dr. Ernest Cachia
Slide 51
Relationship attributes
Name or meaningfull identification
Type
Explicit/Implicit
Structural/Procedural
Single/Multiple
Nature
Data motivated
Control motivated
© 2003 - Dr. Ernest Cachia
Slide 52
Relationship examples
system X
get value
get data
validate
data
(a) Structural, explicit and
single
transaction 1
transaction
processing
(c) Structural, explicit
and multiple
© 2003 - Dr. Ernest Cachia
transaction 2
transaction n
component
A
component
B
(b) Structural, implicit and
single
do A
do B
(d) Procedural, explicit and
single
Slide 53
Various relationship representations
In programming languages: Global and
non-local variables, parameter passing,
control structure, etc.
In natural languages: Reasoning sequence,
topic relevance, point-by-point elaboration,
presentation of details, etc.
In drawings: Directed and un-directed arcs,
symbol locations, specific symbols, etc.
In human thought: Relationships!
© 2003 - Dr. Ernest Cachia
Slide 54
Fundamental design strategies
 Functional structuring
Describe a system in terms of the functions of its different
parts
 Object structuring
Describe a system as a collection of objects of which it is
composed
 Data
structuring
Describe a system in relation to the data structures it uses
 No
structuring
Pretty obvious meaning - I think!
© 2003 - Dr. Ernest Cachia
Slide 55
ABS example - the system
CAR Anti-skid Braking System (ABS)
ABS computer
Electro-hydraulic
brake servo unit
wheel 1
Wheel
speed
sensor
Electro-hydraulic
brake servo unit
Wheel
speed
sensor
wheel 2
Hydraulic supply
© 2003 - Dr. Ernest Cachia
Slide 56
ABS functional structuring
Measure
wheel speed
function 3
Calculate
wheel accel./
decelerations
function 2
Store
measured
data
function 4
Output
commands to
brake servos
function 1
wheel
sensors
© 2003 - Dr. Ernest Cachia
brake
servo
units
Slide 57
ABS object structuring
speed signal
ABS computer
wheel 1
© 2003 - Dr. Ernest Cachia
actuator command
wheel 2
wheel 4
wheel 3
Slide 58
ABS object structuring (altered)
speed signal
ABS computer
Display
unit
actuator command
wheel 4
wheel 3
wheel 1
wheel 2
TP
© 2003 - Dr. Ernest Cachia
TP
TP
Diagnostic
computer
Slide 59
ABS data structuring
wheel
sensor
info.
data input
processes
© 2003 - Dr. Ernest Cachia
transform
data process
data output
processes
internal data
wheel
sensor
info.
Slide 60
The Structure Chart
Diagrammatic tool
Assumes partioning of s/w in modules
Easy to learn
Easy to use
Easy to understand
Explicit in meaning
Represents modules, data & relationships
© 2003 - Dr. Ernest Cachia
Slide 61
Structure chart (main) notation
Symbol for a module (one being designed)
Symbol for a pre-defined module (eg. a library)
Symbol for a relationship
Symbol for control-driven data
Symbol for information-driven data
© 2003 - Dr. Ernest Cachia
Slide 62
Some basic Structure Chart
notation issues (1)
Fan-in (relationship to more than one parent)

Fan-out (relationship to more than one child)
© 2003 - Dr. Ernest Cachia
Slide 63
Some basic Structure Chart
notation issues (2)

Cross-over (possibly due to fan-in)
Two valid solutions are as follows:
A
A
A
© 2003 - Dr. Ernest Cachia
Slide 64
Some basic Structure Chart
notation issues (3)

Continuity (possibly due structure size)
Module X
(From p. 1)
Module X
(See p. n)
page 1
page 2
page n
© 2003 - Dr. Ernest Cachia
Slide 65
Some basic Structure Chart
notation issues (4)

Iterative invocation (when one action is
made up of more than one repeated smaller
ones)
Module X
Module X
n
Module Y
X invokes Y
undefined times
© 2003 - Dr. Ernest Cachia
Module Y
X invokes Y a
max. of n times
Module X
exactly n
Module Y
X invokes Y
exactly n times
Module X
n
m
Module Y
X invokes Y any
no. of times from
n to m
Slide 66
Some basic Structure Chart
notation issues (5)

Code inclusion (considered as physical
integration with logical separation)
Module X
Module Y is actually code in module X
Module Y

Information clusters (localised manipulation
of complex data structures)
Module A B C
...
n
Data structure
© 2003 - Dr. Ernest Cachia
Slide 67
Some basic Structure Chart
notation issues (6)

Transaction centre (considered as a way of
“selection” of one from many possible functions
at any one specific moment)
Module A
Module B
Module C
Module D
In this example module A’s function can be the function
of either one of modules B, C or D
© 2003 - Dr. Ernest Cachia
Slide 68
Module specification
 Specify
its interface
 Specify its function
Descriptive
– eg. Natural language
Instructional
– eg. Pseudo-code
Directly implementable
– eg. Programming language
© 2003 - Dr. Ernest Cachia
Slide 69