OO Design2. Design Artifacts

Similar documents
Mapping Designs to Code

Designing for Visibility & Mapping to Code CSSE 574: Session 4, Part 3

Domain Modeling- 2. Generalization

COMP 6471 Software Design Methodologies

From designing to coding

Creating Class Definitions from Design Class Diagrams: public class SalesLineItem // Java { private int quantity;

References: Applying UML and patterns Craig Larman

Software Modeling & Analysis

Constantinos Constantinides Computer Science and Software Engineering Concordia University Montreal, Canada

Some Software Engineering Techniques (Class Diagrams and Pair Programming)

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

Download FirstOODesignPractice from SVN. A Software Engineering Technique: (Class Diagrams)

What is a Model? Copyright hebley & Associates

Assigning Responsibilities (Patterns of Responsibility Assignment Principles: GRASP)

Design Engineering. Overview

Information Expert (or Expert)

COMP 354: INTRODUCTION TO SOFTWARE ENGINEERING

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

SE203b: OO Design for Software Engineers. Office: TEB349, Ext

Applying UML & Patterns (3 rd ed.) Chapter 15

Operations Contracts and Preliminaries on Design

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

ADVANCED SOFTWARE DESIGN LECTURE 7 GRASP

Assigning Responsibilities by Larman

2 GRASP Patterns and basic OO Design. Roel Wuyts OASS

Sequence Diagram. A UML diagram used to show how objects interact. Example:

Chapter 3: Object Oriented Design

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

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

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

Sequence Diagram. r: Register s: Sale

PART 5 Elaboration Iteration 3 Intermediate topics. Iteration 3

GRASP: Patterns for. chapter18

On to Object-oriented Design

Last Time: Object Design. Comp435 Object-Oriented Design. Last Time: Responsibilities. Last Time: Creator. Last Time: The 9 GRASP Patterns

Logical Architecture & Design Preliminaries

Design. Furthermore, it is natural to discover and change some requirements during the design and implementation work of the early iterations.

Principles of Software Construction: Objects, Design and Concurrency. Object-Oriented Design: Assigning Responsibilities.

REPRESENTATION OF CLASS DIAGRAM AND SEQUENCE DIAGRAM IN PROCESS MODELING: UML-BASED STUDY

COMP 6471 Software Design Methodologies

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

Modeling Dynamic Behavior

Modeling Dynamic Behavior

ADVANCED SOFTWARE DESIGN LECTURE 4 GRASP. Dave Clarke

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

CS1004: Intro to CS in Java, Spring 2005

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

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

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

On to Object-oriented Design

Understanding class definitions

4 Software models. often more than what people can handle not necessary to know all details at all times

Notes on Chapter Three

Domain Model and Domain Modeling

Anatomy of a Class Encapsulation Anatomy of a Method

CmSc 150 Fundamentals of Computing I. Lesson 28: Introduction to Classes and Objects in Java. 1. Classes and Objects

ITI Introduction to Computing II

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

Software Process. Software Process

Chapter 4: Writing Classes

Domain Modeling: Associations and Attributes

ITI Introduction to Computing II

CMSC 132: Object-Oriented Programming II

Object Oriented Features. Inheritance. Inheritance. CS257 Computer Science I Kevin Sahr, PhD. Lecture 10: Inheritance

Binghamton University. CS-140 Fall Problem Solving. Creating a class from scratch

CS 1302 Chapter 9 (Review) Object & Classes

Today s Agenda. Quick Review

Inheritance. Inheritance Reserved word protected Reserved word super Overriding methods Class Hierarchies Reading for this lecture: L&L

Defining Classes. Chap 1 introduced many concepts informally, in this chapter we will be more formal in defining

Simple Component Writer's Guide

Short Notes of CS201

Handout 7. Defining Classes part 1. Instance variables and instance methods.

CS201 - Introduction to Programming Glossary By

Understanding class definitions. Looking inside classes (based on lecture slides by Barnes and Kölling)

Introduction to Software Engineering (2+1 SWS) Winter Term 2009 / 2010 Dr. Michael Eichberg Vertretungsprofessur Software Engineering Department of

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

Object-Oriented Functional Analysis and Design for POS Example

