1. Responsibilities and Rewards: Reasoning about Design Patterns Neelam Soundarajan Computer Science & Engineering Ohio State University Joint work with Jason Hallstrom, Ben Tyler,...

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

3. Reasoning About Design Patterns3 Example... Common Problem: Need to keep the states of a set of objects consistent with that of another object.

4. Attach(in Obs) Detach(in Obs) ConcreteSubject -subjectState 1 subject * ConcreteObserver -observerState 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:

5. Reasoning About Design Patterns5 Why use patterns? Exploits collective wisdom of community Common vocabulary for designers Reuse of designs, not just code.

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

7. Reasoning About Design Patterns7 Background (contd.) Patterns are usually described informally Many pattern catalogs (GoF, POSA1, POSA2,...) Informal descriptions are very useful, but...

8. Reasoning About Design Patterns8 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,...

9. Reasoning About Design Patterns9 Potential Risk in Formalizing... Flexibility may be lost! My goal: Find a way to provide precise specs while retaining flexibility.

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

11. Attach(in Obs) Detach(in Obs) ConcreteSubject -subjectState 1 subject * ConcreteObserver -observerState 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:

12. Reasoning About Design Patterns12 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?

13. Reasoning About Design Patterns13 And, moreover... What does inconsistent mean, anyway? Further: If we apply pattern correctly, what can we expect in return?

14. Reasoning About Design Patterns14 Goal of the research... Provide precise answers to such questions

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

16. Reasoning About Design Patterns16 Important Observations... A pattern consists of a number of roles... Subject and Observer in our case. Particular objects play particular roles.

17. Reasoning About Design Patterns17 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.)

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

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

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

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

22. Reasoning About Design Patterns22 Observer Pattern Spec: Pattern-level pattern Observer { roles: Subject, Observer*; state: Subject: set [Observer] _observers; Observer: Subject _subject;

23. Reasoning About Design Patterns23 Pattern-level Spec (contd.) auxiliary concepts: Consistent( Subject, Observer); Modified( Subject, Subject ); constraint: [~Modified(as1, as2) && Consistent(as1, ao1)] ==> Consistent(as2, ao1)

24. 24 Pattern-level Spec (contd.) invariant: (forall ob IN _observers): Consistent(subject.st, ob.st); instantiation: Subject enrollment: // not allowed Observer enrollment:

25. Reasoning About Design Patterns25 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}) &&

26. 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] ]

27. Role-level Spec: Observer role spec Observer { methods: void Update(): requires: true; preserves: _subject; ensures: Consistent(_subject.as, this) others: preserves: _subject; ensures: Consistent(_subject.as, this)

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

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

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

31. Reasoning About Design Patterns31 Thanks! Questions? Slides available at:.../~neelam/TALKS/885Oct1210Talk.ppt Papers at:.../~neelam/papers

32. Reasoning About Design Patterns32 Thanks! Questions? Slides available at:.../~neelam/TALKS/885Oct1210Talk.ppt Papers at:.../~neelam/papers

33. Reasoning About Design Patterns33 Thanks! Questions? Slides available at:.../~neelam/TALKS/885Oct1210Talk.ppt Papers at:.../~neelam/papers

34. Reasoning About Design Patterns34 Thanks! Questions? Slides available at:.../~neelam/TALKS/885Oct1210Talk.ppt Papers at:.../~neelam/papers

35. Subject Attach(in Obs) Notify() Detach(in Obs) observers *1 ConcreteSubject -subjectState 1 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)