Trusted Componentsse.inf.ethz.ch/old/teaching/ws2006/0239/slides/TC2006... · 2006-11-10 ·...

Trusted Components, Winter Semester 2006-2007 Chair of Software Engineering1

Trusted ComponentsReuse, Contracts and Patterns

Bertrand MeyerManuel Oriol

ETH, 2006-2007


Aims of this course

To provide a survey of

Reuse and component technology, with a specialemphasis on object-oriented approaches

Techniques for quality components

Formal methods and proofs


Topics

Quality issues in software engineering Components and the notion of trusted component Designing O-O libraries Axiomatic Semantics and Program Correctness Componentization: turning patterns into

Components Testing Components Fundamentals of Program Analysis Model Checking Abstract Interpretation Proof-Carrying Code


Basic references

Clemens Szyperski, Component Software, Addison-Wesley, 1998

Bertrand Meyer, Object-Oriented SoftwareConstruction, 2nd edition, Prentice Hall, 1997

Bertrand Meyer, Reusable Software, Prentice Hall, 1994Martin Abadi, Luca Cardelli: A Theory of Objects,

Springer-Verlag, 1996.


Organization

Course pagehttp://se.inf.ethz.ch/teaching/ws2006/0239/

Lectures:Monday: 2 hoursWednesday: 1 hour -- exercises and applications

All exercises are optional, but will be corrected. They are animportant preparation for the exam and the project.

Assistant: Dr. Lisa (Ling) Liu

Grading:Written exam (end of semester) 40%Project 60% (details on Wednesday)


Project

Trusted Web-Based File Repository

Stand-alone application (own webserver) User management Reuse of existing libraries Assessment of software quality Proof of properties

Would we trust the webserver? Why?


Today & next lecture

Aims of the course

Introduction to issues of software quality

Introduction to component-based development


Reading assignment

“Ariane” paper:

http://www.eiffel.com/doc/manuals/technology/contract/ariane/page.html

Also read Ken Garlington’s criticism (link in thearticle) and the official report on the Ariane crash


PART 1: Introduction

Issues of Software Quality


Software quality: external vs internal

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

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


Software quality: product vs process

Product: properties of the resulting software

For example: correctness, efficiency

Process: properties of the procedures used to produceand “maintain” the software


External quality factors

CorrectnessRobustnessSecurityEase of useEase of learningEfficiency

ExtendibilityReusabilityPortability

TimelinessCost-effectiveness

Security

Hostility

Correctness

Errors

Correctness

Specification

Process quality:

Product quality (long-term):

Product quality (immediate):


Reliability

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

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

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


Non-quality

September 1997: missile Cruiser USS Yorktown,“dead in the water” for two hours and 45 minutes,due to a divide by zero in Windows NT.

Ariane 5 ESA rocket launcher

Therac-25

London Ambulance System

Year 2000 (see Christopher Creele, BM and PhilippeStephan, IEEE Computer, November 1997)


Ariane 5, 1996

$500 million, not insured.

40 seconds into flight, exception in Ada program not processed; ordergiven to abort the mission.

Exception was caused by an incorrect conversion: a 64-bit real valuewas incorrectly translated into a 16-bit integer.

• Not a design error.

• Not an implementation error.

• Not a language issue.

• Not really a testing problem.

• Only partly a quality assurance issue.

Systematic analysis had “proved” that the exception could not occur– the 64-bit value (“horizontal bias” of the flight) was proved to bealways representable as a 16-bit integer !


Ariane-5 (Continued)

It was a REUSE error:

• The analysis was correct – for Ariane 4 !

• The assumption was documented – in a design document !

With assertions, the error would almost certainly (if not avoided in thefirst place) detected by either static inspection or testing:

integer_bias (b: REAL): INTEGER is require representable (b) do … ensure equivalent (b, Result) end


Ariane 5 (Conclusion)

The main lesson:

Reuse without a contract is sheer folly

See:

Jean-Marc Jézéquel and Bertrand Meyer

Design by Contract: The Lessons of Ariane

IEEE Computer, January 1997

Also at http://www.eiffel.com


US software industry, 1998

Source: Standish report

Project leaders and CIOs representing several thousandsoftware projects

Project outcome:

• 28% failure (1994: 31%)

• 27% success (1994: 16%)

• Rest: completed over budget, over time, under features

