CSSE 374: Even More Object Design with Gang of Four Design Patterns

Similar documents
More Object Design with GoF Patterns (continued) CSSE 574: Session 7, Part 3

2009 Shawn A. Bohner. Shawn Bohner Office: Moench Room F212 Phone: (812)

Object Design with GoF Patterns, continued. Curt Clifton Rose-Hulman Institute of Technology

CSSE 374: More Object Design with Gang of Four Design Patterns

2009 Shawn A. Bohner. Shawn Bohner Office: Moench Room F212 Phone: (812)

Persistence Frameworks with GoF Patterns (State & Command) CSSE 574: Session 7, Part 4

CSSE 374: GRASP ing at the First Five Patterns Principles. Shawn Bohner Office: Moench Room F212 Phone: (812)

CSSE 374: UML Activity Diagrams. Shawn Bohner Office: Moench Room F212 Phone: (812)

CSSE 374: Logical Architecture. Shawn Bohner Office: Moench Room F212 Phone: (812)

Applying Some Gang of Four Design Patterns CSSE 574: Session 5, Part 3

2009 Shawn A. Bohner. Shawn Bohner Office: Moench Room F212 Phone: (812)

CSSE 490 Model-Based Software Engineering: Software Factories

Model-Driven Architecture/ Development

GRASP ing at the First 5 Patterns Principles CSSE 574: Session 3, Part 4

CSSE 490 Model-Based Software Engineering: Cougaar Model-Driven Architecture Example

OODP Session 4. Web Page: Visiting Hours: Tuesday 17:00 to 19:00

From Design Patterns: Elements of Reusable Object Oriented Software. Read the sections corresponding to patterns covered in the following slides.

OODP Session 5a. Web Page: Visiting Hours: Tuesday 17:00 to 19:00

Domain Modeling. CSSE 574: Week 1, Part 3. Steve Chenoweth Phone: Office (812) Cell (937)

We are at System Operation Contracts

CREATE YOUR CONTENT STRATEGY & LAUNCH PLAN Amanda Genther Inc. & Irresistible Offerings

More Object Design with GoF Patterns CSSE 574: Session 7, Part 2

CSSE 490 Model-Based Software Engineering: Domain Specific Language Introduction

Software Design and Analysis CSCI 2040

CSSE 490 Model-Based Software Engineering: Transformational Programming

An Introduction to Patterns

CSSE 490 Model-Based Software Engineering: Introduction to Domain Engineering

Think of drawing/diagramming editors. ECE450 Software Engineering II. The problem. The Composite pattern

The Strategy Pattern Design Principle: Design Principle: Design Principle:

CSSE 490 Model-Based Software Engineering: MDSD and Case Study

CSSE 490 Model-Based Software Engineering: Domain Engineering

CSSE 374: Design Class Diagrams. Shawn Bohner Office: Moench Room F212 Phone: (812)

CSCI 253. Overview. The Elements of a Design Pattern. George Blankenship 1. Object Oriented Design: Template Method Pattern. George Blankenship

CSSE 490 Model-Based Software Engineering: More MBSD. Shawn Bohner Office: Moench Room F212 Phone: (812)

The Design Patterns Matrix From Analysis to Implementation

An Introduction to Patterns

Lecture 16: Factories and Frameworks. Copyright W.E. Howden 1

Software Design COSC 4353/6353 D R. R A J S I N G H

Overview of Patterns: Introduction

Responsibilities. Using several specific design principles to guide OO design decisions.

Object Oriented Programming and Design in Java. Session 21 Instructor: Bert Huang

References: Applying UML and patterns Craig Larman

Goal: build an object-oriented model of the realworld system (or imaginary world) Slicing the soup: OOA vs. OOD

Designing a Persistence Framework

CSSE 490 Model-Based Software Engineering: Introduction to MetaModels

CSE 70 Final Exam Fall 2009

MSO Lecture 12. Wouter Swierstra (adapted by HP) October 26, 2017

THOMAS LATOZA SWE 621 FALL 2018 DESIGN PATTERNS

COMP 6471 Software Design Methodologies

1 Software Architecture

CTIS 359 Principles of Software Engineering SOFTWARE DESIGN OO(A)D

What is Design Patterns?

Application Architectures, Design Patterns

Applying Some More Gang of Four Design Patterns CSSE 574: Session 5, Part 4

CS342: Software Design. November 21, 2017

Principles of Software Construction: Objects, Design, and Concurrency. Assigning Responsibilities to Objects. toad. Jonathan Aldrich Charlie Garrod

Design Patterns גרא וייס המחלקה למדעי המחשב אוניברסיטת בן-גוריון

DESIGN PATTERN - INTERVIEW QUESTIONS

CPSC 310 Software Engineering. Lecture 11. Design Patterns

CSSE 490 Model-Based Software Engineering: Architecture Description Languages (ADL)

Tuesday, October 4. Announcements

CSSE 490 Model-Based Software Engineering: Transformation Systems

