1

Last update: 30 March 2005 Software Architecture

Bertrand Meyer ETH Zurich, 30 March – 29 June 2005

Lecture 2: Software quality; principles and criteria of modularity

Chair of Software Engineering Software architecture Agenda for today 2

ƒ Software quality ƒ Modularity ƒ Reusability

Chair of Software Engineering Software architecture Reading assignment for next week 3

OOSC, chapters 3: Modularity 6: Abstract data types

Chair of Software Engineering Software architecture Software engineering 4

The collection of processes, methods, techniques, tools and languages for developing quality operational software.

Chair of Software Engineering Software architecture By the way… 5

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

Chair of Software Engineering Software architecture Software engineering 6

The collection of processes, methods, techniques, tools and languages for developing quality operational software.

Chair of Software Engineering Software architecture Software quality: external vs internal 7

ƒ External factors: visible to customers

(not just end users but e.g. purchasers)

ƒ Examples: ease of use, extendibility, timeliness

ƒ Internal factors: perceptible only to developers

ƒ Examples: good programming style, information hiding

Only external factors count in the end, but the internal factors make it possible to obtain them.

Chair of Software Engineering Software architecture Software quality: product vs process 8

ƒ Product: properties of the resulting software

For example: correctness, efficiency

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

Chair of Software Engineering Software architecture External quality factors 9

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

Chair of Software Engineering Software architecture Reliability 10

Correctness: The systems’ ability to perform according to specification, in cases covered by the specification

Robustness: The systems’ ability to perform reasonably in cases not covered by the specification

Security (integrity): The systems’ ability to protect itself against hostile use

Chair of Software Engineering Software architecture Security 11

Carcassonne, 13th century

Chair of Software Engineering Software architecture Security 12

Chambord, 16th century

Chair of Software Engineering Software architecture Security 13

Versailles, 17-18th century

Chair of Software Engineering Software architecture Security 14

“I think that it’s extraordinarily important that we in computer 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 complaints seriously. We began to feel as if we really were 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 External quality factors 15

ƒ CORRECTNESS ƒ ROBUSTNESS ƒ INTEGRITY

ƒ EASE OF USE ƒ REUSABILITY ƒ EXTENDIBILITY ƒ PORTABILITY ƒ EFFICIENCY ƒ …

ƒ 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 Reliability 16

ƒ Correctness + Robustness + Security

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

Chair of Software Engineering Software architecture Modularity 17

ƒ Reusability + Extendibility

ƒ Favored by architectural techniques tending to ensure decentralization of modules

Chair of Software Engineering Software architecture Modularity 18

ƒ Some principles of modularity: ƒ Decomposability ƒ Composability ƒ Continuity ƒ Information hiding ƒ The open-closed principle ƒ The single choice principle

Chair of Software Engineering Software architecture Decomposability 19

ƒ Method helps decompose complex problems into subproblems.

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

Chair of Software Engineering Software architecture Top-down functional design 20

Topmost functional abstraction

A

Sequence

BD C

Loop Conditional C1I I1 C2 I2

Chair of Software Engineering Software architecture Top-down design 21

ƒ See Niklaus Wirth, “Program Construction by Stepwise Refinement”, Communications of the ACM, 14, 4, (April 1971), p 221-227.

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

Chair of Software Engineering Software architecture Composability 22

ƒ Method favors production of software elements that may be freely combined with each other to produce new software.

ƒ Example: Unix shell conventions Program1 | Program2 | Program3

Chair of Software Engineering Software architecture Direct mapping 23

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

Chair of Software Engineering Software architecture Few interfaces principle 24

ƒ Every module communicates with as few others as possible.

(A) (B) (C)

Chair of Software Engineering Software architecture Small interfaces principle 25

ƒ If two modules communicate, they exchange as little information as possible.

x, y

z

Chair of Software Engineering Software architecture Explicit interfaces principle 26

ƒ Whenever two modules A and B communicate, this is obvious from the text of A or B or both.

Module A Module B

Modifies Accesses Data item x

