Object-Oriented Software Construction - ETH Zse.inf.ethz.ch/old/teaching/ss2004/0250/lectures/oosc_04_adt.pdf · Chair of Software Engineering Object technology: A first definition

OOSC - Lecture 4

1

Chair of Software Engineering

Object-Oriented Software Construction

Bertrand Meyer

OOSC - Lecture 4

2


Reading assignment

OOSC2 Chapter 10: Genericity

OOSC - Lecture 4

3


Lecture 4:

Abstract Data Types

OOSC - Lecture 4

4


Abstract Data Types (ADT)

Why use the objects? The need for data abstraction Moving away from the physical representation Abstract data type specifications Applications to software design

OOSC - Lecture 4

5


The first step

A system performs certain actions on certain data. Basic duality:

Functions [or: Operations, Actions] Objects [or: Data]

Action Object

Processor

OOSC - Lecture 4

6


Finding the structure

The structure of the system may be deducedfrom an analysis of the functions (1) or theobjects (2).

Resulting analysis and design method: Process-based decomposition: classical

(routines) Object-oriented decomposition

OOSC - Lecture 4

7


Arguments for using objects

Reusability: Need to reuse whole data structures,not just operations

Extendibility, Continuity: Objects remain morestable over time.

Employeeinformation

Hoursworked

ProducePaychecks

Paychecks

OOSC - Lecture 4

8


Object technology: A first definition

Object-oriented software construction is theapproach to system structuring that bases thearchitecture of software systems on the types ofobjects they manipulate — not on “the” functionthey achieve.

OOSC - Lecture 4

9


The O-O designer’s motto

Ask NOT first WHAT the system does:

Ask WHAT it does it TO!

OOSC - Lecture 4

10


Issues of object-oriented design

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.

OOSC - Lecture 4

11


Description of objects

Consider not a single object but a type of objectswith similar properties.

Define each type of objects not by the objects’physical representation but by their behavior: theservices (FEATURES) they offer to the rest of theworld.

External, not internal view: ABSTRACT DATA TYPES

OOSC - Lecture 4

12


The theoretical basis

The main issue: How to describe program objects(data structures):

Completely

Unambiguously

Without overspecifying? (Remember information hiding)

OOSC - Lecture 4

13


A stack, concrete object

count

representation

(array_up)

capacity

representation [count] := x

free

(array_down)

1representation

nnew

(linked)

item

item

previous

item

previousprevious

“Push” operation:count := count + 1

representation [free] := x“Push” operation:

free := free - 1

new (n)n.item := x

“Push” operation:

n.previous := lasthead := n

OOSC - Lecture 4

14


A stack, concrete object

count

representation

(array_up)

capacity


free

(array_down)

1representation

nnew

(linked)

item

item

previous

item

previousprevious

“Push” operation:count := count + 1

representation [free] := x“Push” operation:

free := free - 1

new (n)n.item := x

“Push” operation:

n.previous := lasthead := n

OOSC - Lecture 4

15


Stack: An abstract data type

Types: STACK [G]

-- G: Formal generic parameter

Functions (Operations): put: STACK [G] × G → STACK [G] remove: STACK [G] → STACK [G] item: STACK [G] → G empty: STACK [G] → BOOLEAN

new: STACK [G]

OOSC - Lecture 4

16


Using functions to model operations

put , =( )

s x s’

OOSC - Lecture 4

17


Reminder: Partial functions

A partial function, identified here by →, is afunction that may not be defined for all possiblearguments.

Example from elementary mathematics:

inverse: ℜ → ℜ, such that

inverse (x) = 1 / x

OOSC - Lecture 4

18


The STACK ADT (cont’d)

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 remove (put (s, x)) = s empty (new)

(or: empty (new) = True)

not empty (put (s, x))(or: empty (put (s, x)) = False)

put ( , ) =

s x s’

OOSC - Lecture 4

19


Exercises

Adapt the preceding specification of stacks (LIFO,Last-In First-Out) to describe queues instead(FIFO).

Adapt the preceding specification of stacks toaccount for bounded stacks, of maximum sizecapacity. Hint: put becomes a partial function.

OOSC - Lecture 4

20


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

OOSC - Lecture 4

21


Expressed differently

s1 = new

s2 = put (put (put (s1, x8), x7), x6)

s3 = remove (s2)

s4 = new

s5 = put (put (s4, x5), x4)

s6 = remove (s5)

y1 = item (s6)

s7 = put (s3, y1)

s8 = put (s7, x2)

s9 = remove (s8)

s10 = put (s9, x1)

s11 = remove (s10)

value = item (s11)

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

OOSC - Lecture 4

22


Expression reduction (1/10)

value = item ( remove (

put ( remove (

put ( put ( remove (

put (put (put (new, x8), x7), x6) )

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

) )

) , x2)

) , x1) )

)

x7

x8

x6

x5

x4

Stack 1 Stack 2

OOSC - Lecture 4

23



x7

put remove

x8

x7

x8

x7

x8

x6


put ( remove (




) )

) , x2)

) , x1) )

)

x5

x4

Stack 1 Stack 2

OOSC - Lecture 4

24




put ( remove (




) )

) , x2)

) , x1) )

)

x7

put remove

x8

x7

x8

x7

x8

x2

x7

put remove

x8

x7

x8

x7

x8

x2

Stack 1

x5

x4

Stack 2

OOSC - Lecture 4