be used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate

The GoF Design Patterns Reference

A few important patterns and their connections

Plan. A few important patterns and their connections. Singleton. Singleton: class diagram. Singleton Factory method Facade

SDC Design patterns GoF

17. GRASP: Designing Objects with Responsibilities

Review Software Engineering October, 7, Adrian Iftene

Design to interfaces. Favor composition over inheritance Find what varies and encapsulate it

Design Patterns #3. Reid Holmes. Material and some slide content from: - GoF Design Patterns Book - Head First Design Patterns

Logical Architecture & Design Preliminaries

Software Design Patterns. Background 1. Background 2. Jonathan I. Maletic, Ph.D.

LinkedList Implementation Mini-project intro

Lecture 21: Design Patterns III

Java Programming Lecture 7

CMPE/SE 135 Object-Oriented Analysis and Design

administrivia today UML start design patterns Tuesday, September 28, 2010

INTERNAL ASSESSMENT TEST III Answer Schema

CHAPTER 6: CREATIONAL DESIGN PATTERNS

Idioms and Design Patterns. Martin Skogevall IDE, Mälardalen University

OODP OOAD Session 7a

Design Pattern and Software Architecture: IV. Design Pattern

Object Analysis & Design in the textbook. Introduction to GRASP: Assigning Responsibilities to Objects. Responsibility-Driven Design

01/09: Project Plan. The Capstone Experience. Dr. Wayne Dyksen Department of Computer Science and Engineering Michigan State University Spring 2013

EINDHOVEN UNIVERSITY OF TECHNOLOGY

Design patterns. OOD Lecture 6

Introduction to Software Engineering: Object Design I Reuse & Patterns

VEL TECH HIGH TECH Dr. RANGARAJAN Dr. SAKUNTHALA ENGINEERING COLLEGE UNIT 1 UML DIAGRAMS

Spring 2003 Instructor: Dr. Shahadat Hossain. Administrative Matters Course Information Introduction to Programming Techniques

Material and some slide content from: - GoF Design Patterns Book. Design Patterns #1. Reid Holmes. Lecture 11 - Tuesday October

Final Exam Review (extended)

2014 NEW ZEALAND DIPLOMA IN ENGINEERING (ELECTRICAL ENGINEERING) MN4528

Building custom components IAT351

What is Design Patterns?

Introduction - SENG 330. Object-Oriented Analysis and Design

CS 520/620 Advanced Software Engineering Spring February 11, 2016

User Guide. User Guide Page 1

Chapter 15 UML Interaction Diagrams. Larman, C. Applying UML and Patterns. 3rd Ed. Ed. Prentice-Hall: 2005.

On to Iteration 3, and Activity Diagrams CSSE 574: Session 6, Part 1

Transcription:

CSSE 374: Even More Object Design with Gang of Four Design Patterns Shawn Bohner Office: Moench Room F212 Phone: (812) 877-8685 Email: bohner@rose-hulman.edu

Problem Solved Some engineer out there has solved P=NP and it's locked up in an electric eggbeater calibration routine. For every 0x5f375a86 we learn about, there are thousands we never see.

Learning Outcomes: Patterns, Tradeoffs Identify criteria for the design of a software system and select patterns, create frameworks, and partition software to satisfy the inherent trade-offs. Using GoF Patterns in Iteration 3 Support for third-party POS devices Handling payments Design Studio with Team 2.5 Q3

Supporting 3 rd Party Devices: How would you handle external, 3 rd party devices that have largely the same function, but they might operate differently and have different interfaces? Think for 15 seconds Turn to a neighbor and discuss it for a minute

Accessing External Physical Devices POS devices include cash drawer, coin dispenser, digital signature pad, & card reader They must work with devices from a variety of vendors like IBM, NCR, Fijitsu UnifiedPOS: an industry standard OO interface JavaPOS provides a Java mapping as a set of Java interfaces

Standard JavaPOS Interfaces for Hardware Device Control JavaPOS «interface» jpos.cashdrawer isdraweropened() opendrawer() waitfordrawerclose( timeout )... «interface» jpos.coindispenser dispensechange(amount) getdispenserstatus()......

Manufacturers Provide Implementations Device driver for hardware The Java class for implementing JavaPOS interface

What does this mean for NextGen POS? What types does NextGen POS use to communicate with external devices? How does NextGen POS get the appropriate instances? Assume: A given store uses a single manufacturer

Closer look at Abstract Factory Problem: How can we create families of related classes while preserving the variation point of switching between families? Solution: Define an abstract factory interface. Define a concrete factory for each family. Q1,2

