Topics in OO, Design Patterns, Reasoning About Program Behavior... (part 4) Neelam Soundarajan Computer Sc. & Eng. e-mail: neelam@cse.

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?

28

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 …