SoftwareEngineering

Lecture 2

Vladimir Safonov,Professor, head of laboratory

St. Petersburg University

Email: v_o_safonov@mail.ru

WWW: http://user.rol.ru/~vsafonov

(C) Vladimir O. Safonov, 2004 2

Structured programming

• BS (Bowl-of-Spaghetti) programs• C. Boehm, J.Jacopini (1966): theoretically proved that

any application can be transformed into functionally equivalent one, with the following constructs used only:

Sequence of statements: S1; S2 Conditional statement: if B then S “While” loop: while B do S (Optional) procedure/function call: P(X1, … Xn)

• E.W.Dijkstra: “GOTO statement considered harmful”,

1968

(C) Vladimir O. Safonov, 2004 3

References on the topic

1. Hughes J., Michtom J. The structured approach to programming. – Addison-Wesley, 1977.

2. Yourdon E. The structured design and construction of programs. – Prentice Hall, 1976.

3. Dijkstra E. Notes on structured programming. – Comm. ACM, 1972.

4. Wirth N. Systematic programming: an introduction. – Addison-Wesley, 1975.

(C) Vladimir O. Safonov, 2004 4

The principles of structured programming

• Using the limited set of constructs – sequence of statements, if statement, while statement, case (switch) statement, and exception handlind constructs (try/catch – C++, Java, C#; signal/except/when – CLU, etc.)

• No use of GOTO, or, at least, structured use of GOTO: only for terminating a structured construct by goto a label immediately following the construct: { … GOTO M; … } M:

• Stepwise refinement as the method of program design and implementation: step-by-step detailization of program structure, using pseudocode

• Using mnemonic names for labels and “pseudo-procedures” to indicate the logical steps of the algorithm, e.g.:

INITIALIZATION: … PROCESS_INPUT_STREAM: …

(C) Vladimir O. Safonov, 2004 5

“Non-structured” programming and improper use of GOTO (what should be

avoided)

• GOTO from one alternative of a CASE statement to another one: CASE x OF C1: S1; GOTO C3; C2: S2; C3: S3 END

• Arbitrary use of GOTO for the purpose of “patching” the program (looks especially confusing in assembler sources)

• Fall through:

SWITCH (x) {CASE C1: S1; /* FALLTHRU */ CASE C2: S2; }

• No exception handling, no error recovery

• No DEFAULT alternative in a SWITCH statement

(C) Vladimir O. Safonov, 2004 6

Stepwise refinement

P

/ \ Pseudocode (variations) :

P1 … Pn PROCEDURE P;

/ \ BEGIN P1; … Pn END;

Q1 … Qm …

PROCEDURE P1;

BEGIN IF B1 THEN Q1 … ELSE Qm

- Structured programming constructs are pseudo-statements;

- Finally, even if the implementation language is low-level,

in the resulting code the initial pseudocode structure is preserved (at least in the form of comments)

(C) Vladimir O. Safonov, 2004 7

Advantages of structured approach

• Clear and systematic style

• Easy rapid prototyping

• Parallelizing the stages of design and implementation

• Increasing reliability

• Specification and formalization of each step is possible

(C) Vladimir O. Safonov, 2004 8

Shortcomings of structured approach

• Difficult to design data (definitions, etc.) in the same “top-down” style

• Any change may require major redesign and recoding

• Danger of delivering low quality code

• Bad opportunity to use poor skilled “coders”

(C) Vladimir O. Safonov, 2004 9

Summary

• Structured programming is an inherent part of modern programming culture

• Using only structured approach is not enough: it fits for design and coding statements only

• Other approaches are necessary, to decompose programs into independent parts, and also to enable convenient and reliable design and implementation of data structures

• Modular programming; abstract data types (the next topics of our course)

(C) Vladimir O. Safonov, 2004 10

Modular programming

• Founders – Glenford Myers, David Parnas (1970s)

• Russian classicist of modularity – Gregory Tseytin

(“Towards assembly programming”. - in: “Programming”, 1990, # 1)

• The concept of programming module is taken from electronics (module is a replaceable block with minimal precisely specified contacts, or interface, and some definite functionality)

(C) Vladimir O. Safonov, 2004 11

Principles of modular approach

• Module – a relatively independent program unit with an explicit definition, uses (or calls), functionality, interface (contacts) with the rest of the application, and the ways of error handling

• An application is decomposed into modules at the design stage

• Module specifications are developed by highly skilled system analysts

• Implementation of modules is parallelized

• Module = interface + implementation

• Module – a unit of programming knowledge (G. Tseytin)

(C) Vladimir O. Safonov, 2004 12

Home task to lecture 2

• Please read and learn the classical papers by G. Myers and D. Parnas on modular programming.