POAD Book: Chapter 10 POAD: The Design Refinement Phase

1
POAD Book Chapter 10POAD The Design
Refinement Phase

• Instructor Dr. Hany H. Ammar
• Dept. of Computer Science and Electrical
  Engineering, WVU

2
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

3
The POAD process a) overall phases, b) analysis,
c) design, and d) design refinement
(b) Analysis
(a) Overall POAD
Detailed Pattern-Level Diagrams
(d) Design Refinement
Concretization
Instantiating Pattern Internals
Specialization
Domain Specific Detailed Pattern-Level Diagrams
Develop Class Diagrams
Initial UML class diagram
Reduction
Design Optimization
Merging Grouping
Optimized class diagram
4
Detailed Pattern-Level Diagrams
Concretization
Instantiating Pattern Internals
Specialization
Domain Specific Detailed Pattern-Level Diagrams
The Design Refinement phase.
Develop Class Diagrams
Initial UML class diagram
Reduction
Design Optimization
Merging Grouping
Optimized class diagram
5
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.

6
Instantiating Pattern Internals

• Specialization (generic -gt application specific)
• The patterns 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

• Specialization contd
• 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

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
ltltObservergtgt
ltltObservergtgt
ErrorObserver
ErrorObserver
Subject
Subject
Observer
Observer
Attach()
Attach()
Detach()
Update()
Detach()
Update()
Notify()
Notify()
FeedbackSubject
ConcreteSubject
ErrorObserver
ConcreteObserver
Notify
subjectState
subjectState
observerState
observerState
getState()
getState()
Update()
Update()
After specialization
Before specialization
10
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

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

12
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

13
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

14
Instantiating the FeedforwardStrategy pattern
15
Instantiating the ErrorObserver pattern
16
Instantiating the FeedbackObserver pattern
17
Instantiating the Blackboard pattern
18
Instantiating the FeedbackStrategy pattern
19
Detailed Pattern-Level Diagrams
Concretization
Instantiating Pattern Internals
Specialization
Domain Specific Detailed Pattern-Level Diagrams
The Design Refinement phase.
Develop Class Diagrams
Initial UML class diagram
Reduction
Design Optimization
Merging Grouping
Optimized class diagram
20
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.

21
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

22
Developing Initial Class diagram

• The following diagram shows this step
• tracing each
• interface to
• the internal
• pattern participant
• that implements
• it

23
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

24
(No Transcript)
25
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

26
(No Transcript)
27
Developing Initial Class diagram

• Product The initial UML class diagram for the
  application design

28
Initial Class Diagram Feedback Control System
29
(No Transcript)
30
(No Transcript)
31
Detailed Pattern-Level Diagrams
Concretization
Instantiating Pattern Internals
Specialization
Domain Specific Detailed Pattern-Level Diagrams
The Design Refinement phase.
Develop Class Diagrams
Initial UML class diagram
Reduction
Design Optimization
Merging Grouping
Optimized class diagram
32
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

33
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

34
ltltObservergtgt
ltltObservergtgt
SensorObserver
ErrorObserver
Subject
Subject
Observer
Attach()
Observer
Attach()
Update()
Detach()
Detach()
Update()
Notify()
Notify()
SensorSubject
FeedbackSubject
FeedbackObserver
subjectState
ErrorObserver
subjectState
observerState
observerState
getState()
getState()
Update()
Update()
(b)
(a)
35
(No Transcript)
36
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.

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
• identifying which classes to merge
• defining how to merge the classes

38
(No Transcript)
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.
• Relationships are between 2 pattern participants,
  these 2 participants are candidates for merging

40
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

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
Subject
Observer
Attach()
Detach()
Update()
n
n
Notify()
FeedbackSubject
ErrorObserverController
AbstractController
observerState
subjectState
AlgorithmInterface()
ContextInterface()
Update()
GetState()
The ErrorObserver is merged with the
context Class of the Strategy pattern
ConcreteStrategyB
ConcreteStrategyA
AlgorithmInterface()
AlgorithmInterface()
43
Design Optimization

• 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
46
Case Study 2
47
Case Study 3