Smaller projects have a higher chance of succeeding


NIST report on “testing” (May 2002)

Monetary effect on

Developers and

User due to

“insufficient testing infrastructure”:

$59.5 billion

(Financial sector: $3.3 billion,

auto/aerospace $1.8 billion etc.)


From reliability to security

Buffer overflow

(Morris worm, most viruses)

See http://www.cert.org

Some_innocuous_public_command “Some message”

(Or maybe just inputting text into a browser field)


Buffer overflow

Memory Setup

0 Max

Program Heap Stack

Stack frames

MainRout1Routn

Stack growth…

Stack top Stack bottom


Calling a routine

0 Max

Program Heap Stack

Stack frames

MainRout1Routn…Args

ofRout

Localsof

Rout

Return address


Calling a utility

syslogd "Some error message“

finger Some_name

some_command "some text"

(Text input into some browser field)


Allocating the buffer

0 Max

Program Heap Stack

Stack frames


ofRout

Return address

Other locals

Buffer


How was the routine coded?

from i := 1 untili > input_size

loopbuffer [i] := input [i]i := i + 1

end

from i := 1 untili > input_size or i > buffer_size

loopbuffer [i] := input [i]i := i + 1

end

(1)

(2)


Allocating the buffer

0 Max

Program Heap Stack

Stack frames


ofRout

Return address

Other locals

Buffer


Getting close

0 Max

Program Heap Stack

Stack frames

MainRout1Routn…

Return address

Other locals

Buffer


Getting closer

0 Max

Program Heap Stack

Stack frames

MainRout1Routn…

Return address

Other locals

Buffer

Available !


Inserting the code

0 Max

Program Heap Stack

Stack frames

MainRout1Routn…

Return address

Other locals

Buffer

Available !

Your Code

Modified Return Address


Buffer overflow: lessons

Lack of specificationLack of specification enforcementProgramming techniquesSecurity concepts

At the core, a programming methodology issue


Software quality (through technology)

A priori (build it right)Object technology, formal development

A posteriori (validate and fix it)Testing, abstract interpretation, model checking


Management aspects

Process standards: CMMI, ISO 9001Get software in source from, benefit from public scrutinyMetrics collection and applicationCode reviews?


Today’s software is often good enough

Overall:Works most of the timeDoesn’t kill too many peopleNegative effects, esp. financial, are diffuse

Significant improvements since early years:Better languagesBetter toolsBetter practices (configuration management)


From “good enough” to good?

Beyond “good enough”, quality is economically badHe who perfects, dies

Actual

Ideal

Quality

1 2 3

Time

4

Choose to release?


The economic argument

Stable system: Sum of individual optima = Global optimum

Non-component-based development: Individual optimum = “Good Enough Software” Improvements: I am responsible!

Component-based development: Interest of both consumer and producer: Better

components Improvements: Producer does the job


Quality through reuse

The good news:

Reuse scales up everything


Quality through reuse

The good news:


The bad news:



Trusted components

Confluence of

Quality engineeringReuse


Approaches: components

O-O libraries: Smalltalk, Eiffel, Java, STL, ...Binary components

Component experience:

CORBACOM/DCOMEnterprise Java Beans.NET component model

Binary component standards:

Reuse, components, COTS (Commercial Off-The-Shelf),CBD (Component-Based Development)


The conjecture behind this course

A breakthrough is necessary in software quality (andmore generally in software engineering)

Only components can provide this breakthrough

Components raise major quality issues on their own


Software design in the future?

Guaranteed qualityFaster time to marketEase of maintenanceStandardization of software practicesPreservation of know-how

Component-based for

Reuse: consumer view, producer view


What exactly is a component?

Working definition:

Program element such that:

It may be used by other program elements(not just humans, or non-software systems).These elements will be called “clients”

Its authors need not know about the clients.

Clients’ authors need only know what thecomponent’s author tells them.


Classifying components by...

Lifecycle role:•Analysis•Design•Implementation

Flexibility:•Static•Dynamic•Replaceable

Form of use:•Interface only•Source only•Source + hiding

Economics:•Free•Purchased•Rented

Abstraction level:•Functional (subroutine)•Casual (package)•Data (class)•Cluster (framework)•System (binary comp.)


This is a broad view of components

Encompasses patterns and frameworks

Software, especially with object technology, permits“pluggable” components (“don’t call us, we’ll call you),where client programmers can insert their ownmechanisms.

