So#ware Architecture Prof. Bertrand Meyer, Dr. Michela Pedroni ETH - - PowerPoint PPT Presentation

Chair of Software Engineering

So#ware Architecture

• Prof. Bertrand Meyer, Dr. Michela Pedroni

ETH Zurich, February‐May 2010

Lecture 17: Some key lessons

2

Lessons in software engineering & architecture

The role of object technology The role of reuse The role of seamless development The role of requirements The role of contracts The role of processes

3

The role of object technology

Not just a programming technique A whole view of software development based on abstraction:

• Things are what we can do with them
• This can be specified mathematically (ADTs)

4

Object Winter?

Scott Guthery: Are the Emperor’s New Clothes Object- Oriented?, Dr. Dobb’s Journal, Dec. 1989 (Dec. 1992) Object-oriented programming will soon join the modular programming of the '60s, portable programming of the '70s, and structured programming of the '80s on the paradigm compost heap. One after the other, these breakthroughs to common sense have been converted into reasons to engage in massive translation of perfectly functional code.

5

Brooks, “No Silver Bullet”,

Nevertheless, such advances [as O-O] can do no more than to remove all the accidental difficulties from the expression of the design. The complexity

• f the design itself is essential, and such

attacks make no change whatever in that. An order-of-magnitude gain can be made by object-oriented programming only if the unnecessary type-specification underbrush still in our programming language is itself nine-tenths of the work involved in designing a program product. I doubt it.

6

Wirth, 1995, IEEE Computer

Remarkably enough, the abstract data type has reappeared 25 years after its invention under the heading object-

• riented. This modern term’s essence,

regarded by many as a panacea, concerns the construction of class (type) hierarchies. Although the older concept hasn’t caught on without the newer description “object-oriented”, programmers recognize the intrinsic strength of the adt and convert to it.

7

Parnas (IEEE Computer, 1996)

Wirth appears critical of the purveyors of techniques that use the buzzword “object-oriented” for having reinvented the ideas behind the older concept of abstract data type. However, many would argue that abstract data type itself was a reinvention (refinement) of ideas that appeared in even earlier work [citations: Dijkstra’s THE

• perating system, Parnas 1971, Parnas CACM 1972]

8

Stendhal, Vie de Henry Brulard

Cela m'ouvrit l'esprit, j'entrevis ce que c'était que se servir de l'instrument nommé algèbre. Du diable si personne me l'avait jamais dit; sans cesse M. Dupuy faisait des phrases emphatiques sur ce sujet, mais jamais ce mot simple: c'est une division du travail qui produit des prodiges comme toutes les divisions du travail et permet à l'esprit de réunir toutes ses forces sur un seul côté des objets, sur une seule de leurs qualités. Quelle différence pour nous si M. Dupuy nous eût dit: Ce fromage est mou ou il est dur; il est blanc, il est bleu; il est vieux, il est jeune; il est à moi, il est à toi; il est léger

• u il est lourd. De tant de qualités ne considérons absolument que le
• poids. Quel que soit ce poids, appelons-le A. Maintenant, sans plus

penser absolument au fromage, appliquons à A tout ce que nous savons des quantités. Cette chose si simple, personne ne nous la disait dans cette province reculée; depuis cette époque, l'École polytechnique et les idées de Lagrange auront reflué vers la province.

9

Stendhal, Leben des Henry Brulard

Es hat mir die Augen geöffnet. Ich sah was es bedeutet das Algebra genannte Werkzeug zu benutzen. Unaufhörlich machte [der Lehrer] emphatische Sätze über diesesThema, aber niemals dieses einfache Wort: es ist eine Arbeitsteilung, die wie alle Arbeitsteilungen Wunder herstellt und dem Geist ermöglicht seine Kraft ganz auf eine einzige Seite von Objekten zu konzentrieren, auf eine Einzige ihrer Qualitäten. Welch Unterschied für uns, wenn uns Herr Dupuy gesagt hatte: Dieser Käse ist weich oder er ist hart; er ist weiss, er ist blau; er ist alt, er ist jung; er gehört dir, er gehört mir; er ist leicht oder er ist schwer. Bei so vielen Qualitäten betrachten wir unbedingt nur das Gewicht. Was dieses Gewicht auch sei, nennen wir es A. Jetzt, ohne unbedingt weiterhin an Käse denken zu wollen, wenden wir auf A alles an, was wir über Mengen wissen. Diese einfach Sache sagte uns niemand in dieser zurückgezogenen Provinz; von dieser Epoche an werden die polytechnische Schule und die Ideen von Lagrange in die Provinz zurückgeflossen sein.

