Computer Science 340
Software Design & Testing
The Theory of Specialization
1
Review of Design by Contract
• Every method has a pre-condition and a
post-condition.
• The pre-condition, if true, guarantees the
post-condition will be true
• The post-condition defines whether or not
the method executed correctly.
2
The Contract
• If, when a user calls a method and
satisfies the pre-condition of the
method, then, when the method is
finished executing the post-condition will
be true.
3
Observations
• If the pre-condition was true but the
post-condition was false then there is a
bug in the implementation of the
method.
• If the pre-condition is false, then, the
post-condition can be either true or
false.
• A false pre-condition does NOT mean
the post-condition must be false.
4
The Semantics of Method
Specialization
• Assume there is a class C with method m whose precondition is mpre and whose post-condition is mpost
• Assume there is a class C’, a specialization of C
• Furthermore, C’ has a method m’ with pre-condition m’pre
and post-condition m’post
• m’ is a specialization of m
• All the promises made by m must still hold in m’
– This is the meaning of method specialization
• A specialization m’ can do what ever it wants but it can never
break a promise made by m
• Guarantees the Liskov substitution principle
5
Queue Example
• Let C be the class Queue
– The domain of Queue is
list : sequence<Student>
• Let m be the method remove()
• mpre = the list is not empty
• mpost = the new list is one element shorter than the old list 
the new list is equal to the old list from location 1 in
the old list to the last location in the old list

result = the student at location 0 of the old list
6
SuperQueue
• Let C’ be the class SuperQueue which is a specialization of
Queue
– The domain of SuperQueue remains the same
• Let m’ be the method remove for a SuperQueue
• mpre = the list may or may not be empty
• mpost =
if the list is not empty
the post-condition of the method remove in Queue must hold

if the list is empty
the list remains unchanged  result = null
7
Observations
• The class SuperQueue is written so that
any instance can substitute for any
Queue.
• If our writing of the pre- and postconditions were unrestricted then the
SuperQueue could break the promises
made by the remove method of the
class Queue.
• Can you give an example?
8
To Guarantee Method
Semantics Preservation
• m’pre must be weaker then mpre
– Mathematically: mpre  m’pre
– From the Queue/SuperQueue example
The list is not empty  the list may or may not be
empty
9
Furthermore
• m’post must be stronger than mpost
– Mathematically: m’post  mpost
– From the Queue/SuperQueue example
if the SuperQueue is empty then
it remains unchanged and a null is returned
else
the first element of the SuperQueue is removed
and returned
IMPLIES
the first element of the SuperQueue is removed
and returned
10
Result
• If the two restrictions hold we can prove
that the semantics of the method
specialization will never conflict with the
semantics of the generalization.
• We satisfy the Liskov substitutability
principle
11
Guaranteed Semantics
Preservation:
Mathematical View
(mpre  mpost)



(m’pre  m’post)
12
A Problem
• Assume we have another method for
the Queue : push(Student s)
• The pre-condition is : s is a Student
• The post-condition is:
The list is one bigger than before.
The last element of the new list = s.
Everything else in the new list remains
unchanged.
13
A Problem Continued
• In SuperQueue we specialize the push to
be push(GradStudent g)
• Assume GradStudent is a sub-type of
Student
• The pre-condition is : g is a GradStudent
• The post-condition remains unchanged
14
A Problem Continued
• The push operation seems a reasonable thing to
do. We are still just adding students to the end of
the queue.
• However, the rules of method specialization only
allow us to weaken the pre-condition and thus
weaken the parameter type. The Student type of
the push method in Queue must be a sub-type of
the parameter type defined in the corresponding
method of SuperQueue.
• This is called contra-variance and is a rule
established by Barbara Liskov and accepted by
most academicians.
15
What Is the Problem?
• The Person parameter type is not a precondition.
• The previously presented semantics of
method specialization stated that the violation
of a pre-condition does not guarantee the
invocation of the method will fail.
• However, if the input parameter is not a
Person, we guarantee there is an error. This
is so serious that we try to catch it at
compilation time.
16
What Is the Parameter Type in
Our Example?
• It is a requirement.
• For every method there are not only
pre-conditions and post-conditions but
also requirements.
17
Requirements
• A failed requirement guarantees when a method invocation
will fail.
• It true requirement does not guarantee the method will
succeed.
• Requirements may not only be expressed as parameter
types, but also as Boolean expressions. For instance, we
could have made it a requirement that if you were to execute
the remove operation on a Queue, then the queue could not
be empty. We changed the pre-condition into a requirement.
• Note: Parameters are not only restricted to having types
defining the requirements, but, may have a second type that
defines the pre-condition. Thus, a parameter may have two
types. It is also possible to have a parameter that only has a
single pre-condition type and not a requirement type. 18
The Revised Semantics of a
Method
• A method’s requirements must be met
and, if the pre-condition is true then the
post-condition will be true.
19
Revisions to the Semantics of
Method Specialization
• If we want to guarantee that the semantics of
a method in a specialization does not violate
the semantics of its generalization in the
super-class then three rules must hold:
• The first two rules are the same as before
1. You can only weaken pre-conditions
2. You can only strengthen post-conditions
• We now add a third rule
3. You can only strengthen requirements
20
Back to the Example
• Since the type Student in the push method of
the Queue class is a requirement, we can
strengthen the parameter type in the push
method of the SuperQueue class to be
GradStudent.
• Thus, the method push(GradStudent g) in
the SuperQueue class is now a legal
specialization of the push(Student s) in the
Queue class.
21
Observation
• If the pre-condition of the remove
operation of a Queue was changed to a
requirement, that is, you can never try to
remove a Student from an empty queue,
then we cannot specialize the remove
operation in SuperQueue to legally
execute if the queue is empty.
Requirements can only be strengthened.
22
Revised Guaranteed
Semantics Preservation:
Mathematical View
(mrequirements  (mpre  mpost))




(m’requirements  (m’pre  m’post))
23
Graphical Form
Inputs that are in the black circle must also be in the outer circle.
Inputs that satisfy the pre-conditions must also satisfy the
requirements.
These inputs are guaranteed to succeed.
They satisfy the pre-condition.
Input Space
These inputs are guaranteed
to fail. They do not
satisfy the
requirements.
These inputs may succeed or fail. They
satisfy the requirements but not the pre-conditions.
24
Method Specialization in
terms of the Graphic
• Weakening the pre-condition enlarges the black
inner disk. You can only enlarge the black circle.
• Strengthening the requirements makes the outer
circle smaller. You can only make the outer circle
smaller.
• This can continue until
requirements = pre-conditions
• At that point the method is invariant. No
subsequent specialization may strengthen the
25
requirements nor weaken the pre-condition.