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

Slides:



Advertisements
Similar presentations
Week 2 The Object-Oriented Approach to Requirements
Advertisements

 Recent researches show that predicative programming can be used to specify OO concepts including classes, objects, interfaces, methods, single and multiple.
Figures – Chapter 7.
Chapter 7 – Object-Oriented Design
CSE3308/CSC Software Engineering: Analysis and DesignLecture 5B.1 Software Engineering: Analysis and Design - CSE3308 Patterns CSE3308/CSC3080/DMS/2000/12.
Systems Analysis and Design in a Changing World, Fourth Edition
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 5: Restaurant.
The Unified Software Development Process - Workflows Ivar Jacobson, Grady Booch, James Rumbaugh Addison Wesley, 1999.
Slide 1 Systems Analysis & Design CS183 Spring Semester 2008 Dr. Jonathan Y. Clark Course Website:
Slide 1 Chapter 7 Structural Modeling. Slide 2 Key Ideas A structural or conceptual model describes the structure of the data that supports the business.
Chapter 14 (Web): Object-Oriented Data Modeling
Software Engineering I Object-Oriented Design
Oct Ron McFadyen1 Collaborations Collaboration : an arrangement of classes, links, roles in a context to implement some behaviour. Useful for.
Chapter 14: Object-Oriented Data Modeling
Domain Modeling (with Objects). Motivation Programming classes teach – What an object is – How to create objects What is missing – Finding/determining.
Object-Oriented Analysis and Design
UML Diagrams: Sequence Diagrams The Requirements Model, and The Dynamic Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical.
Chapter 7: The Object-Oriented Approach to Requirements
Design Patterns.
Software Design Refinement Using Design Patterns Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
ITEC224 Database Programming
The Software Product Line Architectures
POAD Distributed System Case Study: A Medical Informatics System Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Introduction to the Unified Modeling Language “The act of drawing a diagram does not constitute analysis or design. … Still, having a well-defined and.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Software Design The Dynamic Model Design Sequence Diagrams and Communication Diagrams Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical.
UML Diagrams: Class Diagrams The Static Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
POAD Book: Chapter 9 POAD: The Design Phase Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Programming in Java Unit 3. Learning outcome:  LO2:Be able to design Java solutions  LO3:Be able to implement Java solutions Assessment criteria: 
UML Diagrams: Sequence Diagrams The Requirements Model, and The Dynamic Analysis Model Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 10 Use Case Design.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
Lab 04.
Slide 1 Structural Modeling Chapter 7. Slide 2 Key Ideas A structural or conceptual model describes the structure of the data that supports the business.
 A software application is like a city  Modeling = Architecture  OOP = Civil Engineering  UML Classes = Blueprints of Buildings  UML is a common.
