POAD: The Process Instructor: Dr. Hany H. Ammar Dept. of Computer - - PowerPoint PPT Presentation

poad the process
SMART_READER_LITE
LIVE PREVIEW

POAD: The Process Instructor: Dr. Hany H. Ammar Dept. of Computer - - PowerPoint PPT Presentation

POAD Book: Chapter 7 POAD: The Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU Goals Pattern Integration: Present two different ways for gluing patterns To introduce the process aspects


slide-1
SLIDE 1

POAD Book:

Chapter 7

POAD: The Process

Instructor: Dr. Hany H. Ammar

  • Dept. of Computer Science and

Electrical Engineering, WVU

slide-2
SLIDE 2

Goals

 Pattern Integration: Present two different

ways for gluing patterns

 To introduce the process aspects of POAD  to outline the POAD approach and to

illustrate how patterns can be utilized as design building blocks

 We will later see how POAD evolve from

their integration

slide-3
SLIDE 3
  • utline
  • Pattern Integration: Stringing vs Overlapping
  • POAD Process Outline (Nutshell)
  • Analysis
  • Design
  • Design Refinement
slide-4
SLIDE 4

Pattern Integration: Stringing vs Overlapping

 Both techniques (stringing patterns, and

  • verlapping them together) were originally

used for Civil engineering purposes, but they do apply to building software systems.

 Stringing -patterns are glued together

– glue could be UML relationships – design is a loose assembly of patterns – You end up with too many classes with trivial

responsibilities

slide-5
SLIDE 5

Pattern Integration: Stringing vs Overlapping

 Overlapping

– A class as a participant in one pattern could be

at the same time a participant of another pattern in the same application design

– One class can play two different roles, in two

different patterns

 The Advantage of overlapping is that you

have fewer classes

 The disadvantage is that pattern boundary is

lost and patterns are hard to trace

slide-6
SLIDE 6

Example

 Consider the Reactor and Composite Patterns

Reactor Dispatch() EventHandler HandleEvent() CloseHandle() GetHandle() n ConcreteEventHandler1 ConcreteventHandler2

slide-7
SLIDE 7

Example

Leaf Operation() Composite Operation() AddComponent(Component) RemoveComponent(Component) Component Operation() AddComponent(Component) RemoveComponent(Component) n

slide-8
SLIDE 8

Example

 Now, you have two patterns to glue, the

Reactor and the Composite patterns

 Stringing the 2 patterns together gives us

the following

slide-9
SLIDE 9

Example: Stringing

