principles of structured system development csa2821 diploma course l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Principles of Structured System Development (CSA2821 – Diploma Course) PowerPoint Presentation
Download Presentation
Principles of Structured System Development (CSA2821 – Diploma Course)

Loading in 2 Seconds...

play fullscreen
1 / 69

Principles of Structured System Development (CSA2821 – Diploma Course) - PowerPoint PPT Presentation


  • 252 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Principles of Structured System Development (CSA2821 – Diploma Course)' - ostinmannual


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
principles of structured system development csa2821 diploma course

Principles of Structured System Development(CSA2821 – Diploma Course)

Dr. Ernest Cachia

Department of Computer Science & A. I.

who should you be
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

structured specification
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

i o requirements of specification
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

some specification properties
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

how does specification help
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

s w specification until recently
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

reasons for specification neglect
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-fingers-and-hope” attitude

© 2003 - Dr. Ernest Cachia

structured specification tools
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

the analyst
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

the importance of specification 1 2
The importance of specification (1/2)

Requirements

56%

Designing

27%

“Other”

10%

Coding

7%

  • Distribution of s/w errors

© 2003 - Dr. Ernest Cachia

the importance of specification 2 2
The importance of specification (2/2)

Requirements

82%

Designing

13%

Coding

1%

“Other”

4%

  • Error rectification costs

© 2003 - Dr. Ernest Cachia

the specification process
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

visual flow of system analysis
Visual Flow of System Analysis

Feasibility Study

The issue

Authorisation and

Problem definition

Scope, budget,

schedule, resources, etc.

Business Case

Problem Analysis

The development

team

Physical factors

Finalised system

objectives

Refinements,

priorities, etc

Ideas, structure,

reports, etc.

Statement of

Requirements

Decision Analysis

Requirements

Analysis

© 2003 - Dr. Ernest Cachia

the model driven approach
The Model-Driven Approach
  • Structured Analysis
    • Process-centred
  • Information Engineering
    • Data-centred
  • Object-Oriented Analysis
    • Both process and data-centred (i.e. object-centred)

© 2003 - Dr. Ernest Cachia

the accelerated analysis approach
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

system planning
System Planning

Moving on to System Planning

© 2003 - Dr. Ernest Cachia

what is and isn t system planning
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

goal of software system planning
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

how does system planning help
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

effort associated with system planning
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

the situation till very recently
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

how did we get here
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

know your enemy meaning task
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

major thrusts of system planning
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

system simplification
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

hierarchical system organisation
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

graphic tools
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

design elaboration
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

design solution evaluation
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

summary
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

the designer
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

the way one treats design 1 2
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

the way one treats design 2 2
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

identifying sick software
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

the main phases in the software development process
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

implications from development
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

some graphic examples of s w development effort spread
Some graphic examples of s/w development effort spread

Specification

10%

Designing

15%

Requirements

10%

Coding

20%

Testing

45%

© 2003 - Dr. Ernest Cachia

some graphic examples of s w development cost spread
Some graphic examples of s/w development cost spread

Testing 15%

Coding 7%

Designing 5%

Specification 3%

Requirements 3%

Maintenance 67%

© 2003 - Dr. Ernest Cachia

what is un maintainable
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

basic design elements
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

the module
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

module attributes
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

module example
Module example

…….

Module interface

Module implementation

(aka Module body)

The module

© 2003 - Dr. Ernest Cachia

various module implementations
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

the data
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

data attributes
Data attributes
  • Name or meaningfull identification
  • Type
  • Structure
  • Nature (control or information-driven)
  • Location(s)
  • Passage (source-destination)

© 2003 - Dr. Ernest Cachia

data examples
Data examples

Module A

Module B

destination co-ordinates

(a)

completion signal

Module X

count, index: integer;

temp_xcoords: array[1..10] of integer;

temp_ycoords: array[1..10] of integer;

complete: boolean;

(b)

© 2003 - Dr. Ernest Cachia

various data representations
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

the relationships
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

relationship attributes
Relationship attributes
  • Name or meaningfull identification
  • Type
    • Explicit/Implicit
    • Structural/Procedural
    • Single/Multiple
  • Nature
    • Data motivated
    • Control motivated

© 2003 - Dr. Ernest Cachia

relationship examples
Relationship examples

system X

get value

component

A

component

B

get data

validate

data

(a) Structural, explicit and

single

(b) Structural, implicit and

single

transaction 1

transaction

processing

do A

do B

transaction 2

transaction n

(c) Structural, explicit

and multiple

(d) Procedural, explicit and

single

© 2003 - Dr. Ernest Cachia

various relationship representations
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

fundamental design strategies
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

abs example the system
ABS example - the system

CAR Anti-skid Braking System (ABS)

ABS computer

Electro-hydraulic

brake servo unit

Wheel

speed

sensor

Electro-hydraulic

brake servo unit

Wheel

speed

sensor

wheel 1

wheel 2

Hydraulic supply

© 2003 - Dr. Ernest Cachia

abs functional structuring

function 1

Measure

wheel speed

function 3

Calculate

wheel accel./

decelerations

function 4

Output

commands to

brake servos

ABS functional structuring

wheel

sensors

function 2

Store

measured

data

brake

servo

units

© 2003 - Dr. Ernest Cachia

abs object structuring
ABS object structuring

ABS computer

wheel 4

speed signal

actuator command

speed signal

speed signal

actuator command

speed signal

actuator command

actuator command

wheel 3

wheel 1

wheel 2

© 2003 - Dr. Ernest Cachia

abs object structuring altered
ABS object structuring (altered)

ABS computer

wheel 4

speed signal

actuator command

Display

unit

speed signal

speed signal

actuator command

actuator command

speed signal

actuator command

wheel 3

tyre pressure (TP)

display data

tyre pressure warning

wheel 1

wheel 2

TP

TP

Diagnostic

computer

TP

© 2003 - Dr. Ernest Cachia

abs data structuring
ABS data structuring

wheel

sensor

info.

data input

processes

transform

data process

data output

processes

internal data

wheel

sensor

info.

© 2003 - Dr. Ernest Cachia

the structure chart
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

structure chart main notation
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

some basic structure chart notation issues 1
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

some basic structure chart notation issues 2
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

some basic structure chart notation issues 3
Some basic Structure Chart notation issues (3)
  • Continuity (possibly due structure size)

(From p. 1)

Module X

Module X

(See p. n)

page 1

page 2

page n

© 2003 - Dr. Ernest Cachia

some basic structure chart notation issues 4
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

Module X

Module X

exactly n

n

m

n

Module Y

Module Y

Module Y

Module Y

X invokes Y

undefined times

X invokes Y a

max. of n times

X invokes Y

exactly n times

X invokes Y any

no. of times from

n to m

© 2003 - Dr. Ernest Cachia

some basic structure chart notation issues 5
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

some basic structure chart notation issues 6
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

module specification
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