Introduction to Pattern Oriented Analysis and Design (POAD) Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
POAD Book: Chapter 8 POAD: Analysis Phase Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
CHAPTER 13 (ONLINE): OBJECT-ORIENTED DATA MODELING © 2013 Pearson Education, Inc. Publishing as Prentice Hall 1 Modern Database Management 11 th Edition.
Object-Oriented Analysis and Design Fall 2009.
© 2009 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 15: Object-Oriented Data Modeling Modern Database Management 9 h Edition Jeffrey A.
© 2011 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 13 (Online): Object-Oriented Data Modeling Modern Database Management 10 th Edition.
Automating the Development of Pattern-Oriented Designs Copyright, 1996 © Dale Carnegie & Associates, Inc. Sherif Yacoub, Hengyi Xue, and Hany Ammar {yacoub,
The Static Analysis Model Class Diagrams Prof. Hany H. Ammar, CSEE, WVU, and Dept. of Computer Science, Faculty of Computers and Information, Cairo University.
CS 3610: Software Engineering – Fall 2009 Dr. Hisham Haddad – CSIS Dept. Class Project OO Design Document Here is what you need to do for your class project.
Structural Modeling Chapter 7. Key Ideas A structural or conceptual model describes the structure of the data that supports the business processes in.
1 Structural Modeling Chapter 7. 2 Key Ideas A structural or conceptual model describes the structure of the data that supports the business processes.
Object-Oriented Data Modeling
Relationships Relationships between objects and between classes.
Introduction to OOAD and the UML
DESIGN OF SOFTWARE ARCHITECTURE
Prof. Hany H. Ammar, CSEE, WVU, and
Chapter 8 Object Design Reuse and Patterns. More Patterns Abstract Factory: Provide manufacturer independence Builder: Hide a complex creation process.
UML Course Instructor: Rizwana Noor. Overview  Modeling  What is UML?  Why UML?  UML Diagrams  Use Case  Components  Relationships  Notations.
ITEC0724 Modern Related Technology on Mobile Devices Lecture Notes #2 1.
Software Engineering Lecture 10: System Engineering.
POAD Book: Chapter 7 POAD: The Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Responsibilities and Rewards: Reasoning about Design Patterns Neelam Soundarajan Computer Science & Engineering Ohio State University Joint work with Jason.
UML Fundamental Elements. Structural Elements Represent abstractions in our system. Elements that encapsulate the system's set of behaviors. Structural.
A UML-Based Pattern Specification Technique Presented by Chin-Yi Tsai IEEE TRANSACTION ON SOFTWARE ENGINEERING, VOL. 30, NO. 3, MARCH 2004 Robert B. France,
Software Design Refinement Using Design Patterns
Instructor: Dr. Hany H. Ammar
UML Diagrams: Class Diagrams The Static Analysis Model
POAD Book: Chapter 8 POAD: Analysis Phase
Unified Modeling Language
Observer Design Pattern
Design Patterns - A few examples
Observer Pattern 1.
Chapter 20 Object-Oriented Analysis and Design
Introduction to Pattern Oriented Analysis and Design (POAD)
Chapter 22 Object-Oriented Systems Analysis and Design and UML
Presentation transcript:

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

Outline n Review of POAD Process n This lecture focuses on the design refinement phase. n This phase has 3 main activities – Instantiating the pattern internals – Developing class diagrams, – Optimizing the design

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

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 n Purpose- to create an application-specific instances of the patterns used in the Design phase n 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 n 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 n Specialization cont’d – Renaming pattern internals involve. n Revealing the internal class diagram model for each pattern instance. n Renaming the internal classes of each insatnce according to the application design environment. n 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 > Notify Subject Attach() Detach() Notify() Observer Update() ErrorObserver observerState Update() FeedbackSubject subjectState getState() ErrorObserver > Subject Attach() Detach() Notify() Observer Update() ConcreteObserver observerState Update() ConcreteSubject subjectState getState() Before specialization After specialization

Instantiating Pattern Internals n 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. n When abstract class is pure, the implementation class that realizes the interface is defined

Instantiating Pattern Internals – Instantiation by subclassing n When the abstract class has default implementation, the designer defines an implementation and determines which methods to use and which methods to override. n Keeping History of Participants’ Names – The underlying models should keep track of the name changes. – History tracking enables traceability between models.

Instantiating Pattern Internals n 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 n Scope- We have shifted out focus from design of the overall application to the internals of each pattern

Instantiating Pattern Internals n Product- The application-specific Detailed Pattern-Level design Diagrams. n The following slides will show the patterns for the feedback control system instantiated

FeedforwardStrategy (from POAD1-Feedback) > ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() AbstractController AlgorithmInterface() Controller ContextInterface() Controller Instantiating the FeedforwardStrategy pattern

ErrorObserver (from POAD1-Feedback) > ErrorObserver observerState Update() FeedbackSu bject subjectState GetState() AbstractSubject Attach() Detach() Notify() AbstractObserver Update() nn Update Notify Instantiating the ErrorObserver pattern

UpdateNotify FeedbackObserver (from POAD1-Feedback) > Measurement Subject subjectState GetState() FeedbackObs erver observerState Update() AbstractObserver Update() AbstractSubject Attach() Detach() Notify() nn Instantiating the FeedbackObserver pattern

Blackboard (from POAD1-Feedback) > Blackboard setData() getData() DataHolder getData setData nn ErrorDataMeasuredDataFeedbackData Instantiating the Blackboard pattern

FeedbackStrategy (from POAD1-Feedback) > Feedback ContextInterface() FBAbstractController AlgorithmInterface() FBConcreteStrategy A AlgorithmInterface() FBConcreteStrategy B 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 n Purpose – To develop a class diagram of the application using the class diagrams of the pattern instances n 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 n Previously the application-specific pattern instances were developed. n 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 n Previously we determined the relationships between pattern internals n Now, we are tracing each interface to the internal pattern participant that implements it

Developing Initial Class diagram n The following diagram shows this step tracing each interface to the internal pattern participant that implements it Interface 2 PatternInstance1 > PatternInstance2 > Interface 1 ? ? ?

Developing Initial Class diagram n 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 n Consider FeedforwardStrategy and the ErrorObserver Pattern discussed previously, the following diagram shows there interfaces and the elements that implement them

FeedforwardStrategy > ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() AbstractController AlgorithmInterface() Controller ContextInterface() Context ErrorObserver > ErrorObserver observerState Update() FeedbackSubject subjectState GetState() Subject Attach() Detach() Notify() Observer Update() nn Notify

Developing Initial Class diagram – Tracing the Relationship between pattern instances n Using the relationship between interface and the traceability between interface and pattern internal the designer establishes relationship between internals of the 2 pattern instances. n Interfaces can be interface operations or methods; there are several relationships – Class/Class – Class/Operation – Operation/Operation n After All tracing and realization we get a class diagram

ConcreteStrategyA AlgorithmInterface() ConcreteStrategyB AlgorithmInterface() AbstractController AlgorithmInterface() Controller ContextInterface() ErrorObserver observerState Update() FeedbackSubject subjectState GetState() Subject Attach() Detach() Notify() Observer Update() nn

Developing Initial Class diagram n Product – The initial UML class diagram for the application design

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 n Purpose – To optimize the class diagram, and prepare it for implementation. n Process – We use Reduction, merging and grouping to optimize the class diagram. n 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. n Reduction is the process where the replicated abstract class is removed. n The two classes must be similar – In the case of interfaces the common interface class has to provide the same interface signature

ErrorObserver > Subject Attach() Detach() Notify() Observer Update() ErrorObserver observerState Update() FeedbackSubject subjectState getState() SensorObserver > 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 n The common classes must provide same interface, and default implementation. n 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 n identifying which classes to merge n defining how to merge the classes

FeedforwardStrategy > 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. n Relationships are between 2 pattern participants, these 2 participants are candidates for merging

Design Optimization – POAD uses Hard merge. n 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 context Class of the Strategy pattern

Design Optimization n Product - An optimized class diagram for the application, which is more dense and more profound

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