Presented by Daniel Silva

Transcribed by Ethan Aubin

Component Software - Szyperski
A component has three properties:

What are the implications of this? You can package your component and sell it by itself. Composition requires components have well defined interfaces and meets certain other guarantees. Since components have no observable state, copies cannot be distinguished.

Components are not small necessary small things and can have significant size e.g. a browser. Components units are third party composition. E.g. you can plug an independently deployed component like Internet Exlorer into another independently deployed component like Powerpoint.

Question: Is Szyperski using state in a different sense of the word? E.g. If a database has no observable state its not very useful.
A database and a database component are not the same thing. Its the component which has no observable state. A component in Szyperski's sense is the 'blueprint' of how to put pieces together.

An object is a unit of instantiation with unique identiy, may have state, and encapsulates behavior. Szyperski lives in a time when C++ the dominant programming language and objects are seen as a good method of encapsulation and composition. He contrasts OO with OO with components and concludes that OO cannot play the role of components. He does not account for OO proponents saying that a framework playes the role of the components.

Szyperski's book is market orientied, combining economics with components. This is an old idea going back to at least the 1968 Nato software engineering conference. At that time, what people had in mind were libraries. Around 1971-1972, notion of module and notion of a module contract was introduced. There was work in 1970's resulting in the module systems of the Modula-2, Modula-3 and Ada. Szyperski reexamines the thesis that what we really want is components. There is a market of components. When one component breaks, just replace it with another from a different vender. He knows he wants more than libraries and OO, but doesn't know what.

Design by contract, Building OO Software

June 4, 1996 Ariane 5 crashed 40 seconds after launch. 500 millions were lost. A 64 bit integer was attempted be put in a 16-bit register, the overflow was detected and an exception was thrown.

Meyers sees this as a motivation for design by contract. Contracts should be in the language. Eiffel has mechanisms to preconditions, postconditions and invariants.

However, Eiffel does not handle methods being overriden properly. Suppose we have the following classes (in psuedocode):

class A {
  void m() {...}
  @precondition p
  @postcondition q
}

class B extends A {
  void m() {...}
  @precondition p'
  @postcondition q'
}
What is the relationship between the pre/post conditions of A.m() and B.()? The precondition p must imply the precondition p', and the postcondition q' must imply the postcondition q'.

Question: So after the rocket crashes, we know who to blame?
Yes, but the use of contracts is to give an earlier indication of when conditions are broken.

Ariane 5 was tested with Ariane 4 flight data which used 16-bit sensors. This was a failure of testing. They knew about the bug, which is why they throw the exception.

Units

Lets say there is a class Shape with a method draw and three subclasses which implement it Triangle, Circle and TranslatedShape in one package. Can we add another subclass and add new functionality to all shapes without changing or recompiling the code? One could use units which are components with explicit links to dependencies and exports.

What Matthew Flatt understood was that there is a basic flaw in every system of component, that is the links are internal. The exception is MLs module system, the links are external and hooked up functor application. So can MLs modules system be used to implement Model-View components? No, the because dependecies are tree shaped. There is a hack of passing a higher order function, which is abstracted over what you get back. So the module system is not really abstract from the core language, i.e. you must use feature of the core language (higher-order functions) to use components.