Topics in OO, Design Patterns,
Reasoning About Program Behavior ...
(part 4)
Neelam Soundarajan
Computer Sc. & Eng.
e-mail: neelam@cse
Background

Design Patterns
Time-tested solutions to recurring problems;

Patterns
Have fundamentally altered how s/w is
designed;
Allow designers to exploit the collective
wisdom of the s/w community.
2
What is a Design Pattern?



Fact: Variations of the same problem appear in different
systems.
Fact: A core solution –a pattern– can be used to solve such
problems.
Advantages:
Exploits collective wisdom of community;
Common vocabulary for designers;
Reuse of designs, not just code.
3
Example


Common Problem:
Need to keep the states of a set of objects
consistent with that of another object.
Solution:
Observer Pattern
4
Solution: Observer Pattern:
Observer
Subject
Attach(in Obs)
Notify()
observers
1
*
Update()
Detach(in Obs)
For all o in observers
o.Update()
ConcreteSubject
-subjectState
ConcreteObserver
1
* -observerState
subject
Update()
Idea:
When Subject state changes, call Notify().
Notify() calls Update() on each Observer.
Each Observer has to update its state to make it
consistent with the new Subject state.
But ...



What does “change in subject state” mean?
Change in a single bit/byte?
Std. ans.: Subject notifies observers when a change
occurs that could make its state inconsistent with
that of an observer.
But how will the subject know this has happened?
6
Moreover ...


What does inconsistent mean, anyway?
Further: If we apply pattern correctly, what can we
expect in return?
7
Goal of formalization ...


Provide precise answers to such questions
Guiding Principle:
 In the same way that patterns enable designers
to reuse good solutions to recurring problems,
our formalism should enable
designers/implementers to reuse the
corresponding reasoning, testing, ... efforts in
ensuring that system designs are “correct”.
8
Potential risk ...

If we use one particular precise meaning of
consistent or change in our formalization, the
pattern may not be applicable in other situations.
9
But as it turns out ...




No sacrifice in flexibility ...
Often can identify additional flexibility dimensions
(missing in standard descriptions of the patterns)!
Designers can check that their implementations
faithful to the underlying design (patterns).
Can help system maintainers to preserve
design integrity.
10
Important Observations ...


A pattern consists of a number of roles :
Subject and Observer in Observer pattern.
Particular objects play particular roles.
11
Pattern Instances

There may be several instances of a pattern at a
given time (during execution).
E.g.:
s1, o1, o2 may form one instance;
s2, o3, o4, o5 may form another.
o1 and o2 may be the same object.
(Same object can’t play two roles in the same
instance.)
12
Approach

Pattern P will be specified by a pattern contract PC

System S designed using P will have a subcontract SPC


PC specifies requirements/guarantees applicable to all
systems designed using P
SPC defines how P is specialized for use in S.
13
Key Ideas



Auxiliary concepts: represent notions such as
consistency, change in state, etc.
Actual definition of AC’s --tailored to the system-will be part of the subcontract.
Pattern contract will be in terms of AC’s
14
Key Ideas (contd.)


Pattern contracts will impose constraints on
Auxiliary Concepts
The pattern contract will specify invariants as well as
conditions satisfied by various methods provided the requirements, including the constraints,
are satisfied.
15
Some Details

Pattern contract:



A pattern-level portion
A role-specific portion (for each role).
Pattern-level:
 role names, state for each role
 auxiliary concepts, constraints
 conditions for creating new pattern instance,
enrolling in various roles

pattern invariant
16
Some Details (contd.)

For each role:
 pre- and post- conditions for each method that
the role must provide
 conditions for other methods of the role
 All of these in terms of role’s state component
and auxiliary concepts.
17
Observer -- Pattern level
pattern Observer {
roles: Subject, Observer*;
state:
Subject: set [Observer] _observers;
Observer: Subject _subject;
18
Observer -- Pattern level (contd.)
auxiliary concepts:
Consistent( Subject, Observer);
Modified( Subject, Subject );
constraint:
[~Modified(as1, as2) && Consistent(as1, ao1)]
==> Consistent(as2, ao1)
19
Observer -- Pattern level (contd.)
invariant:
(forall ob IN _observers):
Consistent(subject.st, ob.st);
instantiation:
<Subject.player, Modified>
Subject enrollment: <false> // not allowed
Observer enrollment:
<Consistent, Subject.player.Attach()>
20
Role contract: Subject
role spec Subject {
methods:
void Attach(Observer ob):
requires: (ob = caller) // Omit this?
preserves: applState; // “application state”
ensures:
(_observers = _observers@pre U {ob}) &&
<call: ob.Update>
21
Role contract: Subject (contd.)

others:
preserves: _observers;
ensures:
[~Modified(this@pre, this)] OR
[exists k: [ callSeq[k].m = Notify ] ]

//Bug!
[~Modified(this@pre, this)] OR
[exists k: [callSeq[k].m = Notify ] &
[~Modified(callSeq[k].st, this)] &
[forall j>k: callSeq[j].m != Notify] ]
22
Role contract: Observer
role spec Observer {
methods:
void Update():
requires: true;
preserves: _subject;
ensures: Consistent(_subject.as, this)
others:
preserves: _subject;
ensures: Consistent(_subject.as, this)
23
Some Key Points
Formalizing patterns allowed us to identify/eliminate
potential problems:


Incompatibility between Modified and
Consistent
Failing to make the Observer consistent with the
Subject on attaching.
24
Some Key Points (contd.)
Formalizing allowed us to enhance flexibility:
 Standard descriptions suggest: no change in an
observer except by Update().
Not necessary!
Consistent() provides a more flexible
requirement.

Similar situation for other patterns.
25
Open Questions




Isn’t the contract for Observer too restrictive?
Can’t a call to Update() change the subject state?
If we want to allow for such changes, how do we
ensure that only reasonable activites are allowed?
Does it make sense to specify a pattern in the same
style as specifying individual classes?
Wouldn’t it make more sense to specify the whole
group of objects involved in a pattern instance?
But how? …
26
Open Questions (contd.)




Are our auxiliary concepts sufficiently powerful?
E.g.: Can the observers be organized in a chain so
that the subject directly invokes Update() on the
first observer?
Or into several cohort groups? Etc.?
In general: Shouldn’t we allow the pattern of
interactions to be also specialized in different ways
in individual applications?
But how?
27
Open Questions (contd.)

Pattern hierarchies: Can patterns be organized into
suitable hierarchies? Would it be useful to do so?

Pattern mining? There has been some work on this …

Others …
28