Abstract Factory Example this is the Abstract Factory--an interface for creating a family of related objects Concrete Factories IBMJavaPOSDevicesFactory «interface» IJavaPOSDevicesFactory getnewcashdrawer() : jpos.cashdrawer getnewcoindispenser() : jpos.coindispenser... Abstract Factory NCRJavaPOSDevicesFactory... getnewcashdrawer() : jpos.cashdrawer getnewcoindispenser() : jpos.coindispenser...... getnewcashdrawer() : jpos.cashdrawer getnewcoindispenser() : jpos.coindispenser... { return new com.ibm.pos.jpos.cashdrawer() } { return new com.ncr.posdevices.cashdrawer() } Methods create vendor-specific instances, but use standard interface types.

1 st Attempt at Using Abstract Factory class Register { public Register() { IJavaPOSDevicesFactory factory = } } Constructs a vendorspecific concrete factory new IBMJavaPOSDevicesFactory(); this.cashdrawer = factory.getnewcashdrawer(); Uses it to construct device instances What if we want to change vendors?

Use an Abstract Class Abstract Factory // A factory method that returns a factory public static synchronized! IJavaDevicesFactory getinstance() { if (instance == null) { String factorycn =! System.getProperty( jposfactory.classname ); Class c = Class.forName( factorycn ); instance = (IJavaDevicesFactory) c.newinstance(); } return instance; }

Using a Factory Factory class Register { public Register() { IJavaPOSDevicesFactory factory = } } Gets a vendor-specific concrete factory singleton JavaPOSDevicesFactory.getInstance(); this.cashdrawer = factory.getnewcashdrawer(); Uses it to construct device instances Q3

Politics in the Software Organization

Handling Payments What do we do with different payment types? Cash, Credit, a Check? Need authorization for credit and check Follow the Do It Myself Guideline: As a software object, I do those things that are normally done to the actual object I represent. A common way to apply Polymorphism and Information Expert

Do It Myself Example Payment amount authorize() CashPayment CreditPayment DebitPayment CheckPayment authorize() authorize() authorize() authorize() Real world: payments are authorized OO world: payments authorize themselves Q4

Creating a CheckPayment makecheckpayment(driverslicensenum ) by Creator :Register 1: makecheckpayment(driverslicensenum ) :Sale 1.1: create(driverslicensenum,total) by Do It Myself and Polymorphism 1.2: authorize Finegrained objects :DriversLicense :Check 1.1.1: create (driverslicensenum ) 1.1.2: create(total) :CheckPayment by Creator

Frameworks with Patterns Framework: an extendable set of objects for related functions, e.g.: GUI framework Java collections framework Provides cohesive set of interfaces & classes Capture the unvarying parts Provide extension points to handle variation Relies on the Hollywood Principle: Don t call us, we ll call you.

Designing a Persistence Framework Domain Layer Persistence Framework Relational Database PersistenceFaçade :University name = Butler city = Indianapolis University object get(oid, class):object put(oid, object) Store object in RDB put(oid, Retrieve Butler from U.) RDB get(oid, University) Name City RHIT Terre Haute Purdue W. Lafayette Indiana U. Bloomington Butler U. Indianapolis University Table

The Façade Pattern for Object ID Need to relate objects to database records and ensure that repeated materialization of a record does not result in duplicate objects Object Identifier Pattern assigns an object identifier (OID) to each record Assigns an OID to each object (or its proxy) OID is unique to each object

Maps between Persistent Object & Database University Table :University name = Butler city = Indianapolis oid = xyz123 1 OID name city XI001 RHIT Terre Haute wxx246 Purdue W. Lafayette xxz357 Indiana U. Bloomington xyz123 Butler U. Indianapolis The OID may be contained in proxy object instead

Façade Design Pattern with Brokers PersistenceFacade getinstance( ): PersistenceFacade get(oid, class) : Object put(oid, Object) class 1 <<interface>> DBMapper get(oid):object put(oid, Object ProductSpecification RDBMapper ProductSpecification FlatFileMapper Manufacturer RDBMapper get(oid):object put(oid, Object) get(oid):object put(oid, Object get(oid):object put(oid, Object Each mapper gets and puts objects in its own unique way, depending on the kind of data store and format.

Template Method Pattern Problem: How can we record the basic outline of an algorithm in a framework (or other) class, while allowing extensions to vary the specific behavior? Solution: Create a template method for the algorithm that calls (often abstract) helper methods for the steps. Subclasses can override/implement these helper methods to vary the behavior. Q5,6

Example: Template Method used for Swing GUI Framework //unvarying part of algorithm public void update { clearbackground( ); //call the hook method paint( ); } GUIComponent update( ) paint( ) MyButton framework class Template Method Hook Method Programmer s Class paint( ) Hook method overridden to supply class specific detail

Design Studio Calendar Monday Tuesday Thursday 8th week Team 2.4 Team 2.1 9th week Team 2.2 Team 2.3 10th week Team 2.4 Team 2.1 Today Team 2.5 Course Wrap-up

Homework and Milestone Reminders Read Chapter 38 Milestone 5 Final Junior Project System and Design Preliminary Design Walkthrough on Friday, February 11th, 2011 during weekly project meeting Final due by 11:59pm on Friday, February 18 th, 2011 Team 2.4 Design Studio on Monday