poad book: chapter 10 poad: the design refinement phase
DESCRIPTION
POAD Book: Chapter 10 POAD: The Design Refinement Phase. Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU. Outline. Review of POAD Process This lecture focuses on the design refinement phase. This phase has 3 main activities - PowerPoint PPT PresentationTRANSCRIPT
POAD Book: Chapter 10
POAD: The Design Refinement Phase
Instructor: Dr. Hany H. Ammar
Dept. of Computer Science and Electrical Engineering, WVU
Outline
Review of POAD Process This lecture focuses on the design
refinement phase. This phase has 3 main activities
– Instantiating the pattern internals– Developing class diagrams, – Optimizing the design
Acquaintance Pattern
Library
Candidate Patterns
Selection
Selected Patterns
Application Requirements
Requirement
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
Specialization
Concretization
Develop Class Diagrams
Initial UML class diagram
Design Optimization
Reduction
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
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.
Instantiating Pattern Internals Purpose- to create an application-specific
instances of the patterns used in the Design phase 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.
Instantiating Pattern Internals
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
Instantiating Pattern Internals Specialization cont’d
– Renaming pattern internals involve. Revealing the internal class diagram model for each pattern
instance. Renaming the internal classes of each insatnce according to
the application design environment. 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
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
ErrorObserver
<<Observer>>
Notify
Subject
Attach()Detach()Notify()
ObserverUpdate()
ErrorObserver
observerState
Update()
FeedbackSubject
subjectState
getState()
ErrorObserver
<<Observer>>
Subject
Attach()Detach()
Notify()
Observer
Update()
ConcreteObserver
observerState
Update()
ConcreteSubject
subjectState
getState()
Before specialization After specialization
Instantiating Pattern Internals 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. When abstract class is pure, the implementation class that
realizes the interface is defined
Instantiating Pattern Internals
– Instantiation by subclassing When the abstract class has default implementation,
the designer defines an implementation and determines which methods to use and which methods to override.
Keeping History of Participants’ Names – The underlying models should keep track of the
name changes.– History tracking enables traceability between
models.
Instantiating Pattern Internals
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
Scope- We have shifted out focus from design of the overall application to the internals of each pattern
Instantiating Pattern Internals
Product- The application-specific Detailed Pattern-Level design Diagrams.
The following slides will show the patterns for the feedback control system instantiated
FeedforwardStrategy
(from POAD1-Feedback)
<<Strategy>>
ConcreteStrategyA
AlgorithmInterface()
ConcreteStrategyB
AlgorithmInterface()
AbstractController
AlgorithmInterface()
Controller
ContextInterface()
Controller
Instantiating the FeedforwardStrategy pattern
ErrorObserver
(from POAD1-Feedback)
<<Observer>>
ErrorObserver
observerState
Update()
FeedbackSubject
subjectState
GetState()
AbstractSubject
Attach()Detach()Notify()
AbstractObserver
Update() nn
Update Notify
Instantiating the ErrorObserver pattern
Update Notify
FeedbackObserver
(from POAD1-Feedback)
<<Observer>>
MeasurementSubject
subjectState
GetState()
FeedbackObserver
observerState
Update()
AbstractObserver
Update()
AbstractSubject
Attach()Detach()Notify()
nn
Instantiating the FeedbackObserver pattern
Blackboard
(from POAD1-Feedback)
<<Blackboard>>
Blackboard
setData()getData()
DataHolder
getData
setData
nn
ErrorData MeasuredData FeedbackData
Instantiating the Blackboard pattern
FeedbackStrategy
(from POAD1-Feedback)
<<Strategy>>
Feedback
ContextInterface()
FBAbstractController
AlgorithmInterface()
FBConcreteStrategyA
AlgorithmInterface()
FBConcreteStrategyB
AlgorithmInterface()
Feedback
Instantiating the FeedbackStrategy pattern
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.
Developing Initial Class diagram
Purpose – To develop a class diagram of the application using the class diagrams of the pattern instances
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.
Developing Initial Class diagram
– Revealing the Instantiated Pattern Internals Previously the application-specific pattern instances were
developed. 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 Previously we determined the relationships between pattern
internals Now, we are tracing each interface to the internal pattern
participant that implements it
Developing Initial Class diagram The following diagram shows this step
tracing each
interface to
the internal
pattern participant
that implements
it
Interface 2
PatternInstance1
<<Type>>
PatternInstance2
<<Type>>
Interface 1?
?
?
Developing Initial Class diagram
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
Consider FeedforwardStrategy and the ErrorObserver Pattern discussed previously, the following diagram shows there interfaces and the elements that implement them
FeedforwardStrategy<<Strategy>>
ConcreteStrategyA
AlgorithmInterface()
ConcreteStrategyB
AlgorithmInterface()
AbstractController
AlgorithmInterface()Controller
ContextInterface()
Context
ErrorObserver<<Observer>>
ErrorObserverobserverState
Update()
FeedbackSubjectsubjectState
GetState()
SubjectAttach()Detach()Notify()
Observer
Update() nn
Update() Notify
Developing Initial Class diagram
– Tracing the Relationship between pattern instances Using the relationship between interface and the
traceability between interface and pattern internal the designer establishes relationship between internals of the 2 pattern instances.
Interfaces can be interface operations or methods; there are several relationships
– Class/Class– Class/Operation– Operation/Operation
After All tracing and realization we get a class diagram
ConcreteStrategyA
AlgorithmInterface()
ConcreteStrategyB
AlgorithmInterface()
AbstractController
AlgorithmInterface()Controller
ContextInterface()
ErrorObserverobserverState
Update()
FeedbackSubject
subjectState
GetState()
Subject
Attach()Detach()Notify()
Observer
Update() nn
Developing Initial Class diagram
Product – The initial UML class diagram for the application design
DataHolder
ErrorData MeasuredData FeedbackData
AbstractObserver
Update()
AbstractSubject
Attach()Detach()Notify()
nn
AbstractController
AlgorithmInterface()
ConcreteStrategyB
AlgorithmInterface()
ConcreteStrategyA
AlgorithmInterface()
FBAbstractController
AlgorithmInterface()
FBConcreteStrategyB
AlgorithmInterface()
FBConcreteStrategyA
AlgorithmInterface()
Feedback
ContextInterface()
FeedbackSubjectsubjectState
GetState()
ErrorObserverobserverState
Update()
Controller
ContextInterface()
Blackboard
setData()getData() nn
AbstractObserver
Update()
AbstractSubject
Attach()Detach()Notify()
MeasurementSubjectsubjectState
GetState()
nn
FeedbackObserverobserverState
Update()
Initial Class Diagram Feedback Control System
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.
Design Optimization
Purpose – To optimize the class diagram, and prepare it for implementation.
Process – We use Reduction, merging and grouping to optimize the class diagram.
Reduction – Consider a scenario where we have multiple instances of the same type– Multiple instances indicate multiple abstract
class
Design Optimization
– The abstract class is seldom implemented, it is as source for subclassing and realization.
Reduction is the process where the replicated abstract class is removed.
The two classes must be similar– In the case of interfaces the common interface
class has to provide the same interface signature
ErrorObserver
<<Observer>>
Subject
Attach()Detach()
Notify()
Observer
Update()
ErrorObserver
observerState
Update()
FeedbackSubject
subjectState
getState()
SensorObserver
<<Observer>>
Subject
Attach()Detach()
Notify()
Observer
Update()
FeedbackObserver
observerState
Update()
SensorSubject
subjectState
getState()
(a) (b)
Subject
Attach()Detach()
Notify()
Observer
Update()
FeedbackObserver
observerState
Update()
SensorSubject
subjectState
getState()
ErrorObserver
observerState
Update()
FeedbackSubject
subjectState
getState()(c)
Design Optimization
– In the case of the abstract class The common classes must provide same interface, and
default implementation.
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.
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 identifying which classes to merge defining how to merge the classes
FeedforwardStrategy
<<Strategy>>
Context
ConcreteStrategyA
AlgorithmInterface()
ConcreteStrategyB
AlgorithmInterface()
Context
ContextInterface()
Strategy
AlgorithmInterface()
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.
Relationships are between 2 pattern participants, these 2 participants are candidates for merging
Design Optimization
– POAD uses Hard merge. 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
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
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 contextClass of the Strategy pattern
Design Optimization
Product - An optimized class diagram for the application, which is more dense and more profound
DataHolder
ErrorData MeasuredData FeedbackData
AbstractObserver
Update()
AbstractSubject
Attach()Detach()Notify()
ConcreteStrategyB
AlgorithmInterface()
ConcreteStrategyA
AlgorithmInterface()
FBConcreteStrategyB
AlgorithmInterface()
FBConcreteStrategyA
AlgorithmInterface()
ErrorObserver
observerState
Update()
Controller
ContextInterface()
Blackboard
setData()getData() n
nn
n
MeasurementSubjectsubjectState
GetState()
FeedbackSubjectObserver
AbstractController
AlgorithmInterface()
Refined Class Diagram for feedback control system (case study 1)
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 ( )
Case Study 2
Case Study 3