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 gt 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 ofthe
  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 SC is foreseen, any implementation
  conforming to SC is 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
interface
E1
I2
component of environment

specified component
I3
I1
E2
C

• 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
  currentvoltagetime) that passed through the
  interface I2)

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 AC implies GC (or AC gt 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 gt GC ) ,
  and the properties of the implementation can be
  characterized in the same form, namely by (AI gt
  GI), then a conforming implementation must
  satisfy (AI gt GI) gt (AC gt GC ) .

8
Specification formalism A/G (ii)

• Important Note
• (AC gt AI ) and ( GI gt GC) implies
• (AI
  gt GI) gt (AC gt GC )
• The inverse is also true under certain conditions
  that are normally satisfied. See Section 2.3 in
  http//beethoven.site.uottawa.ca/dsrg/PublicDocume
  nts/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 gt 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
  gt GC) and (AC gt 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 gt 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 gt GCi) .
• The properties of this structural refinement are
  given by
• SC1 and SC2 and SC3
• If one wants that this refinement conforms to the
  original specification SC of the component C,
  one has to verify that
• ( SC1 and SC2 and SC3 ) gt SC
• In the case that these specifications are
  of the A/G form, one has to verify that
• (AC1 gt GC1) and (AC2 gt GC2 ) and
  (AC3 gt GC3) gt (AC gt 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

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

A
Queue(a) interface C1
B
put
get
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 lt100)
• q new Queue() existingQueuesnbQue
  ues 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() . . .