1. Design Refinement: From Patterns to System Implementation Neelam Soundarajan 1 Computer Science & Engineering Ohio State University ( 1 Joint work with Jason Hallstrom, Jason Kirschenbaum, Ben Tyler, Johan Dovland and others.)

2. Design Refinement: From Patterns to System Implementations 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. Design Refinement: From Patterns to System Implementations 3 Example Common Problem: Need to keep the states of a set of objects consistent with that of another object. Solution: Observer Pattern

4. Subject Attach(in Obs) Notify() Detach(in Obs) observers *1 Observer Update() 1 ConcreteObserver -observerState subject * Update() For all o in observers o.Update() Idea:When Subject state changes, call Notify(). Notify() calls Update() on each Observer. Solution: Observer Pattern: ConcreteSubject -subjectState

5. SubjectObserver ConcreteSubject ConcreteObserver Attach(in Obs) Notify() Detach(in Obs) -subjectState -observerState subject observers *1 1 * Update() For all o in observers o.Update() Question:What does Update() do? Answer:It must update the state Observer state to make it consistent with the new Subject state. Solution: Observer Pattern:

6. Design Refinement: From Patterns to System Implementations 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. Design Refinement: From Patterns to System Implementations 7 Moreover... What does inconsistent mean, anyway? Further: If we apply pattern correctly, what can we expect in return?

8. Design Refinement: From Patterns to System Implementations 8 Main goal of our work... 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. Design Refinement: From Patterns to System Implementations 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. Design Refinement: From Patterns to System Implementations 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. Design Refinement: From Patterns to System Implementations 11 Important Observations... A pattern consists of a number of roles : Subject and Observer in Observer pattern. Particular objects play particular roles.

12. Design Refinement: From Patterns to System Implementations 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. Design Refinement: From Patterns to System Implementations 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. Design Refinement: From Patterns to System Implementations 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. Design Refinement: From Patterns to System Implementations 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. Design Refinement: From Patterns to System Implementations 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. Design Refinement: From Patterns to System Implementations 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. Design Refinement: From Patterns to System Implementations 18 Observer -- Pattern level pattern Observer { roles: Subject, Observer*; state: Subject: set [Observer] _observers; Observer: Subject _subject;

19. Design Refinement: From Patterns to System Implementations 19 Observer -- Pattern level (contd.) auxiliary concepts: Consistent( Subject, Observer); Modified( Subject, Subject ); constraint: [~Modified(as1, as2) && Consistent(as1, ao1)] ==> Consistent(as2, ao1)

20. Design Refinement: From Patterns to System Implementations 20 Observer -- Pattern level (contd.) invariant: (forall ob IN _observers): Consistent(subject.st, ob.st); instantiation: Subject enrollment: // not allowed Observer enrollment:

21. Design Refinement: From Patterns to System Implementations 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}) &&

22. Design Refinement: From Patterns to System Implementations 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. Design Refinement: From Patterns to System Implementations 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. Design Refinement: From Patterns to System Implementations 24 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.

25. Design Refinement: From Patterns to System Implementations 25 Some Key Lessons (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. Design Refinement: From Patterns to System Implementations 26 Current / Future Work Run-time monitoring of systems to check that pattern specs are met by each pattern instance Visualization of pattern instances Patterns for distributed computing Problems involving complex chains of references -- including circular references.

27. Design Refinement: From Patterns to System Implementations 27 Thanks! Questions? e-mail: neelam@cse.ohio-state.edu