topics in oo, design patterns, reasoning about program behavior... (part 4) neelam soundarajan...
TRANSCRIPT
Topics in OO, Design Patterns, Reasoning About Program
Behavior ...(part 4)
Neelam Soundarajan Computer Sc. & Eng.e-mail: neelam@cse
2
Background
Design PatternsTime-tested solutions to recurring
problems;
PatternsHave fundamentally altered how s/w
is designed;Allow designers to exploit the
collective wisdom of the s/w community.
3
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.
4
Example
Common Problem:Need to keep the states of a set of objects consistent with that of another object.
Solution:Observer Pattern
Subject
Attach(in Obs)
Notify()
Detach(in Obs)
observers*1
ConcreteSubject
-subjectState1
subject*
Observer
Update()
ConcreteObserver
-observerState
Update()
For all o in observers o.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.
Solution: Observer Pattern:
Subject
Attach(in Obs)
Notify()
Detach(in Obs)
6
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?
7
Moreover ...
What does inconsistent mean, anyway?
Further: If we apply pattern correctly, what can we expect in return?
8
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”.
9
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.
10
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.
11
Important Observations ...
A pattern consists of a number of roles : Subject and Observer in Observer pattern.
Particular objects play particular roles.
12
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.)
13
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.
14
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
15
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.
16
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
17
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.
18
Observer -- Pattern level
pattern Observer {roles: Subject, Observer*;state:
Subject: set [Observer] _observers;Observer: Subject _subject;
19
Observer -- Pattern level (contd.)
auxiliary concepts:Consistent( Subject, Observer);Modified( Subject, Subject );
constraint:[~Modified(as1, as2) && Consistent(as1, ao1)]
==> Consistent(as2, ao1)
20
Observer -- Pattern level (contd.)
invariant:(forall ob IN _observers):
Consistent(subject.st, ob.st);
instantiation:<Subject.player, Modified>
Subject enrollment: <false> // not allowedObserver enrollment:
<Consistent, Subject.player.Attach()>
21
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>
22
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] ]
23
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)
24
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.
25
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.
26
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? …
27
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?