Giving a formal meaning to “Specialization”

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 SC . Note that SC also defines a type, that is, the set of all objects that satisfy SC . We assume that an implementation I can also be characterized by the properties it satisfies. Let us call these properties PI . Definition: We say that I conforms to the specification SC if PI implies SC , or PI => SC . 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 SC and SC’ of two components C and C’, respectively, we say that SC’conforms to SC if SC’ implies SC • this means that all properties specified for SC are implied by the properties specified for SC’ • Note: This leads to a possible definition of`the concept of  ”specialization” (which is one of the basic concepts in OO analysis and design): SC’ is a specialization of SC if SC’conforms to SC

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

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 component of environment • 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) interface E1 I2 component of environment specified component I3 I1 C E2

7. Specification formalism A/G • Form of a specification of a component C: If the environment satisfies the assumption AC then the component C will guarantee the property GC 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 “ACimplies GC “ (or “AC => GC “ ) • Conformance:As defined above, we say that an implementation conforms to a given specification SC if the properties of the implementation imply the specified properties. Assuming that the specification has the form SC = (AC => GC ) , and the properties of the implementation can be characterized in the same form, namely by (AI => GI), then a conforming implementation must satisfy (AI => GI) => (AC => GC ) .

8. Specification formalism A/G – (ii) • Important Note: [(AC => AI) and( GI => GC) ] implies [ (AI => GI) => (AC => GC ) ] • The inverse is also true under certain conditions that are normally satisfied. See Section 2.3 in http://beethoven.site.uottawa.ca/dsrg/PublicDocuments/Publications/Sand05a.pdf for more details. That article also gives some examples of communicating systems for which specifications of this form are used. • Terminology: If X => Y we also say that X is stronger than Y or that Y is weaker than X. Therfore “SC’ conforms to SC “ is equivalent to saying that the guarantees of SC’ are stronger than those of SC and that the assumptions of SC’ are weaker than those of SC , which means [ ( GC’ => GC) and (AC => AC’ ) ]

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

10. Composition: structural refinement (the formalism) • (Abstract) specification of component C: SC(possibly of the form AC => GC) • The refinement of the component in terms of three sub-components C1, C2 and C3 is given by the specifications SCi, i = 1, 2, 3, respectively (possibly of the form ACi => GCi) . • The properties of this structural refinement are given by SC1and SC2and SC3 • If one wants that this refinement conforms to the original specification SC of the component C, one has to verify that ( SC1and SC2and SC3 ) => SC In the case that these specifications are of the A/G form, one has to verify that [ (AC1 => GC1) and (AC2 => GC2 ) and (AC3 => GC3) ] => (AC => GC)

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

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

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

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

15. 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)

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

17. Example of composition: checking assumptions A Queue(a) interface C1’’’ B put get • 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. Queue(b) interface C1 put get

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

19. 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 PT, and an object instance is of T if it satisfies the properties PT. 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.

20. 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() { . . . } }