1 / 28

Topics in OO, Design Patterns, Reasoning About Program Behavior ... (part 4)

Topics in OO, Design Patterns, Reasoning About Program Behavior ... (part 4). Neelam Soundarajan Computer Sc. & Eng. e-mail: neelam@cse. Background. Design Patterns Time-tested solutions to recurring problems; Patterns Have fundamentally altered how s/w is designed;

guy
Download Presentation

Topics in OO, Design Patterns, Reasoning About Program Behavior ... (part 4)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  5. Subject Subject Observer observers 1 * Attach(in Obs) Attach(in Obs) Update() Notify() Notify() Detach(in Obs) Detach(in Obs) For all o in observers o.Update() ConcreteSubject ConcreteObserver 1 * -observerState -subjectState subject Update() Solution: Observer Pattern: 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.

  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 patternObserver { 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 allowed Observer 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 …

More Related