25




put ( remove (




) )

) , x2)

) , x1) )

)

x5

put remove

x5 x5

x4x7

x8

x7

x8

Stack 1 Stack 2

OOSC - Lecture 4

26




put ( remove (




) )

) , x2)

) , x1) )

)

item

x5

Stack 2

x7

x8

x7

x8

Stack 1

OOSC - Lecture 4

27



put ( remove (




) )

) , x2)

) , x1) )

)


x5

Stack 2

x7

x8

x7

x8

Stack 1

OOSC - Lecture 4

28



put ( remove (




) )

) , x2)

) , x1) )

)


x5

x7

x8

x7

x8

Stack 3

OOSC - Lecture 4

29




put ( remove (




) )

) , x2)

) , x1) )

)

x5

x7

x8

x7

x8

Stack 3

put removex1

x5

x7

x8

x7

x8

x5

x7

x8

x7

x8

OOSC - Lecture 4

30


Expression reduction (9/10)item

x5

x7

x8

x7

x8

Stack 3


put ( remove (




) )

) , x2)

) , x1) )

)

OOSC - Lecture 4

31




put ( remove (




) )

) , x2)

) , x1) )

)

value = x5

x5

x7

x8

x7

x8

Stack 3

OOSC - Lecture 4

32


Expressed differently

s1 = new

s2 = put (put (put (s1, x8), x7), x6)

s3 = remove (s2)

s4 = new

s5 = put (put (s4, x5), x4)

s6 = remove (s5)

y1 = item (s6)

s7 = put (s3, y1)

s8 = put (s7, x2)

s9 = remove (s8)

s10 = put (s9, x1)

s11 = remove (s10)

value = item (s11)

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

OOSC - Lecture 4

33


An operational view of the expression

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

x8

x7

x6

x8

x7

s2 s3(empty)

s1x5

x4

s5(empty)

s4x5

s6

y1

x8

x7

x5

s7 (s9, s11)x8

x7

x5

s8

x2

x8

x7

x5

s10

x1

OOSC - Lecture 4

34


Sufficient completeness

Three forms of functions in the specification of anADT T: Creators:

OTHER → T e.g. new Queries:

T ×... → OTHER e.g. item, empty Commands:

T ×... → T e.g. put, remove

Sufficiently complete specification: a “QueryExpression” of the form:

f (...)

where f is a query, may be reduced throughapplication of the axioms to a form not involving T

OOSC - Lecture 4

35


Stack: An abstract data type

Types: STACK [G]

-- G: Formal generic parameter

Functions (Operations): put: STACK [G] × G → STACK [G] remove: STACK [G] → STACK [G] item: STACK [G] → G empty: STACK [G] → BOOLEAN

new: STACK [G]

OOSC - Lecture 4

36


ADT and software architecture

Abstract data types provide an ideal basis formodularizing software.

Identify every module with an implementation ofan abstract data type, i.e. the description of a setof objects with a common interface.

The interface is defined by a set of operations(implementing the functions of the ADT)constrained by abstract properties (the axiomsand preconditions).

The module consists of a representation for theabstract data type and an implementation foreach of the operations. Auxiliary operations mayalso be included.

OOSC - Lecture 4

37


Implementing an ADT

Three components:(E1) The ADT’s specification: functions,

axioms, preconditions.(Example: stacks.)

(E2) Some representation choice.(Example: <representation, count>.)

(E3) A set of subprograms (routines) and attributes, each implementing one of thefunctions of the ADT specification (E1) in

terms of the chosen representation (E2).(Example: routines put, remove, item, empty, new.)

OOSC - Lecture 4

38


A choice of stack representation

count

representation

(array_up)

capacity “Push” operation:count := count + 1


OOSC - Lecture 4

39


Application to information hiding

Secret part:

•Choice of representation (E2)

•Implementation of functionsby features (E3)

ADT specification (E1)Public part:

OOSC - Lecture 4

40


Object technology: A first definition

Object-oriented software construction is theapproach to system structuring that bases thearchitecture of software systems on the types ofobjects they manipulate — not on “the” functionthey achieve.

OOSC - Lecture 4

41


Object technology: More precise definition

Object-oriented software construction is theconstruction of software systems as structuredcollections of (possibly partial) abstract data typeimplementations.

OOSC - Lecture 4

42


Classes: The fundamental structure

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 theinstances of the class, viewed as a type.

OOSC - Lecture 4

43


Class relations

Two relations: Client Heir

OOSC - Lecture 4

44


Overall system structure

CHUNK

word_countjustified?

add_wordremove_word

justifyunjustify

lengthfontFIGURE

PARAGRAPH WORD

space_before

space_afteradd_space_before

add_space_after

set_fonthyphenate_onhyphenate_off

QUERIES COMMANDS

FEATURES

Inheritance

Client

OOSC - Lecture 4

45


A very deferred class

deferred class COUNTER

feature

item: INTEGER is deferred end-- Counter value

up is-- Increase item by 1.

deferredensure

item = old item + 1end

down is-- Decrease item by 1.

deferredensure

item = old item – 1end

invariant

item >= 0

end

OOSC - Lecture 4

46


End of lecture 4

Documents

Object-Oriented Software Construction - ETH Zse.inf.ethz.ch/old/teaching/ss2004/0250/lectures/oosc_04_adt.pdf · Chair of Software Engineering Object technology: A first definition