Object-Oriented Design Lecture 14 CSU 370 Fall 2007 (Pucella) Friday, Nov 2, 2007

Object-Oriented Design

CS112 Lecture: Defining Instantiable Classes

And Even More and More C++ Fundamentals of Computer Science

Object-Oriented Modeling Using UML. CS151 Chris Pollett Aug. 29, 2005.

GRASP Design Patterns A.A. 2018/2019

Object-Oriented Languages and Object-Oriented Design. Ghezzi&Jazayeri: OO Languages 1

C++ (classes) Hwansoo Han

CS 116 Week 8 Page 1

public class TicketMachine Inner part omitted. public class ClassName Fields Constructors Methods

10. Abstract Data Types

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

17. GRASP: Designing Objects with Responsibilities

Zhifu Pei CSCI5448 Spring 2011 Prof. Kenneth M. Anderson

Computer Science II. OO Programming Classes Scott C Johnson Rochester Institute of Technology

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

Problem Solving Object Oriented Design Systems Analysis

Programming II (CS300)

Pointers Ch 9, 11.3 & 13.1

The Unified Modeling Language. Asst.Prof.Dr. Supakit Nootyaskool IT-KMITL

Data Abstraction. Hwansoo Han

Database Design. Overview

Introduction to Programming Using Java (98-388)

Transcription:

OO Design2 POS example - revisited LAR Ch 8 has entire POS design explained READ THIS CHAPTER and ASK Q s in class Design class diagrams Kinds of visibility of objects to one another Navigability of associations How to do implementation from design artifacts? OO Design2-9, CS43 F06, BG Ryder/A Rountev Design Artifacts Design Class Diagrams (DCDs) Differences from Conceptual Class Diagrams in Domain model Contain types, directed associations with multiplicities, numbered actions How visibility between objects is provided Interaction Diagrams Sequence Diagrams Vertical sequence format Communication Diagrams Network format OO Design2-9, CS43 F06, BG Ryder/A Rountev 2

Communication Diagram For POS enteritem(id,qty) :Register 2:makeLineItem(p,qty) :p:=getspec(id) :Product Catalog Façade Controller Creator (of Sale).:p:=find(id) :Product :Product Specification Specification :Sale Creator (of SLI) :SalesLineItem :SalesLineItem 2.2:add(s) 2.:create(p,qty) s:saleslineitem OO Design2-9, CS43 F06, BG Ryder/A Rountev 3 Design Class Diagram for POS (LAR, Fig 8.7) Store address : Address name : Text addcompletesale(...) catalog catalog ProductCatalog... getproductdesc(...) descriptions {Map}..* ProductDescription description : Text price : Money itemid: ItemID... register... Register endsale() enteritem(...) makenewsale() makepayment(...) currentsale completedsales {ordered} Sale iscomplete : Boolean time : DateTime becomecomplete() makelineitem(...) makepayment(...) gettotal() * lineitems {ordered}..* payment SalesLineItem quantity : Integer getsubtotal() Payment amount : Money... description OO Design2-9, CS43 F06, BG Ryder/A Rountev 4 2

Visibility between Objects If object A sends a message to object B, then B must be visible to A i.e., A should have access to a reference (a pointer) to B Ensure the necessary visibility If the interaction diagram shows a message, need to choose the appropriate visibility mechanism to make the message possible OO Design2-9, CS43 F06, BG Ryder/A Rountev 5 Attribute & Parameter Visibility Reference to B is an attribute of A Relatively permanent: often exists for the lifetime of the objects (common) E.g., Register needs to send getspec(id) to ProductCatalog class Register { private ProductCatalog catalog;... } Reference to B is a parameter to a method of A Relatively temporary: exists only for the scope of the method (2nd most common) Often turned into an attribute OO Design2-9, CS43 F06, BG Ryder/A Rountev 6 3

