1. POAD Book: Chapter 10 POAD: The Design Refinement Phase Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU

2. Outline n Review of POAD Process n This lecture focuses on the design refinement phase. n This phase has 3 main activities – Instantiating the pattern internals – Developing class diagrams, – Optimizing the design

3. Acquaintan ce Pattern Library Candidate Patterns Selection Selected Patterns Application Requirements Requirem ent Analysis Required Conceptual Components Retrieval Pattern-Level Diagrams Constructing Pattern-Level models Create Pattern Instances Define Pattern Relationships Construct Pattern-Level Diagrams Constructing models for Pattern-Level with Interfaces Pattern-Level with Interfaces Diagrams Declare Pattern Interfaces Identify Relationships between Pattern Interfaces Constructing models for Detailed Pattern-Level Detailed Pattern- Level Diagrams Selected Patterns (c) Design Instantiating Pattern Internals Domain Specific Detailed Pattern-Level Diagrams Specializatio n Concretizatio n Develop Class Diagrams Initial UML class diagram Design Optimization Reductio n Merging & Grouping Optimized class diagram Detailed Pattern- Level Diagrams (d) Design Refinement Analysis Design Design Refinement (b) Analysis (a) Overall POAD The POAD process a) overall phases, b) analysis, c) design, and d) design refinement

4. Instantiating Pattern Internals Domain Specific Detailed Pattern-Level Diagrams Specialization Concretization Develop Class Diagrams Initial UML class diagram Design Optimization Reduction Merging & Grouping Optimized class diagram Detailed Pattern- Level Diagrams The Design Refinement phase.

5. Instantiating Pattern Internals n Purpose- to create an application-specific instances of the patterns used in the Design phase n Process- instantiation process involves describing the patterns and their constituents in an application specific context – Instantiation is 2 parts; first part defining a pattern instant and its interfaces as preformed in the previous phase, the second part of pattern internals is the subject of this phase.

6. Instantiating Pattern Internals n Specialization (generic -> application specific) – The pattern’s Class diagram is very general, not application specific. – During Design-refinement, the generic design is specialized, specialization includes: renaming classes, methods and relationships, and adding domain specific details

7. Instantiating Pattern Internals n Specialization cont’d – Renaming pattern internals involve. n Revealing the internal class diagram model for each pattern instance. n Renaming the internal classes of each insatnce according to the application design environment. n Giving application specific names for the methods/operations in each pattern class. – Example, feedback control system, readings from plant are processed then compared to user input

8. Instantiating Pattern Internals – difference between processed readings (feedback data) and preset input is used to trigger a control action – Designer uses ErrorObserver instance of type observer to monitor feedback data. – Abstract subject is the abstract interface for the component observed. The concrete subject represents the implementation of the abstract interface, therefore the ConcreteSubject is named FeedbackSubject as shown in the next slide

9. ErrorObserver > Notify Subject Attach() Detach() Notify() Observer Update() ErrorObserver observerState Update() FeedbackSubject subjectState getState() ErrorObserver > Subject Attach() Detach() Notify() Observer Update() ConcreteObserver observerState Update() ConcreteSubject subjectState getState() Before specialization After specialization

10. Instantiating Pattern Internals n Instantiation through subclassing and realization – The class diagram for any pattern contains abstract classes and concrete classes. The abstract classes my only be interfaces or they could have implemented, default functions, etc. – During instantiation designer determines which abstract classes will be implemented, and the concrete subclasses needed. – Instantiation through realization. n When abstract class is pure, the implementation class that realizes the interface is defined

11. Instantiating Pattern Internals – Instantiation by subclassing n When the abstract class has default implementation, the designer defines an implementation and determines which methods to use and which methods to override. n Keeping History of Participants’ Names – The underlying models should keep track of the name changes. – History tracking enables traceability between models.

12. Instantiating Pattern Internals n Concretization- bringing abstract design to a more concrete form – Concretization is different from specialization. – During concretization abstract designs are turned into concrete ones by selecting among design alternatives n Scope- We have shifted out focus from design of the overall application to the internals of each pattern

13. Instantiating Pattern Internals n Product- The application-specific Detailed Pattern-Level design Diagrams. n The following slides will show the patterns for the feedback control system instantiated

14. FeedforwardStrategy (from POAD1-Feedback) > ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() AbstractController AlgorithmInterface() Controller ContextInterface() Controller Instantiating the FeedforwardStrategy pattern

15. ErrorObserver (from POAD1-Feedback) > ErrorObserver observerState Update() FeedbackSu bject subjectState GetState() AbstractSubject Attach() Detach() Notify() AbstractObserver Update() nn Update Notify Instantiating the ErrorObserver pattern

16. UpdateNotify FeedbackObserver (from POAD1-Feedback) > Measurement Subject subjectState GetState() FeedbackObs erver observerState Update() AbstractObserver Update() AbstractSubject Attach() Detach() Notify() nn Instantiating the FeedbackObserver pattern

17. Blackboard (from POAD1-Feedback) > Blackboard setData() getData() DataHolder getData setData nn ErrorDataMeasuredDataFeedbackData Instantiating the Blackboard pattern

18. FeedbackStrategy (from POAD1-Feedback) > Feedback ContextInterface() FBAbstractController AlgorithmInterface() FBConcreteStrategy A AlgorithmInterface() FBConcreteStrategy B AlgorithmInterface() Feedback Instantiating the FeedbackStrategy pattern

19. Instantiating Pattern Internals Domain Specific Detailed Pattern-Level Diagrams Specialization Concretization Develop Class Diagrams Initial UML class diagram Design Optimization Reduction Merging & Grouping Optimized class diagram Detailed Pattern- Level Diagrams The Design Refinement phase.