Supports component families


From patterns to components

Patterns are both one of the greatest advances insoftware engineering, and a step backwards from thepush for reuse through object technology

We should try to turn successful patterns intocomponents!

See Karine Arnout’s thesis


Component quality

Bad-quality components are a major riskDeficiencies scale up, too

High-quality components could transform the state ofthe software industry (if it wanted to – currentlydoesn’t)

The key issue


Component Source: calendar

Home page

Product catalog

Calendar components

Calendar component documentation home

Calendar component operations


Perfectionism

Component design should be Formula-1 racing ofsoftware “engineering”.

In component development, perfectionism isgood.


Levels of reusability

0- Used in one system.1- Used in several systems built by the same person.2- Used in several systems built by the same group or

company.3- Used in several systems built by people that are in

contact with the developers4- Used by groups unknown to the developers.


Component Quality Model

A: Acceptance

B: Behavior

C: Constraints

D: Design

E: Extension



A: Acceptance

B: Behavior

C: Constraints

D: Design

E: Extension

A.1 Some reuse attestedA.2 Producer reputationA.3 Published evaluations



A: Acceptance

B: Behavior

C: Constraints

D: Design

E: Extension

B.1 ExamplesB.2 Usage documentationB.3 PreconditionedB.4 Some postconditionsB.5 Full postconditionsB.6 Observable invariants



A: Acceptance

B: Behavior

C: Constraints

D: Design

E: Extension

C.1 Platform specC.2 Ease of useC.3 Response timeC.4 Memory occupationC.5 BandwidthC.6 AvailabilityC.7 Security


Contract levels

Type

Functional specification

Performance specification

Quality of Service

(Source: Jézéquel, Mingins et al.)



A: Acceptance

B: Behavior

C: Constraints

D: Design

E: Extension

E.1 Portable across platformsE.2 Mechanisms for additionE.3 Mechanisms for redefinitionE.4 User action pluggability



A: Acceptance

B: Behavior

C: Constraints

D: Design

E: Extension

D.1 Precise dependency docD.2 Consistent API rulesD.3 Strict design rulesD.4 Extensive test casesD.5 Some proved propertiesD.6 Proofs of preconditions,

postconditions & invariants


The high road: towards proofs?

A: Acceptance

B: Behavior

C: Constraints

D: Design

E: Extension

D.1 Precise dependency docD.2 Consistent API rulesD.3 Strict design rulesD.4 Extensive test cases

D.5 Some proved propertiesD.6 Proofs of preconditions,

postconditions & invariants


The experience of EiffelBase

Designed 1985-1986, revised 1988

About 180 classes covering fundamental structuresand algorithms (“Knuthware”)

Attempt at “Linnaean” classification of these basestructurs


In NAG

nonlinear_ode

(equation_count: in INTEGER;

epsilon: in out DOUBLE;

func: procedure

(eq_count: INTEGER; a: DOUBLE; eps: DOUBLE;

b: ARRAY[DOUBLE]; cm: pointer Libtype)

left_count, coupled_count: in INTEGER ...)

[And so on. Altogether 19 arguments, including:

- 4 in out values;

- 3 arrays, used both as input and output;

- 6 functions, each with 6 or 7 arguments, of which 2 or 3 are arrays!]


In EiffelMath

... Set up the non-default properties of e ...

e.solve

... Answer is now in e.x and e.y ...


Our experience: Eiffelbase

Collection classes (“Knuthware”)

Consistency principle

Strict design principles: command-query separation,operand-option separation, taxonomy, uniform access...

Strict interface and style rules


Exercise

Where in an object-oriented hierarchy does the notion of“pseudo-random number” fit ?


Pseudo-random numbers

Traditional scheme:

x := random_start (my_seed)

... loopx := random_next (x)...

end


The exercise

Where in an object-oriented hierarchy does the notion of“pseudo-random number” fit ?


Hints

Hint 1: It’s in the abstraction, stupid


Hints


Hint 2: It’s not “random number”


Hints


Hint 2: It’s not “random number”

Hint 3: I can’t teach you this


Eiffelbase hierarchy

CONTAINER

BOX

FINITE INFINITE

BOUNDED UNBOUNDED

FIXED RESIZABLE

COLLECTION

BAG SET

TABLE ACTIVE SUBSET