Chair of Software Engineering Software architecture Continuity 27

ƒ Method ensures that small changes in specifications yield small changes in architecture.

ƒ Design method: Specification → Architecture

ƒ 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 Uniform Access Principle 28

ƒ Facilities managed by a module are accessible to its clients in the same way whether implemented by computation or by storage.

ƒ Definition: A client of a module is any module that uses its facilities.

Chair of Software Engineering Software architecture Uniform Access: An example 29

balance = list_of_deposits.total – list_of_withdrawals.total

list_of_deposits

(A1) list_of_withdrawals

balance

list_of_deposits (A2) list_of_withdrawals

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

Chair of Software Engineering Software architecture Information hiding 30

ƒ Underlying question: how does one “advertise” the capabilities of a module?

ƒ 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.

Chair of Software Engineering Software architecture Information Hiding Principle 31

ƒ The designer of every module must select a subset of the module’s properties as the official information about the module, to be made available to authors of client modules.

Chair of Software Engineering Software architecture Information hiding 32

Public part

Secret part

Chair of Software Engineering Software architecture Information hiding 33

ƒ Justifications: ƒ Continuity ƒ Decomposability

Chair of Software Engineering Software architecture The Open-Closed Principle 34

ƒ Modules should be open and closed.

ƒ Definitions: ƒ 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 An object has an interface 35

start item index forth put_right before after

Chair of Software Engineering Software architecture An object has an implementation 36

start item index forth put_right before after

Chair of Software Engineering Software architecture Information hiding 37

start item index forth put_right before after

Chair of Software Engineering Software architecture The Open-Closed principle 38

B A CE

D

FA’HI

G

Chair of Software Engineering Software architecture Closing modules prematurely 39

type PUBLICATION = record author, title: STRING; publication_year: INTEGER case pubtype: (book, journal, conference) of book: (publisher: STRING); journal: (editor: STRING); conference: (place, chair: STRING) end end

ƒ Use in clients:

p: PUBLICATION ; case p.pubtype of book: ... p.publisher ...; journal: ... p.editor ...; conference: ... p.place ... end

Chair of Software Engineering Software architecture 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.) ƒ Compiler: set of language constructs (instruction, loop, expression etc.)

Chair of Software Engineering Software architecture Reusability issues 41

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

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

Chair of Software Engineering Software architecture Reusability: Technical issues 42

ƒ The general pattern for a searching routine:

has (t: TABLE; x: ELEMENT): BOOLEAN is -- Does item x appear in table t? local pos: POSITION do from pos := initial_position (t, x) until exhausted (t, pos) or else found (t, x, pos) loop pos := next (t, x, pos) end Result := found (t, x, pos) end

Chair of Software Engineering Software architecture Issues for a general searching module 43

ƒ Type variation: ƒ What are the table elements?

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

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

Chair of Software Engineering Software architecture Issues 44

ƒ Representation independence:

ƒ Can a client request an operation such as table search (has) without knowing what implementation is used internally?

has (t1, y)

Chair of Software Engineering Software architecture Issues 45

ƒ Factoring out commonality: ƒ How can the author of supplier modules take advantage of commonality within a subset of the possible implementations?

ƒ Example: the set of sequential table implementations. ƒ A common routine text for has: has (....; x: T): BOOLEAN is -- Does x appear in the table? do from start until after or else found (x) loop forth end Result := found (x) end

Chair of Software Engineering Software architecture Factoring out commonality 46

before after item

1 count back forth

start index

Chair of Software Engineering Software architecture Factoring out commonality 47

TABLE has

start SEQUENTIAL_ TREE_ HASH_ after TABLE TABLE TABLE found forth

ARRAY_ LINKED_ FILE_ TABLE TABLE TABLE

Chair of Software Engineering Software architecture Implementation variants 48

start forth after found (x)

Array i := 1 i := i + 1 i > count t [i] = x

Linked list c := first_cell c := c.right c = Void c.item = x

File rewind read end_of_file f = ξ

Chair of Software Engineering Software architecture 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