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