Covariance - ETH Z

Covariance - ETH Z

Chair of Software Engineering Software Architecture Prof. Bertrand Meyer, Dr. Michela Pedroni ETH Zurich, February-May 2010 Lecture 5: Designing for reuse What exactly is a component? A component is a 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 the components author tells them. This is a broad view of components It encompasses patterns and frameworks Software, especially with object technology, permits pluggable components where client programmers can insert their own mechanisms. Supports component families Why reuse? Faster time to market Guaranteed quality Ease of maintenance

Consumer view Producer view Standardization of software Preservation of know-how practices Component quality The key issue in a reuse-oriented software policy Bad-quality components are a major risk Deficiencies scale up, too High-quality components can transform the state of the software industry The culture of reuse From consumer to producer Management support is essential, including financial The key step: generalization

A reuse policy The two principal elements: Focus on producer side Build policy around a library Library team, funded by Reuse Tax Library may include both external and internal components Define and enforce strict admission criteria Traditional lifecycle model Feasibility Separate tools: Programming environment study Analysis & design tools, Requirement s e.g. UML Specificatio n

Consequences: Hard to keep model, implementation, documentation consistent Constantly reconciling views Inflexible, hard to maintain systems Hard to accommodate bouts of late wisdom Wastes efforts Damages quality Global design Detailed design Implementation V&V

Distribution A seamless model Seamless development: notation, tools, concepts, principles throughout Continuous, incremental development Keep model, implementation documentation consistent Analysis Single Reversibility: back and

forth Design Implemen tation V&V Generalization Example classes: PLANE, ACCOUNT, TRANSACTION STATE, COMMAND HASH_TABLE TEST_DRIVER TABLE The cluster model

Mix of sequential and concurrent engineering A D A I D V I G V G

A D I V G Permits dynamic reconfiguration A D I V G Levels of reusability 0 - Usable in some program 1 - Usable by programs written by the same author

2 - Usable within a group or company 3 - Usable within a community 4 - Usable by anyone Nature or nurture? Two modes: Build and distribute libraries of reusable components (business model is not clear) Generalize out of program elements A D I

V (Basic distinction: Program element --- Software component) G Generalization A D I V 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 G A* B X Y Z Keys to component development Substance: Rely on a theory of the application domain

Form: Obsess over consistency High-level: design principles Low-level: style Design principles Object technology: Module Type Design by Contract Command-Query Separation Uniform Access Operand-Option Separation Inheritance for subtyping, reuse, many variants Bottom-Up Development Design for reuse and extension Style matters Designing for reuse Formula-1 programming

The opportunity to get things right 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 ) Ordinary differential equation [And so on. Altogether 19 arguments, including: 4 in out values; 3 arrays, used both as input and output; 6 functions, each 6 or 7 arguments, of which 2 or 3

arrays!] The EiffelMath routine ... Create e and set-up its values (other than defaults) ... e.solve . . ... Answer available in e x and e y ... The Consistency Principle All the components of a library should proceed from an overall 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 What makes a good data abstraction? Good signs: Can talk about it in substantive terms Several 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 the world) - Design (unit of architectural decomposition) - Implementation (useful data structure) Design smells Signs that a proposed class may not be right

This class does ... Name is verb, e.g. Analyze Very similar to other class Abstraction and objects Not all classes describe objects in the sense of real-world things. Types of classes: Analysis classes examples: AIRPLANE, CUSTOMER, PARTICLE Design classes examples: STATE, COMMAND, HANDLE Many classes associated with design patterns fall into this category Implementation classes examples: ARRAY, LINKED_LIST

Key to the construction of a good library is the search for the best abstractions The key to building a library Devising a theory of the underlying domain Eiffelbase hierarchy * CONTAINER Representation * BOX * INFINITE * FINITE

* BOUNDED * FIXED * UNBOUNDED * RESIZABLE Access * COLLECTION * COUNTABLE *

INDEXABLE * BAG * TABLE * CURSOR_ STRUCTURE * SET * ACTIVE * DISPENSER

Iteration * TRAVERSABLE * HIERAR_ CHICAL * SUBSET * SEQUENCE * LINEAR * BILINEAR

Active data structures --- Typical Typical use: use: jj := := ll search search (x); (x); ll insert insert (( jj + + 1, 1, y) y) 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 () . ? Perfect Number

