Responsibilities and Rewards:Reasoning about Design Patterns

Neelam Soundarajan Computer Science & Engineering

Ohio State University

Joint work with Jason Hallstrom, Ben Tyler, ...

Reasoning About Design Patterns 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.

Reasoning About Design Patterns 3

Example ...

Common Problem:Need to keep the states of a set

of objects consistent with that of another object.

Attach(in Obs)

Detach(in Obs)

ConcreteSubject

-subjectState 1subject

*

ConcreteObserver

-observerState

Update()

Update()Notify()

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.

observers*1

ObserverSubject

Solution: Observer Pattern:

Reasoning About Design Patterns 5

Why use patterns?

Exploits collective wisdom of community

Common vocabulary for designers

Reuse of designs, not just code.

Reasoning About Design Patterns 6

Background

Patterns allow designers to design and document their designs.

New designers can get a good idea of how a system is designed and why it behaves in certain ways

...

Reasoning About Design Patterns 7

Background (contd.) Patterns are usually described

informally Many pattern catalogs

(GoF, POSA1, POSA2, ...)

Informal descriptions are very useful, but ...

Reasoning About Design Patterns 8

Thesis ... To fully realize the benefits of patterns,

we must have precise specs ...

... else possibility of conflicting interpretations of how to apply a pattern... or how to make changes to a system, ...

Reasoning About Design Patterns 9

Potential Risk in Formalizing ...

Flexibility may be lost!

My goal: Find a way to provide

precise specs while retaining

flexibility.

Reasoning About Design Patterns 10

Talk Outline What is a design pattern?

Example: Observer pattern Background Problems with informal descriptions of

Observer Roles, auxiliary concepts, ... Specification of Observer Future work ...

Attach(in Obs)

Detach(in Obs)

ConcreteSubject

-subjectState 1subject

*

ConcreteObserver

-observerState

Update()

Update()Notify()

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.

observers*1

ObserverSubject

Solution: Observer Pattern:

Reasoning About Design Patterns 12

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?

Reasoning About Design Patterns 13

And, moreover ...

What does inconsistent mean, anyway?

Further: If we apply pattern correctly, what can we expect in return?

Reasoning About Design Patterns 14

Goal of the research ...

Provide precise answers to such questions

Reasoning About Design Patterns 15

Potential Risk ...

If we use one particular precise meaning of consistent or change in our formalization, the pattern may not beapplicable in other situations.

Reasoning About Design Patterns 16

Important Observations ...

A pattern consists of a number of roles ... Subject and Observer in our case.

Particular objects play particular roles.

Reasoning About Design Patterns 17

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 o3 may be the same object.

(Same object can’t play two roles in the same instance.)

Reasoning About Design Patterns 18

Key Ideas Auxiliary concepts: represent

notions such as consistency, change in state, etc.

Actual definition of AC’s will be specific to pattern instance.

Pattern spec will be in terms of AC’s

Reasoning About Design Patterns 19

Key Ideas (contd.) Pattern spec will impose

constraints on the ACs.

The reward of using the pattern will be in terms of an invariant over all the objects playing roles in the pattern.

Reasoning About Design Patterns 20

Some Details ...

Spec consists of a pattern-level portion, &

a role-specific portion (for each role). Pattern-level:

role names, state for each role; auxiliary concepts, constraints on them; conditions for creating new pattern instance,

enrolling in various roles; invariant –the reward– for using the pattern.

Reasoning About Design Patterns 21

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

Reasoning About Design Patterns 22

Observer Pattern Spec: Pattern-level

pattern Observer {roles: Subject, Observer*;state:

Subject: set [Observer] _observers;

Observer: Subject _subject;

Reasoning About Design Patterns 23

Pattern-level Spec (contd.)

auxiliary concepts:Consistent( Subject, Observer);Modified( Subject, Subject );

constraint:[~Modified(as1, as2) && Consistent(as1, ao1)]==> Consistent(as2, ao1)

24

Pattern-level Spec (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()>

Reasoning About Design Patterns 25

Role-level Spec: Subject

role spec Subject {methods:void Attach(Observer ob):requires: (ob = caller) // Omit this?preserves: as; // “application state”ensures: (_observers = _observers@pre U {ob}) &&<call: ob.Update>

Role-level Spec: Subject (contd) others:

preserves: _observers;ensures:[~Modified(this@pre, this)] OR[exists k: [ cs[k].m = Notify ] ] //Bug!

[~Modified(this@pre, this)] OR[exists k: [ cs[k].m = Notify ] && [~Modified(cs[k].st, this)] && [forall j>k: cs[j].m != Notify] ]

Role-level Spec: Observerrole spec Observer {

methods:void Update():requires: true;preserves: _subject;ensures: Consistent(_subject.as, this)others:preserves: _subject;ensures: Consistent(_subject.as, this)

Reasoning About Design Patterns 28

Some Key Lessons

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.

Reasoning About Design Patterns 29

Key Lessons (contd)Formalizing allowed us to enhance

flexibility: Standard descriptions suggest: no

change in Observer except by Update().Not necessary! Consistent() provides a more flexible requirement.

Similar situation for other patterns.

Reasoning About Design Patterns 30

Current and Future Work

Run-time monitoring of systems to check violations of pattern contracts.

Creating tests to check satisfaction of pattern contracts.

Visualization of pattern instances. Consider patterns for distributed computing. Etc.

Reasoning About Design Patterns 31

Thanks! Questions?

Slides available at:.../~neelam/TALKS/885Oct1210Talk.ppt

Papers at:.../~neelam/papers

Reasoning About Design Patterns 32

Thanks! Questions?

Slides available at:.../~neelam/TALKS/885Oct1210Talk.ppt

Papers at:.../~neelam/papers

Reasoning About Design Patterns 33

Thanks! Questions?

Slides available at:.../~neelam/TALKS/885Oct1210Talk.ppt

Papers at:.../~neelam/papers

Reasoning About Design Patterns 34

Thanks! Questions?

Slides available at:.../~neelam/TALKS/885Oct1210Talk.ppt

Papers at:.../~neelam/papers

Subject

Attach(in Obs)Notify()

Detach(in Obs)

observers*1

ConcreteSubject

-subjectState 1subject

*

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)