info4 02 modularity reusability -...

Programming in the large - Lecture 2

1

Chair of Software Engineering

Programming in the large

Bertrand Meyer

Last update: 16 April 2004

Programming in the large - Lecture 2

2

Chair of Software Engineering

Lecture 2: Modularity, Reusability

Programming in the large - Lecture 2

3

Chair of Software Engineering

Agenda for today

Software qualityModularityReusability

Programming in the large - Lecture 2

4

Chair of Software Engineering

Software quality

External factors: visible to customers

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

Examples: ease of use, extendibility

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.

Programming in the large - Lecture 2

5

Chair of Software Engineering

External quality factors

CORRECTNESSROBUSTNESSINTEGRITY

EASE OF USEREUSABILITYEXTENDIBILITYPORTABILITYEFFICIENCY…

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.

Correctness

RobustnessIntegrity

HOSTILE USEERRORSSPECIFICATION

Programming in the large - Lecture 2

6

Chair of Software Engineering

Reliability

Correctness + Robustness

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

Programming in the large - Lecture 2

7

Chair of Software Engineering

Modularity

Reusability + Extendibility

Favored by architectural techniques tending to ensure decentralization of modules

Programming in the large - Lecture 2

8

Chair of Software Engineering

Modularity

Some principles of modularity:Decomposability ComposabilityContinuity Information hiding The open-closed principle The single choice principle

Programming in the large - Lecture 2

9

Chair of Software Engineering

Decomposability

Method helps decompose complex problems into subproblems.

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

Programming in the large - Lecture 2

10

Chair of Software Engineering

Top-down functional design

A

B D C

C1 I1 C2 I2I

Topmost functional abstraction

Loop Conditional

Sequence

Programming in the large - Lecture 2

11

Chair of Software Engineering

Top-down design

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/

Programming in the large - Lecture 2

12

Chair of Software Engineering

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

Example: Unix shell conventionsProgram1 | Program2 | Program3

Composability

Programming in the large - Lecture 2

13

Chair of Software Engineering

Direct mapping

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

Programming in the large - Lecture 2

14

Chair of Software Engineering

Few interfaces principle

Every module communicates with as few others as possible.

(A) (B) (C)

Programming in the large - Lecture 2

15

Chair of Software Engineering

Small interfaces principle

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

x, y

z

Programming in the large - Lecture 2

16

Chair of Software Engineering

Explicit interfaces principle

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

Module A Module B

Data item

x

Modifies Accesses

Programming in the large - Lecture 2

17

Chair of Software Engineering

Continuity

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.

Programming in the large - Lecture 2

18

Chair of Software Engineering

Uniform Access Principle

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.

Programming in the large - Lecture 2

19

Chair of Software Engineering

Uniform Access: An example

balance = list_of_deposits.total – list_of_withdrawals.total

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

list_of_deposits

list_of_withdrawals

balance

list_of_deposits

list_of_withdrawals(A2)

(A1)

Programming in the large - Lecture 2

20

Chair of Software Engineering

Information hiding

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.

Programming in the large - Lecture 2

21

Chair of Software Engineering

Information Hiding Principle

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.

Programming in the large - Lecture 2

22

Chair of Software Engineering

Information hiding

Secret part

Public part

Programming in the large - Lecture 2

23

Chair of Software Engineering

Information hiding

Justifications:ContinuityDecomposability

Programming in the large - Lecture 2

24

Chair of Software Engineering

The Open-Closed Principle

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.

Programming in the large - Lecture 2

25

Chair of Software Engineering

An object

startforth

put_right before after

item index

has an interface

Programming in the large - Lecture 2

26

Chair of Software Engineering

An object

startforth

put_right before after

item index

has an implementation

Programming in the large - Lecture 2

27

Chair of Software Engineering

Information hiding

startforth

put_right before after

item index

Programming in the large - Lecture 2

28

Chair of Software Engineering

The Open-Closed principle

F A’

G

H I

A C E

D

B

Programming in the large - Lecture 2

29

Chair of Software Engineering

Closing modules prematurely

type PUBLICATION =record

author, title: STRING;publication_year: INTEGERcase pubtype: (book, journal, conference) of

book: (publisher: STRING);journal: (editor: STRING);conference: (place, chair: STRING)

endend

Use in clients:

p: PUBLICATION ;case p.pubtype of

book: ... p.publisher ...;journal: ... p.editor ...;conference: ... p.place ...

end

Programming in the large - Lecture 2

30

Chair of Software Engineering

The Single Choice principle

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

Programming in the large - Lecture 2

31

Chair of Software Engineering

Reusability issues

Organizational and managerial issues:(Not covered here.)

Technical issues: what form of components? Routine librariesPackages (Ada)Class librariesWhat form of classes?

Programming in the large - Lecture 2

32

Chair of Software Engineering

Reusability: Technical issues

The general pattern for a searching routine:

has (t: TABLE; x: ELEMENT): BOOLEAN is-- Does item x appear in table t?

localpos: POSITION

dofrom

pos := initial_position (t, x) until

exhausted (t, pos) or else found (t, x, pos)loop

pos := next (t, x, pos)endResult := found (t, x, pos)

end

Programming in the large - Lecture 2

33

Chair of Software Engineering

Issues for a general searching module

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

Programming in the large - Lecture 2

34

Chair of Software Engineering

Issues

Representation independence:

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

has (t1, y)

Programming in the large - Lecture 2

35

Chair of Software Engineering

Issues

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?

dofrom start until after or else found (x) loop

forthendResult := found (x)

end

Programming in the large - Lecture 2

36

Chair of Software Engineering

Factoring out commonality

1

item

index

forthcount

start

after

back

before

Programming in the large - Lecture 2

37

Chair of Software Engineering

Factoring out commonality

TABLE

SEQUENTIAL_TABLE

TREE_TABLE

HASH_TABLE

ARRAY_TABLE

LINKED_TABLE

FILE_TABLE

has

startafterfoundforth

Programming in the large - Lecture 2

38

Chair of Software Engineering

Implementation variants

Array

Linked list

File

start forth after found (x)

c := first_cell

rewind

i := 1

c := c.right

i := i + 1

read end_of_file

c = Void

f = ξ

c.item = x

i > count t [i] = x

Programming in the large - Lecture 2

39

Chair of Software Engineering

Encapsulation languages (“Object-based”)

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.

Programming in the large - Lecture 2

40

Chair of Software Engineering

Complementary material

OOSC2:Chapter 3: ModularityChapter 4: Approaches to reusability

Programming in the large - Lecture 2

41

Chair of Software Engineering

End of lecture 2