poad book: chapter 10 poad: the design refinement phase instructor: dr. hany h. ammar dept. of...

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



Specialization

Concretization



Design Optimization

Reduction

Merging & Grouping



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.


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


– 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


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


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


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


AbstractController


Controller

ContextInterface()

Controller

Instantiating the FeedforwardStrategy pattern

ErrorObserver


<<Observer>>

ErrorObserver

observerState

Update()

FeedbackSubject

subjectState

GetState()

AbstractSubject


AbstractObserver

Update() nn

Update Notify

Instantiating the ErrorObserver pattern

Update Notify

FeedbackObserver


<<Observer>>

MeasurementSubject

subjectState

GetState()

FeedbackObserver

observerState

Update()

AbstractObserver

Update()

AbstractSubject


nn

Instantiating the FeedbackObserver pattern

Blackboard


<<Blackboard>>

Blackboard

setData()getData()

DataHolder

getData

setData

nn

ErrorData MeasuredData FeedbackData

Instantiating the Blackboard pattern

FeedbackStrategy


<<Strategy>>

Feedback

ContextInterface()

FBAbstractController


FBConcreteStrategyA


FBConcreteStrategyB


Feedback

Instantiating the FeedbackStrategy pattern



Specialization

Concretization



Design Optimization

Reduction

Merging & Grouping




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.


– 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?

?

?


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


ConcreteStrategyB


AbstractController

AlgorithmInterface()Controller

ContextInterface()

Context

ErrorObserver<<Observer>>

ErrorObserverobserverState

Update()

FeedbackSubjectsubjectState

GetState()

SubjectAttach()Detach()Notify()

Observer

Update() nn

Update() Notify


– 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


ConcreteStrategyB


AbstractController

AlgorithmInterface()Controller

ContextInterface()


Update()

FeedbackSubject

subjectState

GetState()

Subject


Observer

Update() nn


Product – The initial UML class diagram for the application design

DataHolder


AbstractObserver

Update()

AbstractSubject


nn

AbstractController


ConcreteStrategyB


ConcreteStrategyA


FBAbstractController


FBConcreteStrategyB


FBConcreteStrategyA


Feedback

ContextInterface()

FeedbackSubjectsubjectState

GetState()


Update()

Controller

ContextInterface()

Blackboard

setData()getData() nn

AbstractObserver

Update()

AbstractSubject


MeasurementSubjectsubjectState

GetState()

nn

FeedbackObserverobserverState

Update()

Initial Class Diagram Feedback Control System



Specialization

Concretization



Design Optimization

Reduction

Merging & Grouping




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


ConcreteStrategyB


Context

ContextInterface()

Strategy


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


ConcreteStrategyB


AbstractController

AlgorithmInterface()ContextInterface()

ErrorObserverController

observerState

Update()

FeedbackSubject

subjectState

GetState()

Subject


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


AbstractObserver

Update()

AbstractSubject


ConcreteStrategyB


ConcreteStrategyA


FBConcreteStrategyB


FBConcreteStrategyA


ErrorObserver

observerState

Update()

Controller

ContextInterface()

Blackboard

setData()getData() n

nn

n

MeasurementSubjectsubjectState

GetState()

FeedbackSubjectObserver

AbstractController


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

poad book: chapter 10 poad: the design refinement phase instructor: dr. hany h. ammar dept. of...

Documents