1. Software Engineering Lecture 2 Vladimir Safonov, Professor, head of laboratory St. Petersburg University Email: v_o_safonov@mail.ru WWW: http://user.rol.ru/~vsafonov

2. (C) Vladimir O. Safonov, 20042 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

3. (C) Vladimir O. Safonov, 20043 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.

4. (C) Vladimir O. Safonov, 20044 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: …

5. (C) Vladimir O. Safonov, 20045 “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

6. (C) Vladimir O. Safonov, 20046 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)

7. (C) Vladimir O. Safonov, 20047 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

8. (C) Vladimir O. Safonov, 20048 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”

9. (C) Vladimir O. Safonov, 20049 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)

10. (C) Vladimir O. Safonov, 200410 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)

11. (C) Vladimir O. Safonov, 200411 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)

12. (C) Vladimir O. Safonov, 200412 Home task to lecture 2 Please read and learn the classical papers by G. Myers and D. Parnas on modular programming.