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

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 2

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

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

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

Wirth, 1995, IEEE Computer Remarkably enough, the abstract data type has reappeared 25 years after its invention under the heading object- oriented. 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. 6

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 operating system, Parnas 1971, Parnas CACM 1972] 7

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

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

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

How O-O helps reuse Inheritance Information hiding Contracts Bottom-up design Design patterns 11

The key ideas: class Merge notions of type and module 12

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 ] 13

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

The key ideas: inheritance Subtyping for taxonomy Module extension and inclusion Powerful consequences:  Polymorphism  Dynamic binding 15

The role of seamlessness “To Program Is To Understand” (Nygaard) 16

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 17

Seamless development Example classes: PLANE, ACCOUNT, Analysis TRANSACTION… STATE,  Single notation, tools, Design COMMAND… concepts, principles  Continuous, incremental Implemen- HASH_TABLE… development tation  Keep model, implementation and documentation consistent TEST_DRIVER… V&V  Reversibility: go back and forth Generali- TABLE… zation 18

G Generalization A D I V A* Prepare for reuse. For example:  Remove built-in limits  Remove dependencies on specifics of project B  Improve documentation, contracts...  Abstract X  Extract commonalities and revamp inheritance hierarchy Z Y Few companies have the guts to provide the budget for this 19

Reversibility Analysis Design Implemen- tation V&V Generali- zation 20

The cluster model Cluster 1 A Cluster 2 D A I D A I V&V D V&V G A I D G V&V I G V&V G 21

Extremes “Clusterfall” “Trickle” A D Cluster 1 A A A I D D D V&V G I I I A V&V V&V V&V D Cluster 2 I G G G V&V G A D Cluster 1 Cluster 2 I V&V G 22

Dynamic rearrangement Cluster 1 A D Cluster 2 I A V&V D G I Cluster 3 V&V A Cluster 4 G D I A V&V D G I V&V G 23

Order of clusters Bottom up: start with most fundamental functionalities, end with user interface V&V A D G I Cluster 3 V&V Cluster 2 A D G I V&V Cluster 1 A D G I 24

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 25

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 26

Contracts in analysis classes deferred class VAT inherit TANK feature in_valve , out_valve : VALVE fill is -- Fill the vat. require in_valve.open out_valve.closed deferred ensure in_valve.closed out_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 27

The role of processes Many process variants exist, from CMMI to XP Choose your process, but enforce it 28