Example of Parameter Visibility enteritem(id,qty) :Register 2:makeLineItem(p,qty) :p:=getspec(id) :Product Catalog parameter visibility from Sale to ProductSpecification void makelineitem(p,qty) { s = new SalesLineItem(p,qty); inside the SLI constructor, p is assigned to an attribute of SLI object :Sale 2.:create(p,qty) s:saleslineitem OO Design2-9, CS43 F06, BG Ryder/A Rountev 7 Local Visibility B is a local object within a method of A A new B object is created and a reference to it is assigned to a local variable An object reference returned by a call is assigned to a local variable Relatively temporary: only exists within the scope of the method (3rd most common) Often transformed into attribute visibility OO Design2-9, CS43 F06, BG Ryder/A Rountev 8 4

Example of Local Visibility enteritem(id,qty) :Register :p:=getspec(id) :Product Catalog enteritem(id,qty) { local visibility from Register to ProductSpecification p = catalog.getspec(id);... } OO Design2-9, CS43 F06, BG Ryder/A Rountev 9 Global Visibility B is defined in a scope that encloses A s scope E.g., a static field is global for all methods inside its declaring class Relatively permanent: typically persists as long as A and B exist (least common) Should be used cautiously: may violate the principles of object orientation Should use Singleton pattern instead OO Design2-9, CS43 F06, BG Ryder/A Rountev 0 5

Design Class Diagrams (DCD) Register enteritem(..) Captures 0.. Sale date time iscomplete:bool makelineitem(..) Design classes Identified while creating interaction diagrams, inspired by domain model Attributes Correspond to domain model Methods Determined from actions in digrams Associations with navigability OO Design2-9, CS43 F06, BG Ryder/A Rountev Type Information Types of attributes (useful to show) Types of method parameters/returns (can be omitted) Register enteritem vs. Register enteritem(itemid,int) OO Design2-9, CS43 F06, BG Ryder/A Rountev 2 6

create messages: create messages Language-independent No create methods in the design classes For many languages: constructor(s) Sometimes people do not show constructors in the DCD: reduces the clutter OO Design2-9, CS43 F06, BG Ryder/A Rountev 3 getters and setters for attributes Internal variables that implement the attribute are private and hidden e.g. internally a Point attribute may be a pair of floating-point numbers E.g., for price attribute of type Money getprice():money setprice(amt:money) Methods are typically not shown in design class (just show attribute) OO Design2-9, CS43 F06, BG Ryder/A Rountev 4 7

Associations in the DCD Based on the interaction diagrams and the domain model Often the associations already exist in the domain model Will there be an ongoing, somewhat permanent connection between an instance of and an instance of Y in order to satisfy the interactions? Common cases to consider: () sends a message to Y or (2) creates Y OO Design2-9, CS43 F06, BG Ryder/A Rountev 5 Partial Communication Diagram enteritem(id,qty) :Register 2:makeLineItem(p,qty) :p:=getspec(id) :Product Catalog :Sale s:saleslineitem 2.:create(p,qty) OO Design2-9, CS43 F06, BG Ryder/A Rountev 6 8

Register enteritem(..) * Looks-in navigability Part of the DCD Captures 0.. ProductCatalog getspec(..) Sale date time iscomplete:bool makelineitem(..) enteritem(id,qty) :p:=getspec(id) :Product Catalog :Register OO Design2-9, CS43 F06, BG Ryder/A Rountev 7 Navigability Property of an association Shows how it will be implemented Who is responsible for knowing the association? Not part of the domain model Navigability from Register to Sale: should be able to traverse the association in that direction Register is responsible for knowing the associated Sale, but not vice versa OO Design2-9, CS43 F06, BG Ryder/A Rountev 8 9

Navigability Could be -way or 2-way Y Not mandatory, but most associations in the DCD should have it Implies attribute visibility Will be implemented by an attribute in class Register The attribute is not shown in the DCD: it is implied by the navigability OO Design2-9, CS43 F06, BG Ryder/A Rountev 9 Creating a Container When creating this interaction diagram, we also considered the domain model Sale date time Contains..* SalesLineItem quantity OO Design2-9, CS43 F06, BG Ryder/A Rountev 20 0

Creating a Container Based on the domain model: decided to use a container for SalesLineItems Sale will create the container This will happen when Sale is created Very common case for one-to-many associations: an attribute of Sale refers to the container Attribute visibility from Sale to the container OO Design2-9, CS43 F06, BG Ryder/A Rountev 2 Representation in the DCD Not necessary to show a separate container class The navigability implies that Sale has an attribute that refers to a set of SalesLineItem objects i.e., to a container storing these objects Sale Contains..* Sales LineItem quantity OO Design2-9, CS43 F06, BG Ryder/A Rountev 22

SalesLineItem & ProductSpecification Domain Model: Sales LineItem quantity:integer Described-by * Product Specification descr:string price:money id:itemid Based on the interaction diagrams: relatively permanent connection Decision: attribute visibility from SalesLineItem to ProductSpec OO Design2-9, CS43 F06, BG Ryder/A Rountev 23 Sale Design Class Diagram..* Contains Sales LineItem Described-by quantity:integer * Product Specification descr:string price:money id:itemid Looks a lot like the domain model, but has more details worked out OO Design2-9, CS43 F06, BG Ryder/A Rountev 24 2

Accessibility of Methods and Fields Public: can be accessed by any code UML notation: +foo Private: can be accessed only by code inside the class UML notation: -foo Protected: can be accessed only by code in the class and in its subclasses UML notation: #foo Fields usually are not public, but have getters and setters instead OO Design2-9, CS43 F06, BG Ryder/A Rountev 25 private static field UML Notation public constructor public static method note: static constructor is meaningless: by definition, a constructor is invoked on an object OO Design2-9, CS43 F06, BG Ryder/A Rountev 26 3

A Quick Look Ahead How to do implementation from design artifacts? OO Design2-9, CS43 F06, BG Ryder/A Rountev 27 Artifact Use-Case Model Supplem. Spec Domain Model Design Model Implem. Model UP Artifacts Incep Elab OO Design2-9, CS43 F06, BG Ryder/A Rountev 28 Const Trans Requirements analysis: Use-Case Model + Supplementary Specification Domain analysis: Domain Model Design: Design Model Coding: Implementation Model 4

Implementation Model UP: code, database definitions, HTML pages, etc. Built from the design model: interaction diagrams and DCDs Design a little, code a little May deviate from the design The design is not perfect In the next iteration: the design will be modified based on the code Reverse engineering OO Design2-9, CS43 F06, BG Ryder/A Rountev 29 Mapping Design to Code DCDs -> classes in code DCD: class names, methods, attributes, superclasses, associations, etc. Tools can do this automatically Interaction diagrams -> method bodies Interactions in the design model imply that certain statements should be included in a method s body OO Design2-9, CS43 F06, BG Ryder/A Rountev 30 5

SalesLineItem quantity:integer getsubtotal() Example Described-by * Product Specification descr:string price:money id:itemid public class SalesLineItem { private int quantity; private ProductSpecification productspec; public SalesLineItem(ProductSpecification s, int q) {} public Money getsubtotal() {} } OO Design2-9, CS43 F06, BG Ryder/A Rountev 3 Another Example: Register class Register makenewsale() enteritem() endsale() makepayment() * Captures 0.. Sale date time iscomplete makelineitem() becomecomplete() makepayment() gettotal() Looks-in ProductCatalog getspec(..) OO Design2-9, CS43 F06, BG Ryder/A Rountev 32 6

Java class Register public class Register { } private Sale sale; private ProductCatalog catalog; public Register (ProductCatalog c) { this.catalog = c; // } public void makenewsale() {} public void enteritem(itemid id, int qty) {} public void endsale() {} public void makepayment(money amt) {} OO Design2-9, CS43 F06, BG Ryder/A Rountev 33 Method makenewsale makenewsale() :Register :create() :Sale :SalesLineItem :SalesLineItem.:create() public class Register { private Sale sale; public void makenewsale() { this.sale = new Sale(); } } OO Design2-9, CS43 F06, BG Ryder/A Rountev 34 7

enteritem(id,qty) Method enteritem() 2:makeLineItem(p,qty) :Register :p:=getspec(id) :Product :Sale Catalog public class Register { public void enteritem(itemid id, int qty) { ProductSpecification p = this.catalog.getspec(id); this.sale.makelineitem(p,qty); } } OO Design2-9, CS43 F06, BG Ryder/A Rountev 35 8