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. Bertrand Meyer ETH Zurich, 30 March – 29 June 2005
Lecture 2: Software quality; 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 Compiler: 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 algorithms: 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