DISPENSERINDEXABLE CURSOR_STRUCTURE

SEQUENCE

TRAVERSABLE

HIERAR_CHICAL LINEAR

BILINEAR

*

* * *

*

*

*

*

* *

* * * * * *

* * * * * *

COUNTABLE*


What makes a good data abstraction?

Can talk about it in substantive termsSeveral applicable “features”Some are queries, some are commands

(Ask about instances / Change instances)If variant of other, adds or redefines features

(Beware of taxomania)Corresponds to clear concept of one of:

- Analysis (unit of modeling of some part of theworld)

- Design (unit of architectural decomposition)- Implementation (useful data structure)

Good omens:


What makes a good data abstraction?

“This class does ...”Name is verb, e.g. “Analyse”Very similar to other class

Bad omens:


Abstraction and objects

Analysis classes – examples: AIRPLANE, CUSTOMER,PARTICLE

Design classes – examples: STATE, COMMAND, HANDLEImplementation classes – examples: ARRAY,

LINKED_LIST

Not all classes describe “objects” in the sense ofreal-world things.

Types of classes:

Key to the construction of a good library is thesearch for the best abstractions.


The consistency principle

Top-down and deductive (the overall design).Bottom-up and inductive (the conventions).

Two components:

All the components of a library should proceedfrom an overall coherent design, and follow a setof systematic, explicit and uniform conventions.


Active data structures

OLD INTERFACE FOR LISTS:

l.insert (i,x)l.remove (i)pos := l.search(x)

l.insert_by_value (...)l.insert_by_position (...)l.search_by_position (...)

NEW INTEFACE:

Queries:

l.index l.item l.before l.after

Commands:

l.start l.forth l.finish l.back l.go (i)l.search (x)l.put (x) l.remove

-- Typical sequence

j := l.search (x);

l.insert (j+1,y)

Number offeatures

Number of (re)uses

Perfect

Desirable

?


A list as an active data structure

itembefore after

count

forthback

index


Objects as machines

before after

item index

put_right

startforth


Our exercise

Where in an object-oriented hierarchy does thenotion of “pseudo-random number” fit ?


Top of Eiffelbase hierarchy

CONTAINER

BOX

FINITE INFINITE

BOUNDED UNBOUNDED

FIXED RESIZABLE

COLLECTION

BAG SET

TABLE ACTIVE SUBSET

DISPENSERINDEXABLE CURSOR_STRUCTURE

SEQUENCE

TRAVERSABLE

HIERAR_CHICAL LINEAR

BILINEAR

*

* * *

*

*

*

*

* *

* * * * * *

* * * * * *

COUNTABLE*


A list as an active data structure

itembefore after

count

forthback

index


Random number sequence

item no “after”

no “count” (?)

forth

index

1start (seed)


Getting random numbers

Traditional scheme:

x := random_start (my_seed)... loop

x := random_next (x)...

end


Getting random numbers

Traditional scheme:

x := random_start (my_seed)... loop

x := random_next (x)...

endO-O scheme:

my_sequence: RANDOM... create my_sequence.start (my_seed)... loop

my_sequence.forthx := my_sequence.item

end


Command-query separation principle

Calling a function must not change the target object’s state

This principle excludes many common schemes,such as using functions for input (e.g. C’s getint orequivalent).


Kinds of feature

Command

Query

Feature

Function

No result

Feature

Memory

Computation

Client view(specification)

Internal view(implementation)

Returns result

Attribute

Procedure

Memory

Computation

Routine

Feature Feature


Command-query separation principle

Calling a function must not change the target object’s state

This principle excludes many common schemes,such as using functions for input (e.g. C’s getint orequivalent).


Referential transparency

If two expressions have equal value, it’s OK tosubstitute one for the other.

If a = b, then f (a) = f (b) for any f.

Prohibits functions with side effects.

Also:

For any integer i, normally i+i = 2iBut even if getint() = 2, getint()+getint() is usually not

equal to 4.


Why referential transparency?

“... our intellectual powers are rather geared tomaster static relations and our powers to visualizeprocesses evolving in time are relatively poorlydeveloped. For that reason we should do (as wiseprogrammers aware of our limitations) our utmostto shorten the conceptual gap between the staticprogram and dynamic process, to make thecorrespondence between the program (spread outin text space) and the process (spread out in time)as trivial as possible.”

