1 Software engineering 4

Last update: 30 March 2005 The collection of processes, methods, techniques, Software Architecture tools and languages for developing quality operational software. ETH Zurich, 30 March – 29 June 2005

Lecture 2: ; principles and criteria of modularity

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Agenda for today 2 By the way… 5

ƒ Software quality “Software” is not just programs. It includes ƒ Modularity processes for producing and operating the ƒ Reusability programs, as well as all related documentation,

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Reading assignment for next week 3 Software engineering 6

OOSC, chapters The collection of processes, methods, techniques, 3: Modularity tools and languages for developing quality 6: Abstract data types operational software.

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

1 Software quality: external vs internal 7 Reliability 10

ƒ External factors: visible to customers Correctness: (not just end users but e.g. purchasers) The systems’ ability to perform according to specification, in cases covered by the specification ƒ Examples: ease of use, extendibility, timeliness Robustness: The systems’ ability to perform reasonably in ƒ Internal factors: perceptible only to developers cases not covered by the specification

ƒ Examples: good programming style, Security (integrity): information hiding The systems’ ability to protect itself against hostile use Only external factors count in the end, but the internal factors make it possible to obtain them.

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Software quality: product vs process 8 Security 11

ƒ Product: properties of the resulting software

For example: correctness, efficiency

ƒ Process: properties of the procedures used to produce and “maintain” the software

Carcassonne, 13th century

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

External quality factors 9 Security 12

Product quality (immediate): ƒ Correctness ƒ Robustness ƒ Security ƒ Ease of use ƒ Ease of learning ƒ Efficiency

Product quality (long-term): Specification Errors Hostility ƒ Extendibility ƒ Reusability ƒ Portability

Process quality: ƒ Timeliness ƒ Cost-effectiveness Correctness Correctness Security Chambord, 16th century

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

2 Security 13 Reliability 16

ƒ Correctness + Robustness + Security

ƒ Techniques will be studied in detail: typing, Design by Contract, …

Versailles, 17-18th century

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Security 14 Modularity 17

“I think that it’s extraordinarily important that we in computer ƒ Reusability + Extendibility science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their ƒ Favored by architectural techniques tending to complaints seriously. We began to feel as if we really were ensure decentralization of modules responsible for the successful, error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them, setting them off in new directions, and keeping fun in the house.”

Alan Perlis, Preface to The Structure and Interpretation of Computer programs by Abelson and Sussman

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

External quality factors 15 Modularity 18

ƒ CORRECTNESS ƒ Some principles of modularity: ƒ ROBUSTNESS ƒ INTEGRITY ƒ Decomposability ƒ Composability ƒ EASE OF USE ƒ REUSABILITY ƒ Continuity ƒ EXTENDIBILITY ƒ Information hiding ƒ PORTABILITY ƒ The open-closed principle ƒ EFFICIENCY ƒ … ƒ The single choice principle

ƒ Correctness: ƒ The ability of a software system to perform according to specification, in cases defined by the specification. ƒ Robustness: ƒ The ability of a software system to react in a reasonable manner to cases not covered by the specification.

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

3 Decomposability 19 Composability 22

ƒ Method helps decompose complex problems into ƒ Method favors production of software elements that may be subproblems. freely combined with each other to produce new software.

ƒ COROLLARY: Division of labor. ƒ Example: Top-down design method (see next). ƒ Counter-example: General initialization module.

ƒ Example: Unix shell conventions Program1 | Program2 | Program3

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Top-down functional design 20 Direct mapping 23

ƒ Method yields software systems whose modular Topmost functional abstraction structure remains compatible with any modular A structure devised in the process of modeling the problem domain. Sequence

BD C

Loop Conditional C1I I1 C2 I2

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Top-down design 21 Few interfaces principle 24

ƒ See Niklaus Wirth, “Program Construction by ƒ Every module communicates with as few others as Stepwise Refinement”, Communications of the possible. ACM, 14, 4, (April 1971), p 221-227.

http://www.acm.org/classics/dec95/

(A) (B) (C)

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

4 Small interfaces principle 25 Uniform Access Principle 28

ƒ If two modules communicate, they exchange as ƒ Facilities managed by a module are accessible to little information as possible. its clients in the same way whether implemented by computation or by storage.

ƒ Definition: A client of a module is any module that x, y uses its facilities. z

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Explicit interfaces principle 26 Uniform Access: An example 29

ƒ Whenever two modules A and B communicate, this balance = list_of_deposits.total – list_of_withdrawals.total is obvious from the text of A or B or both. list_of_deposits

(A1) list_of_withdrawals Module A Module B balance

Modifies Accesses list_of_deposits Data item (A2) list_of_withdrawals x

Ada, Pascal, C/C++, Java, C#: Simula, Eiffel: a.balance a.balance balance (a) a.balance()

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Continuity 27 Information hiding 30