of features Desirable New interface: Queries: . . . l index l item Commands: . . l start

(x) l put (x) . l before . l forth l finish l remove . Number of (re)uses . l after

. l back . l go (i) . l search A list seen as an active data structure before after item "Zurich" 1

Curs back forth or start finish index count Beyond internal cursors Internal cursors, as in the preceding example, have disadvantages: Poorly adapted to recursive routines and concurrency Programmers need to remember to reset cursor, e.g. . backup := l index from start until after loop some_operation (l item)

. l forth end l go_i_th (backup) . . External cursor The cursor becomes an object: "Zurich" 1 count

Operations on a cursor c : c start c forth . . c.index c.item . c after and other commands and other queries Loop construct with built-in cursor Instead of local c : CURSOR []

. from c.start until c.after loop some_operation (c.item) c.forth create c make (my_list) end just use (EiffelStudio 6.5): . across my_list as c loop some_operation (c item) end Structures class must be a descendant of ITERABLE. This is the case (6.6) with lists, across loop for predicates across my_integer_list as c all

. c item > 0 end . across my_integer_list as c some c item > 0 end Uniform access Uniform Access principle It does not matter to the client whether you look up or compute Uniform access balance = list_of_deposits.total list_of_withdrawals.total list_of_deposits list_of_deposits (A1) list_of_withdrawals

list_of_withdrawals balance balance (A2) list_of_deposits list_of_deposits list_of_withdrawals A self-adapting complex number class class COMPLEX feature {NONE } x_internal, y_internal, ro_internal, theta_internal : REAL cartesian_available, polar_available : BOOLEAN update_cartesian require polar_ok: polar_available do if not cartesian_available then internal_x := ro * cos (theta) internal_y := ro * sin (theta)

cartesian_available := True end ensure cart_ok: cartesian_available polar_ok: polar_available end Representation invariant invariant cartesian_available or polar_available Accessing the horizontal coordinate feature x : REAL -- Abscissa of current point do update_cartesian Result := x_internal ensure cartesian_ok: cartesian_available end

Adding two complex numbers plus (other : COMPLEX ) -- Add other to current complex number. do update_cartesian x_internal := x_internal + other.x y_internal := y_internal + other.y ensure cartesian_ok: cartesian_available end Commands and queries Command-Query Separation principle A query must not change the target objects state Command-Query separation principle A command (procedure) does something but does not return a result. A query (function or attribute) returns a result but

does not change the state. This principle excludes many common schemes, such as using functions for input (e.g. Cs getint) Feature classification (reminder) Client view (specification) Comma nd Procedure Routin e No result Featur e Returns

result Query Internal view (implementation) Function Computat ion Memor y Attribute Computat ion Featur Feature Memor e

y Command-Query Separation Principle Asking a question should not change the answer! Referential transparency If two expressions have equal value, one may be substituted for the other in any context where that other 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 using EiffelBase (instead of n := getint ()):

. io read_integer . n := io last_integer Libraries and contracts Include appropriate contracts: Contracts help design the libraries right. Preconditions help find errors in client software.

Library documentation fundamentally relies on contracts (interface views). APPLICATION l.insert (x, j + k + 1) LIBRARY insert (x : G; i : INTEGER) require i >= 0 i <= count + 1 Designing for consistency: An example Describing active structures properly: can after also be before? not before before Symmetry: start finish

forth back after before not after item after count Valid cursor positions For symmetry and consistency, it is desirable to have

the invariant properties. after = (index = count + 1) A before = (index = 0) List with cursor before after item "Zurich" 1 Curs back forth or start finish index count

Designing for consistency Typical iteration: from start until after loop 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, see invariant A): should index be 0 or 1? Designing for consistency To obtain a consistent convention we may transform the invariant into: after