Leaf Operation() Composite Operation() AddComponent(Component) RemoveComponent(Compon Component Operation() AddComponent(Component) RemoveComponent(Component) n Reactor Dispatch() EventHandler HandleEvent() CloseHandle() GetHandle() n ConcreteEventHandler1 Concretevent Handler2

slide-10
SLIDE 10

Example: Overlapping

Reactor Dispatch() EventHandlerComponent HandleEvent() CloseHandle() GetHandle() AddComponent(EventHandlerComponent) RemoveComponent(EventHandlerComponent) n LeafEventHandler HandleEvent() CloseHandle() GetHandle() CompositeEventHandler HandleEvent() CloseHandle() GetHandle() AddComponent(EventHandlerComponent) RemoveComponent(EventHandlerComponent) n

slide-11
SLIDE 11

What does POAD uses

 Although Stringing is the easier of the 2

approaches, it is often avoided

– It provides good traceability

 POAD uses both

– It uses the simplicity and traceability of the

stringing-patterns approach

– the density and profoundness of the

  • verlapping-patterns approach

 POAD integrates both methods in one

process

slide-12
SLIDE 12

Hierarchical Integration Techniques

 POAD starts by assembling patterns at a

higher level of abstraction using the stringing approach

 It then allows the designer to integrate the

lower level classes to produce dense and profound designs

slide-13
SLIDE 13
  • utline
  • Pattern Integration: Stringing vs Overlapping
  • POAD Process Outline (Nutshell)
  • Analysis
  • Design
  • Design Refinement
slide-14
SLIDE 14

POAD Process Outline (Nutshell)

 We will use the purpose/process/product

template to explain the various steps within a development phases

– Purpose - explains why a designer would

conduct this step

– Process - describes the activity that the designer

conducts in this step

– Product - describes expected output of this step

slide-15
SLIDE 15

Three phases of POAD

 analysis

– A set of patterns are selected from a domain

specific library

 high-level design phase where

– patterns are glued together using pattern

composition models to produce an initial class diagram

 design refinement phase

– initial class diagram is processed to produce a

more dense and profound class diagram

slide-16
SLIDE 16

POAD Process

 The following figure shows the symbols we

use for POAD Process description

Product A process uses a product A process uses another process Legend A process produces a product Process

slide-17
SLIDE 17

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

slide-18
SLIDE 18
  • utline
  • Pattern Integration: Stringing vs Overlapping
  • POAD Process Outline (Nutshell)
  • Analysis
  • Design
  • Design Refinement
slide-19
SLIDE 19

Analysis phase

 Purpose

– Analyze the application requirements and decide

what patterns that will be used

 Process

– UML use case diagrams and sequence diagrams are

used to identify required patterns

– Main concern is determining whether or not the

pattern can be used and why it is better

– analyst searches pattern catalogues for candidate

patterns

– Analyst must be acquainted with the catalogue

Acquaintan ce Pattern Library Candidate Patterns Selection Selected Patterns Application Requirements Requirem ent Analysis Required Conceptual Components Retrieval

slide-20
SLIDE 20

Analysis phase

– Retrieval how to select a pattern from a catalogue

 Product

– Patterns chosen by the application analyst – For example: Recall the

 Feedback control example.

Observer and Strategy pattern is selected for the feedforward component, And for the feedback component

Referenc e Input Measureme nt Feedbac k Data Error (Actuatin g) Signal Feed forward Elements Feedback Elements Plant. + + Controlled Output

Acquaintan ce Pattern Library Candidate Patterns Selection Selected Patterns Application Requirements Requirem ent Analysis Required Conceptual Components Retrieval

slide-21
SLIDE 21
  • utline
  • Pattern Integration: Stringing vs Overlapping
  • POAD Process Outline (Nutshell)
  • Analysis
  • Design
  • Design Refinement
slide-22
SLIDE 22

Design phase

 Purpose

– Develop the application design by composing the

patterns selected in the analysis phase

 Process

– Instantiating patterns, and identifying relationships

between instances

– Proceed from the Pattern-Level diagram to create a

Pattern-Level with Interface diagram

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

slide-23
SLIDE 23

Design phase

 Process (Cont.)

 From Pattern-Level with Interface diagram, the

designer identifies details of the pattern and Detailed Pattern-Level diagram is produced  Product

– The product of this phase is Detailed Pattern-

Level diagrams

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

slide-24
SLIDE 24

Example

FeedforwardStrategy <<Strategy>> InputObserver <<Observer>> Context Update Notify Subject Attach() Detach() Notify() Observer Update() ConcreteObserver

  • bserverState

Update() ConcreteSubject subjectState getState() n n ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() Context ContextInterface() Strategy AlgorithmInterface()

slide-25
SLIDE 25
  • utline
  • Pattern Integration: Stringing vs Overlapping
  • POAD Process Outline (Nutshell)
  • Analysis
  • Design
  • Design Refinement
slide-26
SLIDE 26

Design Refinement phase

 Purpose

– To develop the profound dense class diagram for

the application

 Process

– Starting with Detailed Pattern-Level diagram – Designer instantiates each pattern in the context of

the application

slide-27
SLIDE 27

Design Refinement phase

 Process (cont.)

– This produces our initial class diagram – class diagram is obtained from gluing patterns

together at the high level design

 Product

– Optimized class diagram for the application

slide-28
SLIDE 28

DataHolder ErrorData MeasuredData FeedbackData AbstractObserver Update() AbstractSubject Attach() Detach() Notify() ConcreteStrategyB AlgorithmInterface() ConcreteStrategyA AlgorithmInterface() FBConcreteStrategyB AlgorithmInterface() FBConcreteStrategyA AlgorithmInterface() ErrorObserver

  • bserverState

Update() Controller ContextInterface() Blackboard setData() getData() n n n MeasurementSubject subjectState GetState() FeedbackSubjectObserver AbstractController AlgorithmInterface()

Example