Principles of Structured System Development CSA 2821

Principles of Structured System Development (CSA 2821 – 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 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. ” 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 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 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 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) 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 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. 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 10

The importance of specification (1/2) Requirements 56% Designing 27% “Other” 10% Coding 7% • Distribution of s/w errors 11

The importance of specification (2/2) Requirements 82% Designing 13% Coding 1% • Error rectification costs “Other” 4% 12

The Specification Process Generally referred to as 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 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 Statement of Requirements Authorisation and Problem definition Problem Analysis Physical factors Finalised system Refinements, objectives priorities, etc Requirements Analysis 14

© 2003 - Dr. Ernest Cachia 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 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 17

System Planning Moving on to System Planning © 2003 - Dr. Ernest Cachia 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 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 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 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 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%) 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 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 25

Major thrusts of System Planning System simplification Natural Hierarchical system structure Graphic tools (methods) Design elaboration (overall & detailed) Design solution evaluation 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) 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. 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) 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 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 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 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 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 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 complicated a system is 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 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 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 38

Some graphic examples of s/w development effort spread Specification 10% Designing 15% Requirements 10% Coding 20% Testing 45% 39

Some graphic examples of s/w development cost spread Coding 7% Designing 5% Testing 15% Specification 3% Requirements 3% Maintenance 67% 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 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 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 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) 44

Module example ……. Module interface Module implementation (aka Module body) The module 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! 46

The data Abstract entity Internal or external (to module) entity Share-able entity Decompose-able entity Completely non-hardware dependent entity Communicate-able 47

Data attributes Name or meaningfull identification Type Structure Nature (control or information-driven) Location(s) Passage (source-destination) 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; 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! 50

The relationships Abstract entities Completely non-hardware dependent entities Qualifiable entities Highly structure-dependent entities Data-passage related entities Basic “non-decomposable” entity 51

Relationship attributes Name or meaningfull identification Type Explicit/Implicit Structural/Procedural Single/Multiple Nature Data motivated Control motivated 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 transaction 2 transaction n component A component B (b) Structural, implicit and single do A do B (d) Procedural, explicit and single 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! 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! 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 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 brake servo units 57

ABS object structuring speed signal com d sig spe na l act uat or d an m spee d sig nal om rc actu ator ee o at wheel 1 actuator command sp tu ac man d ABS computer wheel 2 ed s wheel 4 com ign a l ma nd wheel 3 58

ABS object structuring (altered) ABS computer spe ed sig nal ma nd om or c uat act an d rni wa wheel 3 TP ng TP sig na l co mm re su display data ato r ee d tyre pressure (TP) ac tu res TP wheel 4 sp ep wheel 2 actuator command tyr wheel 1 speed signal actuator command Display unit speed signal Diagnostic computer 59

ABS data structuring wheel sensor info. data input processes transform data process data output processes internal data wheel sensor info. 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 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 62

Some basic Structure Chart notation issues (1) Fan-in (relationship to more than one parent) l Fan-out (relationship to more than one child) 63

Some basic Structure Chart notation issues (2) l Cross-over (possibly due to fan-in) Two valid solutions are as follows: A A A 64

Some basic Structure Chart notation issues (3) l Continuity (possibly due structure size) Module X (From p. 1) Module X (See p. n) page 1 page 2 page n 65

Some basic Structure Chart notation issues (4) l Iterative invocation (when one action is made up of more than one repeated smaller ones) Module X n Module Y X invokes Y undefined times 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 66

Some basic Structure Chart notation issues (5) l Code inclusion (considered as physical integration with logical separation) Module X Module Y is actually code in module X Module Y l Information clusters (localised manipulation of complex data structures) Module A B C . . . n Data structure 67

Some basic Structure Chart notation issues (6) l 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 68

Module specification ¬ Specify its interface Specify its function Descriptive – eg. Natural language Instructional – eg. Pseudo-code Directly implementable – eg. Programming language 69