B = (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 <= index index <= count + 1 before = (index = 0) A after = (index = count + 1) not (after and before) not after ; not before

1 <= index; index <= count before not after 0 1 item Valid cursor positions count after not before count +

1 The case of an empty structure 0 before not after 1 (i.e. count + 1) after not before Valid cursor positions Can after also be before? Lessons from an example; General principles: Consistency

A posteriori: How do I make this design decision compatible with the previous ones?. A priori: How do I take this design decision so that it will be easy or at least possible to make future ones compatible with it?. Use assertions, especially invariants, to clarify the issues. Importance of symmetry concerns (cf. physics and mathematics). Importance of limit cases (empty or full structures).

Abstract preconditions Example (stacks): put require not full do ensure end How big should a class be? 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. Feature classification (reminder) Client view (specification) Comma nd Procedure Routin e No result Featur

e Returns result Query Internal view (implementation) Function Computat ion Memor y Attribute Computat ion Featur

Feature Memor e y Another classification Incremental size Immediate Redefined New in class Feature of a class From parent Had an implementation Redeclared Was deferred Changed

Effected Inherited Unchang ed Kept The shopping list approach If a feature may be useful, it probably is. An extra feature cannot hurt if it is designed according to the spirit of the class (i.e. properly belongs in the underlying abstract data type), is consistent with its other features, and follows the principles of this presentation. No need to limit classes to atomic features. How big should a class be? As big as it needs to what matters more is consistency of the underlying data abstraction

Example: STRING_8 154 immediate features 2675 lines of code EiffelBase statistics Percentages, rounded. 250 classes, 4408 exported features 0 to 5 features 43 6 to 10 features 14 11 to 15 features 10 16 to 20 features

4 21 to 40 features 17 41 to 80 features 9 81 to 142 features 2 (All measures from version 6.0, courtesy Yi Wei) EiffelVision on Windows Percentages, rounded. 733 classes, 5872 exported features 0 to 5 features

64 6 to 10 features 14 11 to 15 features 8 16 to 20 features 5 21 to 40 features 7 41 to 80 features 2

EiffelVision on Linux Percentages, rounded. 698 classes, 8614 exported features 0 to 5 features 63 6 to 10 features 13 11 to 15 features 8 16 to 20 features 5 21 to 40 features

8 41 to 80 features 2 Language and library The language should be small The library, in contrast, should provide as many useful facilities as possible. Key to a non-minimalist library: Consistent design. Naming. Contracts. Usefulness and power. The size of feature interfaces More relevant than class size for assessing complexity. Statistics from EiffelBase and associated libraries: Number of features

4408 Percentage of queries 66% Percentage of commands 34% Average number of arguments to a feature Maximum number 0.5 5 No arguments 57%

One argument 36% Two arguments 6% Three or more arguments 1% Size of feature interfaces Including non-exported features: Average number of arguments to a feature Maximum number 0.6 12 No arguments

55% One argument 36% Two arguments 7% Three arguments 2% Four arguments 0.4% Five or six arguments

0.1% Size of feature interfaces EiffelVision on Windows (733 classes, exported only) Number of features 5872 Percentage of queries 56% Percentage of commands 44% Average number of arguments to a feature 0.5 Maximum number

10 No argument 67% One argument 23% Two arguments 6% Three arguments 1.5% Four arguments

1.5% Five to seven arguments 0.6% Size of feature interfaces EiffelVision on Linux (698 classes, exported only) Number of features 8614 Percentage of queries 56% Percentage of commands 44% Average number of arguments to a feature

0.96 Maximum number 14 No argument 49% One argument 28% Two arguments 15% Three arguments

4% Four arguments 2% Five to seven arguments 1% Operands and options 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 of significant 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 normally remain the same, but options may be added. The Option-Operand Principle Only operands should appear as arguments of a feature 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 Operands and options Useful checklist for options: Option Default Window color White

Hidden? No Set set_background_color set_visible set_hidden Accessed background_color hidden Naming (classes, features, variables) Traditional advice (for ordinary application programming):

Choose meaningful variable names! for EiffelBase classes Original New Final and names old names for EiffelBase classes Class ARRAY Features put enter put entry item item

enter STACK QUEUE HASH_TABLE push put put put add put put insert put entry item top item

remove pop remove push add top oldest item oldest remove_oldest remove item remove remove_oldest insert value itemvalu

item e remove delete remove delete Naming rules Achieve consistency by systematically using a set of standardized names. Emphasize commonality over differences. Differences will be captured by: Signatures (number and types of arguments & result) Assertions Comments Some standard names

Queries (non-boolean): count, capacity item to_external, from_external Commands: put, extend, replace, force wipe_out, remove, prune make -- For creation Boolean queries: writable, readable, extendible, prunable is_empty, is_full -- Usual invariants: 0 <= count ; count <= capacity is_empty = (count = 0) is_full = (count = capacity) -- Some rejected names: if s addable then s add (v) end

if s deletable then s delete (v) end 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 with Command-Query Separation Principle Example: next_item, not get_next_item Feature categories class C inherit feature -- Category 1 Feature declarations feature {A, B } -- Category 2 Feature declarations feature {NONE } -- Category n Feature declarations invariant end Feature categories

Standard categories (the only ones in EiffelBase): Initialization Creation Access Measurement Comparison Status report Basic queries Conversion Duplication Basic operations Transformation s

Status setting Cursor movement Element change Removal Resizing Transformation Basic commands Inapplicable Implementation Miscellaneous Internal

Obsolete features and classes A constant problem in information technology: How do we reconcile progress with the need to protect the installed base? Obsolete features and classes support smooth evolution. In class ARRAY: enter (i : V ; v : T) obsolete "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 name

ensures more consistent terminology). Caution: do not confuse with ARRAYED_LIST (lists implemented by one array each). ]" inherit MULTI_ARRAY_LIST [G ] end Summary Reuse-based development holds the key to substantial progress in software engineering Reuse is a culture, and requires management commitment (buy in)

