1. Giving a formal meaning to “Specialization” In these note we try to give a formal meaning to specifications, implementations, their comparisons. We define specialization as “conformance” which means that the specialized type satisfies all properties of its super-type. This is the same relationship between a specification and an implementation that satisfies that specification. This is the basis for component re- use. We also discuss that a specification, in general, has two parts: assumptions about the environment and guarantees that the specified component provides. We also give some examples from object-oriented analysis/design and OO programming. Gregor v. Bochmann (February 2003)

2. Specification and implementation A typical example specialization is: the concept of dog is a specialization of the concept of animal. This means that a dog has all the properties that all animals have. In order to formalize this idea, we assume that the specification of a system component C (for instance at the requirements level) is a conjunction of logical properties, let us call them S C. Note that S C also defines a type, that is, the set of all objects that satisfy S C. We assume that an implementation I can also be characterized by the properties it satisfies. Let us call these properties P I. Definition: We say that I conforms to the specification S C if P I implies S C, or P I => S C. This means that I is a suitable implementation which satisfies the requirements.

3. Conforming specifications In the same manner as the properties of an implementation can be compared to a specification by using conformance, also two property specifications C and C’ can be compared by conformance. Definition: Given two specifications S C and S C’ of two components C and C’, respectively, we say that S C’ conforms to S C if S C’ implies S C –this means that all properties specified for S C are implied by the properties specified for S C’ Note: This leads to a possible definition of`the concept of ”specialization” (which is one of the basic concepts in OO analysis and design): S C’ is a specialization of S C if S C’ conforms to S C

4. Possibilities of replacement and reuse Important fact: If S C’ conforms to S C then an implementation conforming to S C’ could be used at any place in a system where a component satisfying the specification S C is foreseen by the system specification. –Proof: Where S C is foreseen, any implementation conforming to S C is acceptable, that is, any implementation with properties I C such that I C implies S C. Now, for any implementation I’ with properties I C’ that conforms to S C’ we have I C’ implies S C’. And since S C’ implies S C we also have that I C’ implies S C which means that I’ is a suitable implementation for S C.

5. Specifications with assumptions and guarantees (A/G) : justification A system component functions within an environment of other components; the component specification must take this environment into account Normally, the properties specified for a component should (only) be satisfied when certain other properties are satisfied by the components in the environment. Examples: –operating temperature should be within a given range (for a computer, or a component thereof) –electrical power supply must be given (idem) –disk must be formatted the right way (for a disk unit) –line length within some bound (text processor)

6. An example: Components, interfaces Example: Electricity counter –I1: electricity input (assumption: less than 100 Amps, less than 300 Volts) –I2: electricity output (guarantee: same current and voltage as at I1) –I3: read-out interface (guarantee: the value provided is equal to the energy (i.e. product of current*voltage*time) that passed through the interface I2) specified component component of environment interface E1 E2C I1 I3 I2 component of environment

7. Specification formalism A/G Form of a specification of a component C: If the environment satisfies the assumption A C then the component C will guarantee the property G C Note: For the case that the assumption is not satisfied, the specification does not say anything about the expected behavior In first-order logic: the specification of C has the form “A C implies G C “ (or “A C => G C “ ) Conformance: As defined above, we say that an implementation conforms to a given specification S C if the properties of the implementation imply the specified properties. Assuming that the specification has the form S C = (A C => G C ), and the properties of the implementation can be characterized in the same form, namely by (A I => G I ), then a conforming implementation must satisfy (A I => G I ) => (A C => G C ). Important Note: [ (A C => A I ) and ( G I => G C ) ] implies [ (A I => G I ) => (A C => G C ) ] Terminology: If X => Y we also say that X is stronger than Y or that Y is weaker than X. Therfore “S C’ conforms to S C “ is equivalent to saying that the guarantees of S C’ are stronger than those of S C and that the assumptions of S C’ are weaker than those of S C, which means [ ( G C’ => G C ) and (A C => A C’ ) ]

8. Composition: Structural refinement (an example) C1 I1 I2 I3 I4 C3 C2 specified component composition : this module C consists of three components, two external interfaces and two internal interfaces C specified component specified component

9. Composition: structural refinement (the formalism) (Abstract) specification of component C: S C (possibly of the form A C => G C ) The refinement of the component in terms of three sub- components C1, C2 and C3 is given by the specifications S Ci, i = 1, 2, 3, respectively (possibly of the form A Ci => G Ci ). The properties of this structural refinement are given by S C1 and S C2 and S C3 If one wants that this refinement conforms to the original specification S C of the component C, one has to verify that ( S C1 and S C2 and S C3 ) => S C In the case that these specifications are of the A/G form, one has to verify that [ (A C1 => G C1 ) and (A C2 => G C2 ) and (A C3 => G C3 ) ] => (A C => G C )

10. Interface specifications: Example Specification of a collection: Property C1: The object offers the two methods put (with an Integer as input parameter, no result) get (no input parameter, and an Integer as result) This specification defines a type of objects: –Any object that satisfies this property belongs to the collection type –The collection type is the set of all object (instances) that satisfy Property C1

11. Interface Specialization Let us consider another property: –Property R1: The object offers the method reset (without any input parameter, nor result) –One may define the type Allow-for-reset which is the set of all objects satisfying R1 One may define the type of objects that satisfy both properties, C1 and R1, let us call it Reset-Collection Reset-Collection is a sub-type of Collection in the sense of OO specialization (an object of type Reset-Collection is also of type Collection ). Clearly (C1 and R1)  C1. This is equivalent to saying that Reset-Collection conforms to Collection. Note: The type Reset-Collection is also a subtype of Allow- for-reset

12. Meaning of an interface specification Property C1 is a definition of an interface. What does it mean precisely? –The fact that put has an input parameter of type Integer means: The called object makes the assumption that, when method put is called, there is an input parameter and its value is of type Integer. –The fact that get has an input parameter of type Integer means: The called object provides the guarantee that, when method get is called, there is an output parameter and its value is of type Integer.

13. Comparing interfaces Given the following interface definitions –Property C1’ defines an interface like C1, except that the type of the input parameter of put is in the range from 0 to 100 (a subrange of Integer). –Property C1’’ defines an interface like C1, except that the type of the output parameter of get is in the range from 0 to 100. –Property C1’’’ defines an interface like C1, except that the type of the input and output parameters are of type range from 0 to 100. How do C1’, C1’’ and C1’’’ compare to C1 ? –Can in implementation of C1’, C1’’ or C1’’’ be used where an implementation of C1 is originally prescribed ? –C1’’ conforms to C1; C1 conforms to C1’ (C1’ has a stronger assumption) “contravariant rule”; incompatibility between C1’’’ and C1 –Generalization of these rules Type checking rules: –When a method is called, does the actual input parameter value conform to the type specified in the interface for this parameter ? –When a method returns a result, does the actual output parameter value conform to the type specified in the interface for this parameter ? –In a strongly typed languages, these checks can be performed by the compiler (by analyzing the source code, without performing an execution of the dynamic behavior)

14. Dynamic behavior There are two aspects of the requirements specification of a component: –Definition of the interface –Definition of the dynamic behavior The Collection interface definition alone allows for the following sequence of method calls: –put(1); put(2); get(5); get(1); get(4) The specification of the dynamic behavior concerns in general two aspects: –In which order may the methods be called ? We may impose property CD1: in any prefix of a valid execution sequence, there should never be more occurrences of get than of put. –What are the conditions on the values of the input parameters (assumptions) and output parameters (guarantees) ? We may impose property CD2: The value of the output parameter of an occurrence of a get must occur as input parameter of a previous invocation of a put in the same execution sequence. Note: this still allows the following sequence: put(1); put(2); get(1); get(1); get(1)

15. Importance of clearly specifying the dynamic behavior Defining the interface is just the first step towards a requirement definition. The dynamic behavior is crucial. Unfortunately, it is often only implied by the name of the method of a class definition. But a more precise definition should always be given. For example, the different object types bag, set, queue, stack (of Integers) all can be defined with the same interface Collection. They also all satisfy the dynamic property CD2. Bag, queue and stack also satisfy CD1. But there are important differences between the latter three. Bag (and set) is non-deterministic, that is, there are in general different choices for the output value of a get method (if several Integers are in the set). For a queue, the FIFO order should, for instance, be specified. Queue and stack are sub-types of bag.

16. Example of composition: checking assumptions We want to build the system shown on the right, where A submits integers in the range 0..100 to the queue and B retrieves these integers. Question: Can we re-use an implementation of the specification Queue(b) in this system ? –Answer: The interface property C1 is not conform with the property C1’’’ (the range of the output of get is not guaranteed to be within the range 0..100. –However, we know that Queue(b) has the FIFO property which implies the property CD2. Now we can prove that we can use Queue(b) in this context as follows: –Module A (part of the environment of Queue(b) ) guarantees that all integers entered into the queue are within the range 0..100; therefore CD2 implies that the output parameters of the get operations are also within this range. Therefore the assumption of B (namely that the range of the output parameter is within this range) is satisfied. put get Queue(a) interface C1’’’ B A put get Queue(b) interface C1

17. Abstract and concrete interfaces Interfaces can be defined at different levels of abstraction At the requirements level (examples of interaction primitives): –Abstract message passing without buffering nor delay (a kind of rendevous) –Message passing with delay (like in SDL) –Abstract (remote) procedure call (implies processing at called side before the operation completes) At the implementation level: –Programming language interface definition (e.g. in Java) –Machine language level interface (e.g. subroutine call with parameter passing conventions) –Realization of interface primitives in hardware Implementation-level interface definitions are often less flexible than the abstract (logical) formulation at the requirements level, or the type checking is incomplete –E.g. Java type checking rules do not distinguish between the C1 and C’’’ properties. –And if we use the parameter types Animals and Dogs instead of Integer and 0..100, respectively, in the same example, then the Java type checking rules do not allow to use an instance of the Queue(b) while the modules A and B expect a Queue(a) interface (even though we can prove that there is no problem from the logical point of view). The Java program of B will have to include type casting to check during execution that the Animals provided as output by the get operation are indeed Dogs.

18. What is a OO class definition ? Type: Specialization as defined in OO analysis and design is based on the concept of type and subtype. A type T defines a set of properties P T, and an object instance is of T if it satisfies the properties P T. The properties of a subtype imply the properties of its supertype. Class: A class definition in Smalltalk or Java defines two types of objects: (1) the type of the dynamically created objects (using the new primitive) which offer all non-static methods and atributes, and (2) the type (which may be called “static type”) offering all static methods and attributes. An instance of the static type exists (at least conceptually) when the program starts its execution. No other instance of the static type can be created during program execution. Class hierarchy: When one talks about class hierarchy and specialization in OO programming, one means the type hierarchy of the “dynamic” objects.

19. Example of a queue factory in Java If we look at the Daemon Game example in SDL, we see that there are Game processes dynamically created. A Monitor process manages them, that is, it creates the Game processes, keeps their identify in an array and sends bump messages to all of them when the Daemon sends its bump message. In Java, one could write a single class Game where the “static type” of the Game class plays the role of the Monitor process in SDL. Here is an example of a queue factory realized by the static type of the Queue class: public class Queue { // static type private Queue() {} private static Queue existingQueues[] ; private static int nbQueues = 0; public static Queue createQueue() { Queue q; if (nbQueues <100) {q = new Queue(); existingQueues[nbQueues] = q; nbQueues =+ 1;} else {q = null;} return(q); } public static void resetAll() {... } // dynamic type public int get() {... } public void put(int i) {... } private void reset() {... } }