Dijkstra, GOTO statement consideredharmful, 1968


Command-query separation

Input mechanism (instead of n := getint()):

io.read_integer

n := io.last_integer


Uniform Access principle

Facilities managed by a module must be accessible toclients in the same way whether implemented bycomputation or by storage.


Updating cartesian representation

update_cartesian isrequire

polar_ok: polar_uptodatedo

if not cartesian_uptodate theninternal_x := ro * cos (theta)internal_y := ro * sin (theta)

endensure

cart_ok: cartesian_uptodatepolar_ok: polar_uptodate

end


Accessing the horizontal coordinate

x: REAL is -- Abscissa of current pointdo

if not cartesian_available thenupdate_cartesian

endResult := x_internal

ensurecartesian_ok: cartesian_available

end


Adding two complex numbers

plus (other: COMPLEX ) is -- Add other to current complex number.do update_cartesian

x_internal := x_internal + other.xy_internal := y_internal + other.y

ensurecartesian_ok: cartesian_available

end


Representation invariant

invariant

cartesian_uptodate or polar_uptodate


Uniform access

balance = list_of_deposits.total – list_of_withdrawals.total

list_of_deposits

list_of_withdrawals

balance

list_of_deposits

list_of_withdrawals

(A1)

(A2)


Uniform Access principle

Facilities managed by a module must be accessible toclients in the same way whether implemented by

computation or by storage.


Uniform access through feature call

To access a property of a point p, the Eiffel notation is the sameregardless of the representation, e.g.

p.x

applicable in

cartesian representation (x is an attribute)

polar representation (x is a function)

Field access or computation.

No difference for clients (except speed).


How big should a class be?



As big as it needs to – what matters more isconsistency of the underlying data abstraction

Example: STRING


EiffelBase statistics

Percentages, rounded.

149 classes, 1823 exported features

181 to 142 features441 to 80 features


1111 to 15 features176 to 10 features450 to 5 features

(All statistics here from 1994, but picture hasn’t changed much.)


EiffelVision 1 statistics

Percentages, rounded.

546 classes, 3666 exported features

241 to 78 features621 to 40 features416 to 20 features711 to 15 features


(All statistics here from 1994, but picture hasn’t changed much.)


Minimalism?

Consistent designNamingContracts

Language should be small.

Library should provide as many useful facilities aspossible.

Key to a non-minimalist library:

Usefulness and power


Size of feature interfaces

Statistics from EiffelBase (exported features only):

0.3%Three arguments

3%Two arguments

37%One argument

60%No arguments

3Maximum number

0.4Average number of arguments to a feature

41%Percentage of commands

59%Percentage of queries

1823Number of features



Including non-exported features:

0.6%Five or six arguments

0.6%Four arguments

1%Three arguments

5%Two arguments

36%One argument

57%No arguments

6Maximum number

0.5Average number of arguments to a feature