The process model can support reuse Generalization turns program elements into software components A good reusable library proceeds from systematic design principles and an obsession Complementary material OOSC2: Chapter 22: How to find the classes Chapter 23: Principles of class design

Recently Viewed Presentations

  • Presentazione di PowerPoint

    Presentazione di PowerPoint

    Akanthos Ensemble è stato invitato da festivals e stagioni europee quali Festival "Ars Musica" della SWF Rottenburg, Sonopolis - Teatro La Fenice Venezia, Bucarest, Fondazione Scelsi Roma, La Spezia, Musica Verticale - Goethe Institut Roma, Perspektiven Heilbronn, Würzburg, Freiburg, Teatro...
  • 12-1 Chapter Twelve Stress and Conflict McGraw-Hill/Irwin  2002

    12-1 Chapter Twelve Stress and Conflict McGraw-Hill/Irwin 2002

    Chapter Twelve Stress and Conflict Learning Objectives Define the meaning of stress Identify the extraorganizational, organizational, and group stressors Examine individual dispositions of stress Describe intraindividual and interactive conflict Discuss the effects of stress and conflict Present strategies for coping/managing...
  • Traffic Signs, Signals, and Road Markings

    Traffic Signs, Signals, and Road Markings

    Describe the actions to take at STOP, YIELD, and speed limit signs. List five situations where warning signs might be used. Explain what to do at a green light, yellow light, and a red light. Describe the action to take...
  • APOSTROPHE - Winston-Salem/Forsyth County Schools

    APOSTROPHE - Winston-Salem/Forsyth County Schools

    APOSTROPHES with Contractions Can always be avoided: just write out the words and don't ( do not ) join them with an apostrophe! The SECOND reason to use an apostrophe is…
  • Tower Safety Austin, TX August 11, 2016 Sim

    Tower Safety Austin, TX August 11, 2016 Sim

    During this workshop, industry stakeholders, along with worker safety advocates and the families of communication tower workers who had been killed on the job, gathered to discuss the issues surrounding tower safety. This presentation contains portions of the OSHA/FCC Best...
  • Economic Systems Part 2

    Economic Systems Part 2

    Complete Study Guide by writing out all relevant notes and material for person, term, concept, etc. on the Study Guide Learning Objectives Analyze advantages and disadvantages of Capitalism, Socialism, and Communism
  • PowerPoint Presentation to Accompany Chapter 6 Digital Devices

    PowerPoint Presentation to Accompany Chapter 6 Digital Devices

    HD movie mode <#> 2. Bridging the Gap: Transferring Photos. ... Photo kiosks in retail stores have built-in editing features, so you can connect your camera via USB or use a memory card. ... Android(Samsung, HTC, $200* Verizon 2 yrs...
  • The Challenge: To Create More Value in All Negotiations

    The Challenge: To Create More Value in All Negotiations

    Within a few moments, Sam had driven his score up to an elite level of 70. …" —Mark Schaeffer, ROI/Return on Influence: The Revolutionary Power of Klout, Social Scoring, and Influence Marketing "When Virgin America opened its Toronto route, it...