ƒ Method ensures that small changes in ƒ Underlying question: how does one “advertise” the specifications yield small changes in architecture. capabilities of a module?

ƒ Design method: Specification → Architecture ƒ Every module should be known to the outside world through an official, “public” interface. ƒ The rest of the module’s properties comprises its “secrets”. ƒ It should be impossible to access the secrets from the outside. ƒ Example: Principle of Uniform Access (see next) ƒ Counter-example: Programs with patterns after the physical implementation of data structures.

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

5 Information Hiding Principle 31 The Open-Closed Principle 34

ƒ The designer of every module must select a subset ƒ Modules should be open and closed. of the module’s properties as the official information about the module, to be made ƒ Definitions: available to authors of client modules. ƒ Open module: May be extended. ƒ Closed module: Usable by clients. May be approved, baselined and (if program unit) compiled.

ƒ The rationales are complementary: ƒ For closing a module (manager’s perspective): Clients need it now. ƒ For keeping modules open (developer’s perspective): One frequently overlooks aspects of the problem.

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Information hiding 32 An object has an interface 35

Public part

Secret part

start item index forth put_right before after

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Information hiding 33 An object has an implementation 36

ƒ Justifications: ƒ Continuity ƒ Decomposability

start item index forth put_right before after

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

6 Information hiding 37 The Single Choice principle 40

ƒ Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list.

ƒ Editor: set of commands (insert, delete etc.) ƒ Graphics system: set of figure types (rectangle, circle etc.)

start item index ƒ : set of language constructs (instruction, forth loop, expression etc.) put_right before after

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

The Open-Closed principle 38 Reusability issues 41

ƒ Organizational and managerial issues: B A CE ƒ (Not covered here.)

D ƒ Technical issues: what form of components? ƒ Routine libraries ƒ Packages (Ada) ƒ Class libraries FA’HI ƒ What form of classes?

G

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Closing modules prematurely 39 Reusability: Technical issues 42

type PUBLICATION = ƒ The general pattern for a searching routine: record author, title: STRING; publication_year: INTEGER has (t: TABLE; x: ELEMENT): BOOLEAN is case pubtype: (book, journal, conference) of -- Does item x appear in table t? book: (publisher: STRING); local journal: (editor: STRING); pos: POSITION conference: (place, chair: STRING) do end from end pos := initial_position (t, x) until ƒ Use in clients: exhausted (t, pos) or else found (t, x, pos) loop p: PUBLICATION ; pos := next (t, x, pos) case p.pubtype of end book: ... p.publisher ...; journal: ... p.editor ...; Result := found (t, x, pos) conference: ... p.place ... end end

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

7 Issues for a general searching module 43 Factoring out commonality 46

ƒ Type variation: before after item ƒ What are the table elements?

ƒ Routine grouping: ƒ A searching routine is not enough: it should be coupled with routines for table creation, 1 count insertion, deletion etc. back forth

ƒ Implementation variation: start index ƒ Many possible choices of data structures and : sequential table (sorted or unsorted), array, binary search tree, file, ...

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Issues 44 Factoring out commonality 47

ƒ Representation independence: TABLE has

ƒ Can a client request an operation such as table search (has) without knowing what start SEQUENTIAL_ TREE_ HASH_ implementation is used internally? after TABLE TABLE TABLE found forth has (t1, y) ARRAY_ LINKED_ FILE_ TABLE TABLE TABLE

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

Issues 45 Implementation variants 48

ƒ Factoring out commonality: ƒ How can the author of supplier modules take start forth after found (x) advantage of commonality within a subset of the possible implementations?

ƒ Example: the set of sequential table Array i := 1 i := i + 1 i > count t [i] = x implementations. ƒ A common routine text for has: Linked list c := first_cell c := c.right c = Void c.item = x has (....; x: T): BOOLEAN is -- Does x appear in the table? do File rewind read end_of_file f = ξ from start until after or else found (x) loop forth end Result := found (x) end

Chair of Software Engineering Software architecture Chair of Software Engineering Software architecture

8 Encapsulation languages (“Object-based”) 49

ƒ Ada, Modula-2, CLU...

ƒ Basic idea: gather a group of routines serving a related purpose, such as has, insert, remove etc., together with the appropriate data structure descriptions.

ƒ This addresses the Related Routines issue.

ƒ Advantages: ƒ For supplier author: Get everything under one roof. Simplifies configuration management, change of implementation, addition of new primitives. ƒ For client author: Find everything at one place. Simplifies search for existing routines, requests for extensions.

Chair of Software Engineering Software architecture

Complementary material 50

ƒ OOSC2: ƒ Chapter 3: Modularity ƒ Chapter 4: Approaches to reusability

Chair of Software Engineering Software architecture

51

End of lecture 2

Chair of Software Engineering Software architecture

9