Statistics from EiffelVision 1 (546 classes, exported only

0.4%Five to seven arguments0.4%Four arguments3%Three arguments15%Two arguments32%One argument

49%No argument7Maximum number0.7Average number of arguments to a feature61%Percentage of commands39%Percentage of queries3666Number of features


Operands and options

Operands: values on which feature will operateOptions: modes that govern how features will operate.

Example: printing a real. The number is an operand;format properties (number of significant digits, width...)are options.

print (real_value, number_of_significant_digits,zone_length, number_of_exponent_digits, ...)

my_window.display(xposition, yposition, height,width, text, title_bar_text, color, ...)

Two possible kinds of arguments to a feature:


Recognizing options from operands

There is a reasonable default value.During the evolution of a class, operands will normally

remain the same, but options may be added.

Two criteria to recognize an option:



THE OPTION PRINCIPLEThe arguments of a feature should only be operands

Options should have default values, with proceduresto set different values if requested.

For example

my_window.set_background_color (“blue”)my_window.display



hiddenset_visibleset_hidden

NoHidden?

background_colorset_background_colorWhiteWindow color

ACCESSEDSETDEFAULTOPTION

Useful checklist for options:


Naming (1)

deletevalueinsertHASH_TABLE

remove_oldestoldestaddQUEUE

poptoppushSTACK

entryenterARRAY

FEATURESCLASS


Naming (2)

removeitemputHASH_TABLE

removeitemputQUEUE

removeitemputSTACK

itemputARRAY

FEATURESCLASS


Naming rules

Signatures (number and types of arguments and result)ContractsComments

Achieve consistency by systematically using aset of standardized names.

Emphasize commonality over differences.

Differences will be captured by:


Some standard names

Queries:countitem, infix "@"to_external, to_c, from_external

Commands:make -- For creationput, extend, replace, forceremove, prune, wipe_out

Boolean queries:writable, readable, extendible, prunableempty, fullcapacity

-- Usual invariants:-- empty = (count = 0)-- full = (count = capacity)

-- Array access:a.item (i) or a @ i

-- Rejected names:if s.addable then

s.add (v)

if s.deletable thens.delete (v)

end

end


Grammatical rules

Procedures (commands): verbs, infinitive form. Examples: make, put,display.

Boolean queries: adjectives, e.g. full. Also (especially in case ofpotential ambiguity) names of the form is_some_property.Example: is_first. In all cases, you should usually choose the form of the

property that is false by default at initialization (making ittrue is an event worth talking about). Example: is_erroneous.

Other queries: nouns or adjectives.Examples: count, error_ window.

Do not use verbs for queries, in particular functions; this goes withthe command-query separation principle (prohibition of side-effects in functions).


Feature categories

class C

inherit…

feature -- Category 1

… Feature declarations

feature {A, B} -- Category 2


feature {NONE} -- Category n


invariant…

end


Feature categories

Standard categories (the only ones in EiffelBase):

Initialization Access Measurement Comparison Status report Status setting Cursor movement Element change Removal Resizing Transformation

Conversion Duplication Basic operations Obsolete Inapplicable Implementation Miscellaneous


Obsolete features and classes

A central problem in the computer field: how to reconcileprogress with the protection of the installed base?

Obsolete features and classes support smooth evolution.

In class ARRAY:

enter (i: V; v: T) isobsolete "Use `put (value, index)’"do

put (v, i)end


Obsolete classes

class ARRAY_LIST [G]

obsolete

"[Use MULTI_ARRAY_LIST instead(same semantics, but new nameensures more consistent terminology).Caution: do not confuse with ARRAYED_LIST(lists implemented by one array each).

]"

inherit

MULTI_ARRAY_LIST [G]

end


Component development

Component development is Formula-1 programming

Perfectionism Is Good

118Chair of Software Engineering

Typical API in a traditional library (NAG)

nonlinear_ode(equation_count: in INTEGER; epsilon: in out DOUBLE; func: procedure

(eq_count: INTEGER; a: DOUBLE; eps: DOUBLE; b: ARRAY [DOUBLE]; cm: pointer Libtype);

left_count, coupled_count: INTEGER …)

[And so on. Altogether 19 arguments, including: 4 in out values; 3 arrays, used both as input and output; 6 functions, each with 6 or 7 arguments, of which 2 or 3 arrays!]


The EiffelMath routine

... Set up the non-default values ...

e.solve

... Answer available in e.x and e.y ...


The Consistency Principle

All the components of a library should proceed from anoverall coherent design, and follow a set of systematic,explicit and uniform conventions.

Two components: Top-down and deductive (the overall design). Bottom-up and inductive (the conventions).


The key to building a library

Devising a theory of the underlying domain


Some of the theory behind EiffelBase

CONTAINER*

BOX* COLLECTION* TRAVERSABLE*

FINITE* INFINITE*

* UNBOUNDED* COUNTABLE*

RESIZABLE*

BAG* SET* HIERARCHICAL* LINEAR*

TABLE* ACTIVE* INTEGER_INTERVAL

* BILINEAR*

INDEXABLE* CURSOR_STRUCTURE

* DISPENSER* SEQUENCE*

STRING HASH_TABLE STACK* QUEUE*

… …

BOUNDED

ARRAY


Active data structures

Old interface for lists:l.insert (i, x)l.remove (i)pos := l.search (x)

l.insert_by_value (…)l.insert_by_position (…)l.search_by_position (…)

New interface:Queries:

l.index l.item l.before l.afterCommands:

l.start l.forth l.finish l.back l.go (i)l.search (x)l.put (x) l.remove

-- Typical sequence:j := l.search (x);l.insert (j + 1, y)

Numberoffeatures

Perfect

Desirable

?

Number of (re)uses


A list seen as an active data structure

itembefore after

count

forthback

index