20. Developing Initial Class diagram n Purpose – To develop a class diagram of the application using the class diagrams of the pattern instances n Process – We will use the diagrams from the previous phase, the pattern interfaces and instantiated details of the pattern internals to generate a UML class diagram.

21. Developing Initial Class diagram – Revealing the Instantiated Pattern Internals n Previously the application-specific pattern instances were developed. n The classes and methods have application specific names and can thus be used as the basis for the initial class diagram. – Tracing Pattern Interfaces to internal Realization n Previously we determined the relationships between pattern internals n Now, we are tracing each interface to the internal pattern participant that implements it

22. Developing Initial Class diagram n The following diagram shows this step tracing each interface to the internal pattern participant that implements it Interface 2 PatternInstance1 > PatternInstance2 > Interface 1 ? ? ?

23. Developing Initial Class diagram n Each interface is realized by an internal participant, this means that the interface can be traced back to the element implementing or defining it using a UML realization n Consider FeedforwardStrategy and the ErrorObserver Pattern discussed previously, the following diagram shows there interfaces and the elements that implement them

24. FeedforwardStrategy > ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() AbstractController AlgorithmInterface() Controller ContextInterface() Context ErrorObserver > ErrorObserver observerState Update() FeedbackSubject subjectState GetState() Subject Attach() Detach() Notify() Observer Update() nn Notify

25. Developing Initial Class diagram – Tracing the Relationship between pattern instances n Using the relationship between interface and the traceability between interface and pattern internal the designer establishes relationship between internals of the 2 pattern instances. n Interfaces can be interface operations or methods; there are several relationships – Class/Class – Class/Operation – Operation/Operation n After All tracing and realization we get a class diagram

26. ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() AbstractController AlgorithmInterface() Controller ContextInterface() ErrorObserver observerState Update() FeedbackSubject subjectState GetState() Subject Attach() Detach() Notify() Observer Update() nn

27. Developing Initial Class diagram n Product – The initial UML class diagram for the application design

28. Initial Class Diagram Feedback Control System

31. Instantiating Pattern Internals Domain Specific Detailed Pattern-Level Diagrams Specialization Concretization Develop Class Diagrams Initial UML class diagram Design Optimization Reduction Merging & Grouping Optimized class diagram Detailed Pattern- Level Diagrams The Design Refinement phase.

32. Design Optimization n Purpose – To optimize the class diagram, and prepare it for implementation. n Process – We use Reduction, merging and grouping to optimize the class diagram. n Reduction – Consider a scenario where we have multiple instances of the same type – Multiple instances indicate multiple abstract class

33. Design Optimization – The abstract class is seldom implemented, it is as source for subclassing and realization. n Reduction is the process where the replicated abstract class is removed. n The two classes must be similar – In the case of interfaces the common interface class has to provide the same interface signature

34. ErrorObserver > Subject Attach() Detach() Notify() Observer Update() ErrorObserver observerState Update() FeedbackSubject subjectState getState() SensorObserver > Subject Attach() Detach() Notify() Observer Update() FeedbackObserver observerState Update() SensorSubject subjectState getState() (a) (b)

35. Subject Attach() Detach() Notify() Observer Update() FeedbackObserver observerState Update() SensorSubject subjectState getState() ErrorObserver observerState Update() FeedbackSubject subjectState getState() (c)

36. Design Optimization – In the case of the abstract class n The common classes must provide same interface, and default implementation. n Merging and Grouping – Sometimes patterns contain classes with trivial responsibilities – Some classes just forward a message to another class – These classes should carry other functionality in the application besides the functionality that they provide.

37. Design Optimization – See the Strategy pattern; the Context class is only the interface, thus the context class would have to play additional roles in the application design (See Figure in Next slide). – Instead of using one class for trivial tasks, designer might consider merging classes from more than one pattern instance – 2 important steps to remember in merging n identifying which classes to merge n defining how to merge the classes

38. FeedforwardStrategy > Context ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() Context ContextInterface() Strategy AlgorithmInterface()

39. Design Optimization – Identifying which classes means the designer must study the pattern internals and the relationships between instances, The pattern internal design and pattern documentation can indicate which classes are candidates for merging. – Another method for determining merge candidates is by studying the pattern relationships. n Relationships are between 2 pattern participants, these 2 participants are candidates for merging

40. Design Optimization – POAD uses Hard merge. n Hard merge - designer merges the two classes to produce one class that has no conflicting methods and attributes – When we merge two classes that have no class relationship between them, the new class will have relationships with other application classes

41. Design Optimization – When we merge two classes that have an association relationship, the association between the two original classes is retained in the merged class as calls between internal class methods – Consider the merging activity in the Feedback control application

42. ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() AbstractController AlgorithmInterface() ContextInterface() ErrorObserverController observerState Update() FeedbackSubject subjectState GetState() Subject Attach() Detach() Notify() Observer Update() nn The ErrorObserver is merged with the context Class of the Strategy pattern

43. Design Optimization n Product - An optimized class diagram for the application, which is more dense and more profound

44. Refined Class Diagram for feedback control system (case study 1)

45. The Feedback Control Example Object Collaboration Diagram Measurement : MeasurementSubject Error : ErrorObserver F_controller : AbstractController Strategy1 : ControlStrategyA FB_Strategy : FBControlStrategyA 5: MeasurePlant ( ) Feedback : FeedbackSubjectObserver TheBlackboard: Blackboard 9: Notify() 12: GetInput() 13: Analyze() 7: FBApply () 8: Update () 10: Update() 11: Getstate() 3: Update ( ) 4: GetState ( ) 6: Update () 15: Control (DataHolder*) 14: Update () 1: Apply (DataHolder*) 2: Notify ( )

46. Case Study 2

47. Case Study 3