10

The role of reuse

Reuse (McIlroy, 1968) Software components (routines), to be widely applicable to different machines and users, should be available in families arranged according to precision, robustness, generality and time-space performance. The most important characteristic of a software components industry is that it will offer families of routines for any given job. No user of a particular member

• f a family should pay a penalty, in unwanted generality,

for the fact that he is employing a standard model routine. In other words, the purchaser of a component from a family will choose one tailored to his exact needs.

11

How O-O helps reuse

Inheritance Information hiding Contracts Bottom-up design Design patterns

12

The key ideas: class

Merge notions of type and module

13

The key ideas: ADTs

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 ]

14

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

15

The key ideas: inheritance

Subtyping for taxonomy Module extension and inclusion Powerful consequences:

• Polymorphism
• Dynamic binding

16

The role of seamlessness

“To Program Is To Understand” (Nygaard)

17

Seamless, incremental development

Seamless development:

• Single set of notation, tools, concepts, principles throughout
• Continuous, incremental development
• Keep model, implementation and documentation consistent

Reversibility: can go back and forth These are in particular some of the ideas behind the Eiffel method

18

Seamless development

• Single notation, tools,

concepts, principles

• Continuous, incremental

development

• Keep model, implementation

and documentation consistent

• Reversibility: go back and

forth

Example classes: PLANE, ACCOUNT, TRANSACTION… STATE, COMMAND… HASH_TABLE… TEST_DRIVER… TABLE…

Analysis Design Implemen- tation V&V

Generali- zation

19

Generalization

Prepare for reuse. For example:

• Remove built-in limits
• Remove dependencies on

specifics of project

• Improve documentation,

contracts...

• Abstract
• Extract commonalities and

revamp inheritance hierarchy Few companies have the guts to provide the budget for this B A* Y X Z

A D I V

G

20

Reversibility

Analysis Design Implemen- tation V&V

Generali- zation

21

The cluster model

Cluster 1 Cluster 2

A D I V&V G A D I V&V G A D I V&V G A D I V&V G

22

Extremes

Cluster 1 Cluster 2

A D I V&V G A D I V&V G A D I V&V G

A D I V&V G “Trickle” “Clusterfall” A D I V&V G A D I V&V G

Cluster 1 Cluster 2

23

Dynamic rearrangement

Cluster 1

A D I V&V G

Cluster 2

A D I V&V G A D I V&V G

Cluster 3

A D I V&V G

Cluster 4

24

Order of clusters

Bottom up: start with most fundamental functionalities, end with user interface

A D I V&V G A D I V&V G A D I V&V G

Cluster 1 Cluster 3 Cluster 2

25

The role of requirements

Software does not exist in a vacuum A key aspect of the difference between programming and software engineering is the central role of requirements (domain + machine) “Big Upfront Requirements” or continous process

26

The role of contracts

Software has semantic properties Contracts appear throughout the lifecycle and throughout software tasks:

• Getting the analysis right (abstract and precise)
• Directing the design
• Guiding the implementation
• Controlling the test process
• Controlling the proof process
• Producing the documentation
• Guiding the maintenance process
• Providing managers with the right information

27

deferred class VAT inherit TANK feature in_valve, out_valve: VALVE fill is

• - Fill the vat.

require in_valve.open

• ut_valve.closed

deferred ensure in_valve.closed

• ut_valve.closed

is_full end empty, is_full, is_empty, gauge, maximum, ... [Other features] ... invariant is_full = (gauge >= 0.97 * maximum) and (gauge <= 1.03 * maximum) end

Contracts in analysis classes

The role of processes

Many process variants exist, from CMMI to XP Choose your process, but enforce it

28

29

Software engineering

“Software engineering” is about “DIAMON”:

• Description: specify (systems, designs,

implementations...) and document

• Implementation: build the products; this includes design

as well as programming

• Assessment: verify, validate, analyze, test, measure

(both products and processes)

• Management: organize the work, communicate,

collaborate

• Operation: deploy systems and oversee their proper

functioning

• Notation: use or devise formalisms appropriate for every

task of software development