Chair of Software Engineering

Software Architecture
Bertrand Meyer, Carlo A. Furia, Martin Nordio

ETH Zurich, February-May 2011

Lecture 5: Modularity and

Abstract Data Types
Three topics (over today & tomorrow)

1. Modularity

2. The theory of abstract data types

3. Object-oriented analysis

2
Reading assignment for this week

OOSC, chapters
3: Modularity
6: Abstract data types

In particular pp.153-159,
sufficient completeness

3
Modularity

General goal:

Ensure that software systems are structured into

units (modules) chosen to favor
 Extendibility
 Reusability
 ―Maintainability‖
 Other benefits of clear, well-defined architectures

4
Modularity

Some principles of modularity:

 Decomposability
 Composability
 Continuity
 Information hiding
 The open-closed principle
 The single choice principle

5
Decomposability

The method helps decompose complex problems

into subproblems

COROLLARY: Division of labor.

 Example: Top-down design method (see next).
 Counter-example: General initialization module.

6
Top-down functional design

Topmost functional abstraction

Sequence

B C D

Loop Conditional
E1 I I1 C2 I2

7
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/

8
Composability

The method favors the production of software

elements that may be freely combined with each
other to produce new software

Example: Unix shell conventions

Program1 | Program2 | Program3

9
Direct Mapping

The method yields software systems whose

modular structure remains compatible with any
modular structure devised in the process of
modeling the problem domain

10
Few Interfaces principle

Every module communicates with

as few others as possible

(A) (B) (C)

11
Small Interfaces principle

If two modules communicate, they exchange as little

information as possible

x, y

12
Explicit Interfaces principle

Whenever two modules communicate, this is clear from

the text of one or both of them

A B

modifies accesses
Data
item
x

13
Continuity

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

14
Uniform Access principle

It doesn‗t matter to the client

whether you look up or compute

A call such as

.
your_account balance

could use an attribute or a function

15
Uniform Access

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

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

18
Information Hiding Principle

Public
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

Private

19
Information hiding

Justifications:
 Continuity
 Decomposability

20
An object has an interface

start item index

forth
put_right before after

21
An object has an implementation

start item index

forth
put_right before after

22
Information hiding

start item index

forth
put_right before after

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

24
The Open-Closed principle

B A C E

F A’ H I

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

26
Reusability: Technical issues

General pattern for a searching routine:

has (t: TABLE; x: ELEMENT ): BOOLEAN
-- Does x appear in 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

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

28
Issues

Representation independence:

 Can a client request an operation such as table

search (has) without knowing what implementation is
used internally?

has (t1, y )

29
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: ELEMENT ): BOOLEAN

-- Does x appear in t ?
do
from start until after or else found (x ) loop
forth
end
Result := found (x )
end

30
Factoring out commonality

TABLE has

start
after SEQUENTIAL TREE_ HASH_
found _TABLE TABLE TABLE
forth

ARRAY_ LINKED_ FILE_

TABLE TABLE TABLE

31
Implementation variants

start forth after found (x)

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

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

File rewind read end_of_file item = x

32
Encapsulation languages (“Object-based”)
Ada, Modula-2, Oberon, 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.

33
The concept of Abstract Data Type (ADT)
 Why use the objects?
 The need for data abstraction
 Moving away from the physical representation
 Abstract data type specifications
 Applications to software design

34
The first step

A system performs certain actions on certain data.

Basic duality:
 Functions [or: Operations, Actions]
 Objects [or: Data]

Actions Objects

Processor

35
Finding the structure

The structure of the system may be deduced from an

analysis of the functions (1) or the objects (2)

Resulting architectural style and analysis/design method:

 (1) Top-down, functional decomposition

 (2) Object-oriented

36
Arguments for using objects

Reusability: Need to reuse whole data structures, not just

operations
Extendibility, Continuity: Object categories remain more
stable over time.

Employee
information
Produce Paychecks
Paychecks
Hours
worked

37
Object technology: A first definition

Object-oriented software construction is the

software architecture method that bases the
structure of systems on the types of objects
they handle — not on ―the‖ function they achieve.

38
The O-O designer’s motto

Ask not first WHAT the system does:

Ask WHAT it does it to!

39
Issues of object-oriented architecture

 How to find the object types

 How to describe the object types
 How to describe the relations and commonalities
between object types
 How to use object types to structure programs

40
Description of objects

Consider not a single object but a type of objects with

