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

2. Outline n Review of the POAD Process n The design phase consists of the following – Constructing Pattern Level Diagrams – Constructing Pattern-Level with Interfaces – Constructing Detailed Pattern Level n Deliverables – High level view of the application – Pattern-Level with Interfaces Diagram – Detailed Pattern Level Diagram

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. Overall Design Phase Pattern-Level Diagrams Constructing Pattern-Level models Create Pattern Instances Define Instance Relationships Construct Pattern-Level Diagrams Constructing the Pattern-Level with Interfaces models Pattern-Level with Interfaces Diagrams Declare Pattern Interfaces Identify Interface Relationships Constructing the Detailed Pattern- Level models Detailed Pattern-Level Diagrams The Selected Patterns & Analysis Documentation

5. Constructing Pattern Level Models n Purpose – To create Pattern Level Models for the application. n Process – Creating Pattern Instances n Designer creates Instance for each pattern selected n Two steps to Instantiation – Identify Name and type of Pattern – Giving application Specific names to Pattern Internals (deferred to the design refinement phase) n Consider a sensor controlled by an application (from feedback example)

6. Constructing Pattern Level Models Reference Input Measurement Feedback Data Error (Actuating) Signal Feed forward Elements Feedback Elements Plant. + + Controlled Output

7. Constructing Pattern Level Models n For this application the analyst uses observer pattern n The application Specific name can be FeedbackObserver. n application design contains pattern instance called FeedbackObserver of type Observer – Multiple Instances of Same type n instance name distinguishes which pattern is referred n In the feedback example another observer is used to monitor the error between inputs and feedback data n i.e. ErrorObserver

8. Constructing Pattern Level Models – Defining Pattern Instance Relationships n In POAD pattern relationships are dependencies n Designer Studies existence of relationships and direction. n E.g the designer has decided to use ForwardStrategy to control the mechanisms of the plant. n Output from ErrorObserver triggers the ForwardStrategy instance n Hence designer creates dependency relationship from the ErrorObserver to the ForwardStrategy

9. Constructing Pattern Level Models – Develop Pattern Level Diagrams n UML models used to represent Pattern-Level diagrams n FeedforwardStrategy > Feedback Observer > ErrorObserver > Apply forward control strategy

10. Constructing Pattern Level Models – Subsystems and Frameworks n For large applications it is wise to divide the application into a set of subsystems n designer will construct a Pattern-Level diagram for each individual subsystem n Product - Pattern-Level diagrams for the application and for each individual subsystem or framework.

11. Design Tips n The designer should use the analysis results including the definition of design components and how the selected patterns are anticipated n Study the dynamics: Attempting to study the application dynamics will help the analyst identify the dependency relationships between pattern instances n Meaningful names: When choosing application specific names for the pattern instance, the designer should choose names that are meaningful in the application context. When there are n Revisit the analysis phase: the designer might find that the patterns selected by the analyst are not suitable

12. FeedforwardStrategy > FeedbackObserver > FeedbackStrategy > ErrorObserver > Blackboard > Apply forward control strategy Manipluate Data Plant Apply feedback control strategy Manipulate Data Calculate Error Manipluate Data Pattern Level Diagram: Feedback control system Examples

13. Example 2: The Simulation of Waiting Queues (POAD: Ch. 12) n Conceptual Components – Customer generator.The customer generator component uses one of a distribution function to generate the time of arrival – Queue facility.The queue facility component consists of a set of queue categories, where each queue category contains one or more queues – Service facility. The service facility component consists of a set of service categories, where each service category contains one or more servers. – Event manager.The event manager component serves as the main driver for the simulation and produces simulation measurements (results).