Command-Query separation principle

A command (procedure) does something but does notreturn a result.

A query (function or attribute) returns a result but doesnot change the state.

This principle excludes many common schemes, such asusing functions for input (e.g. C’s getint or equivalent).


Referential transparency

If two expressions have equal value, one may besubstituted for the other in any context where thatother is valid.

If a = b, then f (a) = f (b) for any f.Prohibits functions with side effects.Also:

For any integer i, normally i + i = 2 x i; But even if getint () = 2, getint () + getint () is usually

not equal to 4.


Command-query separation

Input mechanism (instead of n := getint ()):

io.read_integern := io.last_integer


Libraries and assertions

Include as many visible assertions as possible:

Assertions help design the libraries right.

Preconditions help find errors in client software.

Library documentation fundamentally relies onassertions (interface forms).

APPLICATION

LIBRARY

l.insert (x, j + k + 1)

i <= count + 1

insert (x: G; i: INTEGER)require

i >= 0


Designing for consistency: An example

Describing active structures properly: can after also bebefore?

Symmetry:

For symmetry and consistency, it is desirable to have theinvariant properties.

after = (index = count + 1)before = (index = 0)

start finish

forth back

after before

before

item

after

count

not beforenot after

Valid cursor positions

A


Designing for consistency

Typical iteration:from

startuntil

afterloop

some_action (item)forth

end

Conventions for an empty structure? after must be true for the iteration. For symmetry: before should be true too.

But this does not work for an empty structure (count = 0, seeinvariant A): should index be 0 or 1?


Designing for consistency

To obtain a consistent convention we may transform theinvariant into:

after = (is_empty or (index = count + 1))before = (is_empty or (index = 0)

-- Hence: is_empty = (before and after)

Symmetric but unpleasant. Leads to frequent tests

if after and not is_empty then ...

instead of just

if after then ...

B


Introducing sentinel items

Invariant (partial):0 <= indexindex <= count + 1before = (index = 0)after = (index = count + 1)not (after and before)

A

not afterbefore

not beforeafter

item count count + 10 1

not after; not before1 <= index; index <= count



The case of an empty structure

not afterbefore

not beforeafter

1 (i.e. count + 1)0



Can after also be before?

Lessons from an example; General principles: Consistency

A posteriori: “How do I make this design decision compatiblewith the previous ones?”.

A priori: “How do I take this design decision so that it will beeasy – or at least possible – to make future ones compatiblewith it?”.

Use assertions, especially invariants, to clarify theissues.

Importance of symmetry concerns (cf. physics andmathematics).

Importance of limit cases (empty or full structures).


Abstract preconditions

Example (stacks):

put isrequire

not fulldo

…ensure

…end



The first question is how to measure class size. Candidate metrics: Source lines. Number of features.

For the number of features the choices are: With respect to information hiding:

Internal size: includes non-exported features. External size: includes exported features only.

With respect to inheritance: Immediate size: includes new (immediate) features only. Flat size: includes immediate and inherited features. Incremental size: includes immediate and redeclared features.


The features of a class

Feature of a class

Immediate

Redeclared

Redefined

Effected

Inherited

Kept

New in class

From parent Changed

Unchanged

Was deferred

Had animplementation

Most useful measure is incremental size. Easy to measure.


Incremental size

Feature of a class

Immediate

Redeclared

Redefined

Effected

Inherited

Kept

New in class

From parent Changed

Unchanged

Was deferred

Had animplementation

Most useful measure is incremental size. Easy to measure.


The shopping list approach

If a feature may be useful, it probably is.

An extra feature cannot hurt if it is designed according tothe spirit of the class (i.e. properly belongs in theunderlying abstract data type), is consistent with its otherfeatures, and follows the principles of this presentation.

No need to limit classes to “atomic” features.


11 to 15 features 1116 to 20 features 9

Some statistics from EiffelBase

Percentages, rounded.149 classes, 1823 exported features.

(Includes EiffelLex and EiffelParse, not up to date)



81 to 142 features 1


Language and library

The language should be small

The library, in contrast, should provide as many usefulfacilities as possible.

Key to a non-minimalist library: Consistent design. Naming. Contracts.

Usefulness and power.


Average number of arguments to a feature

The size of feature interfaces

More relevant than class size for assessing complexity.

Statistics from EiffelBase and associated libraries:

Number of featuresPercentage of queriesPercentage of commands

Maximum numberNo argumentOne argumentTwo argumentsThree arguments

182359%41%

0.43

60%37%

3%0.3%



Two possible kinds of argument to a feature: Operands: values on which feature will operate. Options: modes that govern how feature will operate.

Example: printing a real number.The number is an operand; format properties (e.g. number ofsignificant digits, width) are options.

Examples:(Non-O-O) print (real_value, number_of_significant_digits, zone_length, number_of_exponent_digits, ...)

(O-O) my_window.display (x_position, y_position, height, width, text, title_bar_text, color, ...)


Recognizing options from operands

Two criteria to recognize an option:

There is a reasonable default value.

During the evolution of a class, operands will normallyremain the same, but options may be added.


The Option-Operand Principle

Option values: Defaults (specified universally, per type, per object) To set specific values, use appropriate “setter”

procedures

Example:

my_window.set_background_color ("blue")...

my_window.display

Only operands should appear as arguments of a feature



Useful checklist for options:

Option

Window color

Hidden?

Default

White

No

Set

set_background_color

set_visibleset_hidden

Accessed

background_color

hidden


Naming (classes, features, variables…)

Traditional advice (for ordinary application programming):

Choose meaningful variable names!


enter

push

add

insert

Original

Class

ARRAY

STACK

QUEUE

HASH_TABLE

entry

top

oldest

value

pop

remove_oldest

delete

Features

names for EiffelBase classes

put

put

put

put

item

item

item

item

remove

remove

remove

Final

enter

push

add

insert

Class

ARRAY

STACK

QUEUE

HASH_TABLE

remove_oldest

delete

Features

put

put

put

item

item

item

item

remove

remove

remove

entry

top

oldest

valueput

New and old names for EiffelBase classes


Naming rules

Achieve consistency by systematically using a set ofstandardized names.

Emphasize commonality over differences.

Differences will be captured by: Signatures (number and types of arguments and

result). Assertions. Comments.


Some standard names

Queries (non-boolean):count, capacityitemto_external, from_external

Boolean queries:writable, readable, extendible, prunableis_empty, is_full

-- Usual invariants:

0 <= count ; count <= capacity

is_empty = (count = 0)is_full = (count = capacity)

if s.deletable thens.delete (v)

end

-- Some rejected names:if s.addable then

s.add (v)end

Commands:put, extend, replace, forcewipe_out, remove, prunemake -- For creation


Grammatical rules

Procedures (commands): verbs in infinitive form. Examples: make, put, display.

Boolean queries: adjectives Example: full (older convention) Now recommended: is_full, is_first.

Convention: Choose form that should be false by default Example: is_erroneous. This means that making it true is an event worth talking about

Other queries: nouns or adjectives.Examples: count, error_ window.

Do not use verbs for queries, in particular functions; this goes withCommand-Query Separation Principle Example: next_item, not get_next_item


Feature categories

classC

inherit

…

feature -- Category 1


feature {A, B} -- Category 2


feature {NONE} -- Category n


invariant…

end


Feature categories

Standard categories (the only ones in EiffelBase):

Access Measurement Comparison Status report

Basic queries

Status settingCursor movementElement changeRemovalResizingTransformation

Basic commands

Conversion Duplication Basic operations

Transformations

Inapplicable Implementation Miscellaneous

Internal

InitializationCreation


Obsolete features and classes

A constant problem in information technology:How do we reconcile progress with the need to protectthe installed base?

Obsolete features and classes support smooth evolution.

In class ARRAY:

enter (i: V; v: T) isobsolete

"Use `put (value, index)’"do

put (v, i)end


Obsolete classes

classARRAY_LIST [G]

obsolete"[

Use MULTI_ARRAY_LIST instead(same semantics, but new nameensures more consistent terminology).Caution: do not confuse with ARRAYED_LIST(lists implemented by one array each).

]"

inherit

MULTI_ARRAY_LIST [G]

end


Complementary material

OOSC2: Chapter 22: How to find the classes Chapter 23: Principles of class design

Trusted Componentsse.inf.ethz.ch/old/teaching/ws2006/0239/slides/TC2006... · 2006-11-10 ·...

Documents

Transcript of Trusted Componentsse.inf.ethz.ch/old/teaching/ws2006/0239/slides/TC2006... · 2006-11-10 ·...