similar properties.

Define each type of objects not by the objects‘ physical

representation but by their behavior: the services
(FEATURES) they offer to the rest of the world.

External, not internal view: ABSTRACT DATA TYPES

41
The theoretical basis

The main issue: How to describe program objects (data

structures):
 Completely
 Unambiguously
 Without overspecifying?
(Remember information hiding)

42
Abstract Data Types

A formal way of describing data structures

Benefits:
 Modular, precise description of a wide range of
problems
 Enables proofs
 Basis for object technology
 Basis for object-oriented requirements

43
A stack, concrete object

x capacity Implementing a ―PUSH‖ operation:

x
count count := count + 1
Representation 1: rep [count] := x
―Array Up‖

1
rep

44
A stack, concrete object
capacity Implementing a ―PUSH‖ operation:
x count
count := count + 1
Representation 1: rep [count] := x
―Array Up‖

1
rep
x
rep [free] := x
free := free - 1
Representation 2:
―Array Down‖ x free
1
rep

45
A stack, concrete object
capacity Implementing a ―PUSH‖ operation:

count rep [count] := x

Representation 1: count := count + 1
―Array Up‖

1
rep

rep [free] := x
free := free - 1
Representation 2:
―Array Down‖ x
free
1
rep
cell create cell
x item previous
cell.item := x
item previous cell.previous := last
Representation 3: previous
―Linked List‖ item head := cell
46
Stack: An Abstract Data Type (ADT)
Types:
STACK [G ]
-- G : Formal generic parameter

Functions (Operations):
put : STACK [G ]  G  STACK [G ]
remove : STACK [G ]  STACK [G ]
item : STACK [G ]  G Partial function
is_empty : STACK [G ]  BOOLEAN (see next)

new : STACK [G ]

47
Using functions to model operations

put ( , ) =

s x s‘

48
Reminder: Partial functions

A partial function, identified here by , is a function that

may not be defined for all possible arguments.

Example from elementary mathematics:

 inverse:   , such that

inverse (x ) = 1 / x

49
The STACK ADT (continued)

Preconditions:
remove (s : STACK [G ]) require not is_empty (s )
item (s : STACK [G ]) require not is_empty (s )

Axioms: For all x : G, s : STACK [G ]

item (put (s, x )) = x put ( , ) =
remove (put (s, x )) = s s x s‘
is_empty (new)
(can also be written: is_empty (new) = True)
not is_empty (put (s, x ))
(can also be written: is_empty (put (s, x)) = False)

50
Exercises

Adapt the preceding specification of stacks (LIFO, Last-

In First-Out) to describe queues instead (FIFO).

Adapt the preceding specification of stacks to account for

bounded stacks, of maximum size capacity.
 Hint: put becomes a partial function.

51
Formal stack expressions

value =
item (remove (put (remove (put (put
(remove (put (put (put (new, x8 ), x7 ), x6 )),

item (remove (put (put (new, x5 ), x4 )))),

x2 )), x1 )))

52
Expressed differently

value = item (remove (put (remove (put (put (remove (put

(put (put (new, x8 ), x7), x6)), item (remove (put (put (new,
x5 ), x4 )))), x2 )), x1 )))

s1 = new y1 = item (s6 )

s2 = put (put (put (s1, x8 ), x7 ), x6 ) s7 = put (s3, y1 )
s8 = put (s7, x2 )
s3 = remove (s2 )
s9 = remove (s8 )
s4 = new
s10 = put (s9, x1 )
s5 = put (put (s4, x5 ), x4 )
s11 = remove (s10 )
s6 = remove (s5 ) value = item (s11 )