14. The Simulation of Waiting Queues (POAD: Ch. 12) Pattern Selection (cont.) – Customer Generator component use a distribution function to generate the next customer to arrive Select the TemplateMethod pattern as an interface for generating customers (TemplateMethod pattern defines the skeleton of an algorithm (in our case study the steps required to generate a customer) – The Event Manager (Scheduler) component plays the role of demultiplexing and dispatching of events select the Reactor pattern to implement the design of the Event Manager (supports the “de-multiplexing and dispatching of events to multiple event handlers triggered concurrently by multiple events, – The Queuing and Service facilities components Select the Composite Pattern to support composite queues/servers

15. The Simulation of Waiting Queues (POAD: Ch. 12)

16. Example 3: A Digital Content Remastering Application (POAD Ch.13)

17. A Digital Content Remastering (DCRM) Application (POAD Ch.13) Requirements: DCRM consists of several subsystems – The Distribution subsystem, a subsystem that deals with the distribution of tasks across the worker machines – The Filtering Subsystem, a subsystem that handles the application of several content- understanding algorithms – The controller engine subsystem that handles the workflow logic and masters the execution of components in the system.

18. A Digital Content Remastering (DCRM) Application (POAD Ch.13) The Distribution subsystem Requirements – Provide the necessary communication mechanisms to communicate with all worker machines – Be extensible to support several communication technologies, and be able to communicate with heterogeneous worker machines – Provide a mechanism for distributing tasks to worker machines, and be extensible in terms of the number of machines it supports,

19. A Digital Content Remastering (DCRM) Application (POAD Ch.13) n Conceptual Components – Task Distribution Component – Communication Component Acquaintance, Retrieval, Pattern Selection – the literature is full of patterns for distributed and communication systems – Some candidates include the Proxy pattern and the Strategy pattern, and the Abstract Factory pattern

20. A Digital Content Remastering (DCRM) Application (POAD Ch.13)

21. Overall Design Phase Pattern-Level Diagrams Constructing Pattern-Level models Create Pattern Instances Define Instance Relationships Construct Pattern-Level Diagrams Constructing the Pattern-Level with Interfaces models Pattern-Level with Interfaces Diagrams Declare Pattern Interfaces Identify Interface Relationships Constructing the Detailed Pattern- Level models Detailed Pattern-Level Diagrams The Selected Patterns & Analysis Documentation

22. Constructing Pattern Level with Interfaces n Purpose - analyze the relationships between instances and define relationships between interfaces n Process – Exposing the Instance Interfaces n Recall Interfaces can be interface operations or interface classes. n During this phase the designer determines the interfaces used to hook the patterns n Interface definition is buried deep in pattern documentation and is not explicitly defined

23. Constructing Pattern Level with Interfaces n Patterns can have Multiple Interfaces – Identifying the relationship between Pattern Instance Interface n Designer decides which interface to use, and constructs the relationship between pattern interfaces and instances. n The UML relationship “realizes” indicates a pattern implements a specific interface.

24. Constructing Pattern Level with Interfaces n Revisit Slide 7 where the ErrorObserver uses the ForwardStrategy Instance. – Observer has 2 interface operations, update() and notify() FeedforwardStrategy > ErrorObserver > Context Update Notify

25. Constructing Pattern Level with Interfaces – ForwardStrategy instance has interface class context() – as the input values change the control strategy should be applied to control the plant. – Thus the update() operation invokes the context interface – Update interface will be connected to the Context interface using a dependency relationship

26. Constructing Pattern Level with Interfaces n Interface Relationships – We could have 2 types of interfaces, class or operation – Thus we have 4 possible dependencies between patterns n Class-class, class-operation, operation-class, operation-operation. n These dependencies will be further investigated in the next step of the design phase when constructing a detailed pattern-level model

27. Constructing Pattern Level with Interfaces n Product- Constructing the pattern level with interfaces model.

28. FeedforwardStrategy (from POAD1-Feedback) > FeedbackObserver > (from POAD1-Feedback) FeedbackStrategy > (from POAD1-Feedback) ErrorObserver > (from POAD1-Feedback) Blackboard > (from POAD1- Feedback) Context Update Notify Context Update Notify setData getData Pattern Level with interfaces diagram for feedback control system

31. Overall Design Phase Pattern-Level Diagrams Constructing Pattern-Level models Create Pattern Instances Define Instance Relationships Construct Pattern-Level Diagrams Constructing the Pattern-Level with Interfaces models Pattern-Level with Interfaces Diagrams Declare Pattern Interfaces Identify Interface Relationships Constructing the Detailed Pattern-Level models Detailed Pattern-Level Diagrams The Selected Patterns & Analysis Documentation

32. Constructing Detailed Pattern-Level Models n Purpose- To reveal the internal design structure of the pattern instances used in the Pattern-Level with Interface diagrams. n Process- Explore the pattern structure – POAD is structure based composition approach. – Class diagram for each pattern is expected to be a part of a pattern database. – Designer studies study internal class diagram of patterns used in Pattern-Level with Interfaces diagram

33. Constructing Detailed Pattern-Level Models – The following figure shows the Detailed Pattern Level diagram for the previously discussed example. It shows the internals of each pattern – The designer studies participants in the class diagram and the roles they play in solving the design problem

34. FeedforwardStrategy > InputObserver > Context Update Notify Subject Attach() Detach() Notify() Observer Update() ConcreteObserver observerState Update() ConcreteSubject subjectState getState() nn ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() Context ContextInterface() Strategy AlgorithmInterface()

35. Constructing Detailed Pattern-Level Models n Dynamic Aspects- explain how pattern participants communicate with each other. n Realization of the Interface- identify which elements of the pattern internals are exposed as interfaces. – Trace interfaces to pattern internals n Product- Detailed Pattern Level Diagram

36. FeedforwardStrategy (from POAD1-Feedback) > FeedbackObserver (from POAD1-Feedback) > FeedbackStrategy (from POAD1-Feedback) > ErrorObserver (from POAD1-Feedback) > Blackboard (from POAD1-Feedback) > Context UpdateNotify Context Update Notify setData getData ConcreteOb server observerState Update() ConcreteS ubject subjectState getState() Subject Attach() Detach() Notify() Observer Update() nn Subject Attach() Detach() Notify() Observer Update() ConcreteObserver observerState Update() ConcreteSubject subjectState getState() nn ConcreteStrate gyA AlgorithmInterface() ConcreteStrate gyB AlgorithmInterface() Context ContextInterface() Strategy AlgorithmInterface() Context ContextInterface() Strategy AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() ConcreteStrategyA AlgorithmInterface() ConcreteDataHolderAConcreteDataHolderB Blackboard setData() getData() DataHolder nn Detailed pattern Level Diagram Feedback control system