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

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

Program Heap Stack

Stack frames

MainRout1Routn

Stack growth…

Stack top Stack bottom

Calling a routine

Program Heap Stack

Stack frames

MainRout1Routn…Args

ofRout

Localsof

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

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

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

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

Allocating the buffer

Program Heap Stack

Stack frames

ofRout

Return address

Other locals

Buffer

Getting close

Program Heap Stack

Stack frames

MainRout1Routn…

Return address

Other locals

Buffer

Getting closer

Program Heap Stack

Stack frames

MainRout1Routn…

Return address

Other locals

Buffer

Available !

Inserting the code

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

Quality

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

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

The exercise

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

Hint 1: It’s in the abstraction, stupid

Hint 2: It’s not “random number”

Hint 3: I can’t teach you this

Eiffelbase hierarchy

CONTAINER

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

forthback

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

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

forthback

Random number sequence

item no “after”

no “count” (?)

1start (seed)

Getting random numbers

Traditional scheme:

x := random_start (my_seed)... loop

x := random_next (x)...

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

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

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.

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

Accessing the horizontal coordinate

x: REAL is -- Abscissa of current pointdo

if not cartesian_available thenupdate_cartesian

endResult := x_internal

ensurecartesian_ok: cartesian_available

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

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

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.

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)

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…

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]

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

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

forthback

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

not beforenot after

Valid cursor positions

Designing for consistency

Typical iteration:from

startuntil

afterloop

some_action (item)forth

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

Introducing sentinel items

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

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

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

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%

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

set_background_color

set_visibleset_hidden

Accessed

background_color

hidden

Naming (classes, features, variables…)

Traditional advice (for ordinary application programming):

Choose meaningful variable names!

insert

Original

HASH_TABLE

oldest

remove_oldest

delete

Features

names for EiffelBase classes

remove

insert

HASH_TABLE

remove_oldest

delete

Features

remove

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)

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

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]

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

Anti-military Dictatorship in Myanmar 0239

Design & Deploying Trusted And Un-Trusted VoWiFid2zmdbbm9feqrf.cloudfront.net/2016/usa/pdf/BRKSPM-2127.pdf · Design & Deploying Trusted And Un-Trusted VoWiFi Kasu Venkat Reddy ,

Silver Lake 18-0239-00 - RMBELRMB Environmental Laboratories, Inc. 1 of 19 2015 Silver Lake Silver Lake 18-0239-00 CROW WING COUNTY Lake Water Quality Summary Silver Lake is located

March, 2016 IEEE P802.15-16-0239-00-007a IEEE P802.15 ......March, 2016 IEEE P802.15-16-0239-00-007a Submission Page 3 Kookmin University – PHY 4 modes 1.0 PHY 4 Layer Operating

XP and TDD - Extreme Programming and Test Driven Developmentse.inf.ethz.ch/old/teaching/ws2006/0239/slides/TC2006_… · · 2006-11-01Extreme Programming and Test Driven Development

Software Engineering Outsourcing and Offshoringse.inf.ethz.ch/old/teaching/ws2006/0273/slides/outsourcing_20... · Preparing for reusable components 5. Experimentation: user interface,

PROVIDER NO. 14-0239 ROCKFORD MEMORIAL HOSPITAL …...provider no. 14-0239 rockford memorial hospital kpmg llp compu-max micro system version: 2008.05 period from 01/01/2008 to 12/31/2008

1 Source: Bruce McLarenEducational Technologies WS 2006/07 Educational Technologies WS2006 Authoring Tools - CTAT Bruce M. McLaren Senior Researcher, DFKI.

Software Engineering Outsourcing and Offshoringse.inf.ethz.ch/old/teaching/ws2006/0273/slides/outsourcing_10... · recalls optimistic predictions that the company would "cut the budget

Trusted Cells Trusted Cells: Architecture

0239-17A Fact Sheet - Line 97 DIGITAL EN MECH OL

EDUCATION Trusted Computing Group Trusted Storage ...

Project Management Model for Outsourced Projects Peter Kolbse.inf.ethz.ch/old/teaching/ws2006/0273/slides/PP... · Successful Software Outsourcing and Offshoring - 20 - Transition

A Talking Elevator, WS2006 UdS, Speaker Recognition 1.

Trusted Platform Module Library Part 4: Supporting Routines … · Trusted Platform Module Library Part 4: ... Supporting Routines Trusted Platform Module Library ... Trusted Platform

TRUSTED COMPUTING GROUP TRUSTED STORAGE SPECIFICATION · TRUSTED COMPUTING GROUP TRUSTED STORAGE SPECIFICATION. Jason Cox, Seagate Technology

Trusted Computing Platform Alliance (TCPA) Trusted Platform Module

The PATH to RESTORATION NOAH trusted God… ABRAHAM trusted God… MOSES trusted God… DAVID trusted God… NOW the NEW COVENANT MARY trusted God… JOSEPH trusted.

TB43-0239 Maintenance in the Desert

TRUSTED COMPUTING GROUP TRUSTED STORAGE SPECIFICATION … · TRUSTED COMPUTING GROUP TRUSTED STORAGE SPECIFICATION. Jason Cox, Seagate Technology