53
Expression reduction
value = item (
remove (
put (
remove (
put ( Stack 1
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

54
Expression reduction
value = item (
remove (
put (
remove ( x8
put ( Stack 1
put (
remove (
put (put ( put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

55
Expression reduction
value = item (
remove (
put ( x7
remove ( x8
put ( Stack 1
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

56
Expression reduction
value = item (
remove ( x6
put ( x7
remove ( x8
put ( Stack 1
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
)
, item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

57
Expression reduction
value = item (
remove ( x6
put ( x7
remove ( x8
put ( Stack 1
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

58
Expression reduction
value = item (
remove (
put ( x7
remove ( x8
put ( Stack 1 Stack 2
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put ( put ( new , x5 ) , x4 )
)
)
),
x2 )
),
x1 )
)
)

59
Expression reduction
value = item (
remove (
put ( x7
remove ( x8 x5
put ( Stack 1 Stack 2
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put ( put (new, x5 ) , x4 )
)
)
),
x2 )
),
x1 )
)
)

60
Expression reduction
value = item (
remove (
put ( x7 x4
remove ( x8 x5
put ( Stack 1 Stack 2
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put ( new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

61
Expression reduction
value = item (
remove (
put ( x7 x4
remove ( x8 x5
put ( Stack 1 Stack 2
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

62
Expression reduction
value = item (
remove (
put ( x7
remove ( x8 x5
put ( Stack 1 Stack 2
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

63
Expression reduction
value = item (
remove ( x5
put ( x7
remove ( x8 x5
put ( Stack 1 Stack 2
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

64
Expression reduction
x2
value = item (
remove ( x5
put ( x7
remove ( x8
put (
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

65
Expression reduction
x2
value = item (
remove ( x5
put ( x7
remove ( x8
put (
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

66
Expression reduction
value = item ( x1
remove ( x5
put ( x7
remove ( x8
put (
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

67
Expression reduction
x1
value = item (
x5
remove (
put ( x7
remove ( x8
put (
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

68
Expression reduction
value = item (
x5
remove (
put ( x7
remove ( x8
put (
put (
remove (
put (put (put ( new , x8 ), x7 ), x6 )
),
item (
remove (
put (put (new, x5 ), x4 )
)
)
),
x2 )
),
x1 )
)
)

69
Expressed differently

value = item (remove (put (remove (put (put (remove (put

(put (put (new, x8 ), x7), x6)), item (remove (put (put (new,
x5 ), x4 )))), x2 )), x1 )))

s1 = new y1 = item (s6 )

s2 = put (put (put (s1, x8 ), x7 ), x6 ) s7 = put (s3, y1 )
s8 = put (s7, x2 )
s3 = remove (s2 )
s9 = remove (s8 )
s4 = new
s10 = put (s9, x1 )
s5 = put (put (s4, x5 ), x4 )
s11 = remove (s10 )
s6 = remove (s5 ) value = item (s11 )

70
An operational view of the expression

x6

x7 x7 x4 y1
x8 x8 x5 x5
s1 s2 s3 s4 s5 s6
(empty) (empty)

x2 x1

x5 x5 x5

x7 x7 x7

x8 x8 x8
s7 (s9, s11) s8 s10
value = item (remove (put (remove (put (put (remove (put (put (put
(new, x8 ), x7 ), x6)), item (remove (put (put (new, x5 ), x4 )))), x2 )), x1 )))

71
Sufficient completeness

Three forms of functions in the specification of an ADT T :

 Creators:
OTHER  T e.g. new
 Queries:
T ...  OTHER e.g. item, empty
 Commands:
T ...  T e.g. put, remove

Sufficiently Complete specification

An ADT specification with axioms that make it possible
to reduce any correct ―Query Expression‖ of the form
f (...)
where f is a query, to a form not involving T
72
Well-formed and correct expression

An expression built from an ADT is well-formed if all the

function applications it involves use the right number of
arguments of the right type, each argument being
(recursively) well-formed
Examples:
put (x) is not well-formed
put (new, x) is well-formed
remove (new) is well-formed

An expression is correct if (1) it is well-formed (2) the

arguments to all function applications satisfy the
respective preconditions and (3) all these arguments are
(recursively) correct.

73
Is the stack specification sufficiently complete?

Types
STACK [G]

Functions
put: STACK [G]  G  STACK [G]
remove: STACK [G]  STACK [G]
item: STACK [G]  G
empty: STACK [G]  BOOLEAN
new: STACK [G]

74
The STACK ADT (continued)

Preconditions:
remove (s : STACK [G ]) require not empty (s )
item (s : STACK [G ]) require not empty (s )

Axioms: For all x : G, s : STACK [G ]

item (put (s, x )) = x put ( , ) =
remove (put (s, x )) = s s x s‘
empty (new)
(can also be written: empty (new) = True)
not empty (put (s, x ))
(can also be written: empty (put (s, x)) = False)

75
Proving sufficient completeness
Let us say that an ADT expression f for the ADT
STACK [X] is reducible if the axioms make it possible to
determine the value of f in terms of the types X and
BOOLEAN only

To prove sufficient completeness for the stack

specification, we must prove that a correct expression f
of the form

item (e) or
empty (e)

is reducible
(to terms of values X and BOOLEAN respectively)
76
Proof sketch

We prove that a correct expression f = item (e) is

reducible
(the case of empty is left as an exercise)

We work by induction on the number of parenthesis pairs

in f

Lemma:
A correct expression of the form
remove (g)
has a subexpression of the form
remove (put (h, x))

77
“Complete” requirements (from the Requirements lecture)
Complete with respect to what?

Definition from IEEE standard (see next) :

An SRS (Software Requirements Specification) is complete if, and

only if, it includes the following elements:
 All significant requirements, whether relating to functionality,
performance, design constraints, attributes, or external
interfaces. In particular any external requirements imposed by
a system specification should be acknowledged and treated.
 Definition of the responses of the software to all realizable
classes of input data in all realizable classes of situations.
Note that it is important to specify the responses to both
valid and invalid input values.
 Full labels and references to all figures, tables, and diagrams
in the SRS and definition of all terms and units of measure.

78
Completeness (from the Requirements lecture)

Completeness cannot be ―completely‖ defined

But (taking advantage of the notion of sufficient

completeness for abstract data types) we can cross-check:
 Commands x Queries

to verify that every effect is defined

79
ADTs and software architecture

Abstract data types provide an ideal basis for modularizing

software.
Build each module as an implementation of an ADT:
 Implements a set of objects with same interface
 Interface is defined by a set of operations (the
ADT‘s functions) constrained by abstract properties
(its axioms and preconditions).
The module consists of:
 A representation for the ADT
 An implementation for each of its operations
 Possibly, auxiliary operations

80
Implementing an ADT

Three components:
(E1) The ADT‘s specification: functions,
axioms, preconditions
(Example: stacks)

(E2) Some representation choice

(Example: <rep, count >)

(E3) A set of subprograms (routines) and

attributes, each implementing one of the
functions of the ADT specification (E1)
in terms of chosen representation (E2)
(Example: routines put, remove, item, empty, new)

81
A choice of stack representation

capacity ―Push‖ operation:

count := count + 1
rep [count] := x
(array_up) count

1
rep

82
Information hiding
Public
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

Private

83
Applying ADTs to information hiding

Public part:
 ADT specification
(E1 )

Secret part:
 Choice of representation
(E2 )
 Implementation of
functions by features
(E3 )

84
Object technology: A first definition

Object-oriented software construction is the

software architecture method that bases the
structure of systems on the types of objects
they handle — not on ―the‖ function they achieve

85
A more precise definition

Object-oriented software construction is the

construction of software systems as structured
collections of (possibly partial) abstract data
type implementations

86
The fundamental structure: the class
Merging of the notions of module and type:

 Module = Unit of decomposition: set of services

 Type = Description of a set of run-time objects
(―instances‖ of the type)

The connection:
 The services offered by the class, viewed as a
module, are the operations available on the instances
of the class, viewed as a type.

87
Class relations

Two relations:

 Client
 Heir

88
Overall system structure

space_before add_space_before
CHUNK FEATURES
space_after add_space_after

QUERIES COMMANDS
length set_font
add_word font hyphenate_on
FIGURE hyphenate_off
remove_word
PARAGRAPH WORD
justify
word_count
unjustify
justified

Inheritance

Client

89
Bounded stacks
Types:
BSTACK [G]

Functions (Operations):
put : BSTACK [G]  G  BSTACK [G]
remove : BSTACK [G]  BSTACK [G]
item : BSTACK [G]  G
empty : BSTACK [G]  BOOLEAN
new : BSTACK [G]
capacity : BSTACK [G]  INTEGER
count : BSTACK [G]  INTEGER

full : BSTACK [G]  BOOLEAN

90
Television station example
Source: OOSC

class SCHEDULE feature

segments: LIST [SEGMENT]
end

91
91
Schedules
note set_air_time (t : DATE)
description : -- Assign schedule to
― 24-hour TV schedules‖ -- be broadcast at time t.
deferred class SCHEDULE feature require
.
t in_future
segments: LIST [SEGMENT ] deferred
-- Successive segments ensure
deferred air_time = t
end end
print
air_time : DATE is -- Produce paper version.
-- 24-hour period
deferred
-- for this schedule
deferred end
end end

92
92
Contracts

Feature precondition: condition imposed on the rest of the

world

Feature postcondition: condition guaranteed to the rest of

the world

Class invariant: Consistency constraint maintained

throughout on all instances of the class

93
93
Why contracts

Specify semantics, but abstractly!

(Remember basic dilemma of requirements:

 Committing too early to an implementation
Overspecification!

 Missing parts of the problem

Underspecification!
)

94
94
Segment
note sponsor : COMPANY deferred end
-- Segment‘s principal sponsor
description :
"Individual fragments of a schedule "
deferred class SEGMENT feature rating : INTEGER deferred end
-- Segment‘s rating (for
schedule : SCHEDULE deferred end
-- children‘s viewing etc.)
-- Schedule to which
-- segment belongs
index : INTEGER deferred end  Commands such as change_next,
-- Position of segment in set_sponsor, set_rating omitted 
-- its schedule
starting_time, ending_time : Minimum_duration : INTEGER = 30
INTEGER deferred end -- Minimum length of segments,
-- Beginning and end of -- in seconds
-- scheduled air time
next: SEGMENT deferred end Maximum_interval : INTEGER = 2
-- Segment to be played -- Maximum time between two
-- next, if any -- successive segments, in seconds

95
95
Segment (continued)
invariant
in_list: (1 <= index) and (index <= schedule.segments.count)
in_schedule: schedule.segments.item (index) = Current
next_in_list: (next /= Void ) implies
(schedule.segments.item (index + 1) = next)
no_next_iff_last: (next = Void) = (index = schedule.segments.count)
non_negative_rating: rating >= 0
positive_times: (starting_time > 0 ) and (ending_time > 0)
sufficient_duration:
ending_time – starting_time >= Minimum_duration
decent_interval :
.
(next starting_time) - ending_time <= Maximum_interval
end
96
96
Commercial
note set_primary (p: PROGRAM)
description: "Advertizing segment " -- Attach commercial to p.
deferred class COMMERCIAL inherit require
SEGMENT
program_exists: p /= Void
rename sponsor as advertizer end
same_schedule: p,schedule = schedule
feature
primary: PROGRAM deferred before:
-- Program to which this p.starting_time <= starting_time
-- commercial is attached deferred
primary_index: INTEGER deferred ensure
-- Index of primary
index_updated:
primary_index = p.index
primary_updated: primary = p
end

invariant
meaningful_primary_index: primary_index = primary.index
primary_before: primary.starting_time <= starting_time
.
acceptable_sponsor: advertizer compatible (primary.sponsor)
acceptable_rating: rating <= primary.rating
end
97
97
Diagrams: UML, BON

Text-Graphics
Equivalence

98
98
O-O analysis process

Identify abstractions
 New
 Reused
Describe abstractions through interfaces, with contracts
Look for more specific cases: use inheritance
Look for more general cases: use inheritance, simplify
Iterate on suppliers

At all stages keep structure simple and look for applicable

contracts

99
99
Your turn! Describe this in an O-O way
Consider a small library database Transactions 1, 2, 4, and 5 are
with the following transactions: restricted to staff users, except
1. Check out a copy of a book. that ordinary borrowers can
Return a copy of a book. perform transaction 4 to find
2. Add a copy of a book to the out the list of books currently
library. Remove a copy of a borrowed by themselves. The
book from the library. database must also satisfy the
following constraints:
3. Get the list of books by a
particular author or in a All copies in the library must
particular subject area. be available for checkout or
be checked out.
4. Find out the list of books
currently checked out by a No copy of the book may be
particular borrower. both available and checked
out at the same time.
5. Find out what borrower last
checked out a particular copy A borrower may not have
of a book. more than a predefined
number of books checked out
There are two types of users: staff at one time.
users and ordinary borrowers.
100
100
Practical advice

Take advantage of O-O techniques

from the requirements stage on

Use contracts to express semantic

properties

101
101
Practical advice

Write ADT specifications for

delicate parts of the system
requirements

102
Bounded stacks (continued)

Preconditions:
remove (s : BSTACK [G]) require not empty (s)
item (s : BSTACK [G]) require not empty (s)
put (s : BSTACK [G]) require not full (s)
Axioms: For all x : G, s : BSTACK [G]
item (put (s, x)) = x
remove (put (s, x)) = s
empty (new)
not empty (put (s, x))
full = (count = capacity)
count (new) = 0
count (put (s, x)) = count (s) + 1
count (remove (s)) = count (s) - 1
103