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

Similar documents
SDC Design patterns GoF

Design Patterns. An introduction

Ingegneria del Software Corso di Laurea in Informatica per il Management. Design Patterns part 1

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

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

Design Pattern What is a Design Pattern? Design Pattern Elements. Almas Ansari Page 1

Design Patterns. Manuel Mastrofini. Systems Engineering and Web Services. University of Rome Tor Vergata June 2011

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

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

A few important patterns and their connections

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

Ingegneria del Software Corso di Laurea in Informatica per il Management. Design Patterns part 1

Design Pattern. CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.)

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Object-Oriented Oriented Programming

Using Design Patterns in Java Application Development

Trusted Components. Reuse, Contracts and Patterns. Prof. Dr. Bertrand Meyer Dr. Karine Arnout

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

CS/CE 2336 Computer Science II

A Rapid Overview of UML

Introduction to Software Engineering. 5. Modeling Objects and Classes

Design patterns. OOD Lecture 6

DESIGN PATTERN - INTERVIEW QUESTIONS

MechEng SE3 Lecture 7 Domain Modelling

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Object Oriented Methods with UML. Introduction to Design Patterns- Lecture 8

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar

Introduction to Software Engineering: Object Design I Reuse & Patterns

Slide 1. Design Patterns. Prof. Mirco Tribastone, Ph.D

Information systems modelling UML and service description languages

Design Patterns. Observations. Electrical Engineering Patterns. Mechanical Engineering Patterns

EPL 603 TOPICS IN SOFTWARE ENGINEERING. Lab 6: Design Patterns

3 Product Management Anti-Patterns by Thomas Schranz

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

Design Patterns. Gunnar Gotshalks A4-1

2 UML for OOAD. 2.1 What is UML? 2.2 Classes in UML 2.3 Relations in UML 2.4 Static and Dynamic Design with UML. UML for OOAD Stefan Kluth 1

Design Patterns. Dr. Rania Khairy. Software Engineering and Development Tool

Keywords: Abstract Factory, Singleton, Factory Method, Prototype, Builder, Composite, Flyweight, Decorator.

Design Pattern and Software Architecture: IV. Design Pattern

Foundations of Software Engineering Design Patterns -- Introduction

1 Software Architecture

Object Oriented Paradigm

What is Design Patterns?

The GoF Design Patterns Reference

Application Architectures, Design Patterns

Plan. Design principles: laughing in the face of change. What kind of change? What are we trying to achieve?

Tuesday, October 4. Announcements

Design Patterns. Hausi A. Müller University of Victoria. Software Architecture Course Spring 2000

An Introduction to Patterns

A - 1. CS 494 Object-Oriented Analysis & Design. UML Class Models. Overview. Class Model Perspectives (cont d) Developing Class Models

Software Engineering Prof. Rushikesh K.Joshi IIT Bombay Lecture-15 Design Patterns

Lectures 24 and 25 Introduction to Architectural Styles and Design Patterns

CSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich

Introduction to Software Engineering. 5. Modeling Objects and Classes

Produced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar

SWEN425 DESIGN PATTERNS

CSC207H: Software Design Lecture 6

LECTURE NOTES ON DESIGN PATTERNS MCA III YEAR, V SEMESTER (JNTUA-R09)

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

Credit where Credit is Due. Lecture 4: Fundamentals of Object Technology. Goals for this Lecture. Real-World Objects

Topics in Object-Oriented Design Patterns

Design Patterns. SE3A04 Tutorial. Jason Jaskolka

Socket attaches to a Ratchet. 2) Bridge Decouple an abstraction from its implementation so that the two can vary independently.

Model Driven Development Unified Modeling Language (UML)

Development and Implementation of Workshop Management System Application to Explore Combing Multiple Design Patterns

A Primer on Design Patterns

Design Patterns Reid Holmes

UML Primer. -Elango Sundaram

SOFTWARE DESIGN COSC 4353 / Dr. Raj Singh

Facade and Adapter. Comp-303 : Programming Techniques Lecture 19. Alexandre Denault Computer Science McGill University Winter 2004

6.3 Patterns. Definition: Design Patterns

2.1 Design Patterns and Architecture (continued)

Software Service Engineering

MVC. Model-View-Controller. Design Patterns. Certain programs reuse the same basic structure or set of ideas

Object-Oriented Introduction

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

UNIT I Introduction to Design Patterns

Modellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico

Class Diagram. Classes consist of. Note that class diagrams contain only classes, not objects.

Unit Wise Questions. Unit-1 Concepts

CSCI Object Oriented Design: Frameworks and Design Patterns George Blankenship. Frameworks and Design George Blankenship 1

Class Diagram. Classes consist of. Note that class diagrams contain only classes, not objects.

Design Patterns. "Gang of Four"* Design Patterns. "Gang of Four" Design Patterns. Design Pattern. CS 247: Software Engineering Principles

TDDB84. Lecture 2. fredag 6 september 13

The Design Patterns Matrix From Analysis to Implementation

2.1 Design Patterns and Architecture (continued)

Design and UML Class Diagrams

CS 247: Software Engineering Principles. Design Patterns

SYLLABUS CHAPTER - 1 [SOFTWARE REUSE SUCCESS FACTORS] Reuse Driven Software Engineering is a Business

Review Software Engineering October, 7, Adrian Iftene

Unified Modeling Language (UML) Class Diagram

LABORATORY 1 REVISION

Summary of the course lectures

Unified Modeling Language

Experiment no 4 Study of Class Diagram in Rational Rose

Software Reengineering Refactoring To Patterns. Martin Pinzger Delft University of Technology

UML & OO FUNDAMENTALS CSCI 4448/5448: OBJECT-ORIENTED ANALYSIS & DESIGN LECTURE 3 08/30/2011

Applying the Observer Design Pattern

THOMAS LATOZA SWE 621 FALL 2018 DESIGN PATTERNS

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

Transcription:

administrivia Assignment 2? promise to get past assignment 1 back soon exam on monday review slides are posted your responsibility to review covers through last week today UML start design patterns 1

Unified Modeling Language common notation not a methodology primarily pictorial very large extensible widely used very different usages UML 2

pre-history UML developed by 3 amigos Grady Booch Ivar Jacobsen Jim Rumbaugh each had their own notation Booch method Objectory (use-case based) OMT (Rumbaugh) 3

history 3 amigos all now work for Rational IBM bought Rational last year unified their notations classic design by committee everything included now open standard controlled by OMG version 2 released earlier this year will focus on version 1.4 most widely used in practice 4

expressive power UML can describe: everything (almost) usually in more than one way often used for class diagrams instance diagrams sometimes used for use cases collaboration diagrams message sequence diagrams state charts 5

your goals I want everyone to be able to read UML diagrams write UML-like diagrams not picky about precise notation your diagrams should be understandable by UML-literate software developers 6

class diagrams class diagrams most common part of UML show inheritance show packages show associations show attributes show operations (methods/functions) 7

class box class is a box with 3 compartments myclass public attr1 : int = 3 private attr2 : String public op(in p1:int, out p2:string) : String class name attributes operations 8

class name additional info can go along with class name mostly using stereotypes come before class name describe usage/semantics of class enclosed in <<... >> examples useful for java include <<interface>> <<final>> abstract indicated with trailing {abstract} name usually written in italics as well sometime just use italics 9

attributes format of attribute is visibility name [multiplicity] : type = default anything but name can be omitted visibility public (+) /private (-) /protected (#) type any primitive type or class or interface default any value of type other options available 10

multiplicity multiplicity indicates how many values appears many places in UML defaults to 1 (one) can be n : any explicit integer or integer expression * : means any number m..n : between m and n values (inclusive) multiplicity, multiplicity : explicitly list options enclosed in [ ] 11

operations operations indicate method available syntax is visibility name (params) : return params in comma separated list with each direction name : type = default direction is in/out/inout 12

inheritance inheritance shown as line use closed hollow arrow head points from subclass to superclass can inherit from classes and interfaces interfaces can inherit only from interfaces 13

inheritance example shape location: Point h: int w: int rectangle circle polygon numsides: int regularpolygon generalpolygon vertices [numsides] : Point 14

associations attributes relate simple values to instances associations relate instances to other instances distinction matter of taste at boundaries how do you think about it as a value or as a related instance examples parent/child, husband/wife 15

displaying associations associations are lines between classes possibly labeled with name one or both ends (for opposite class) may have multiplicity indicated one or both ends at opposite end 16

navigable just because objects are associated may not be possible to get there using what the program knows at least with reasonable performance called navigable if possible efficiently child may store reference to parent without parent storing reference to child indicated by existence of open arrow head double arrow means two-way no arrows means unspecified 17

example manages 1..* Employee name: String salary: int 1 Manager title: String 18

more complicated example 19

aggregation two more kinds of arrows on class diagrams first is aggregation indicates parts on an entity drawn with hollow diamond arrow head e.g., members of a baseball team 20

composition composition is similar to aggregation part can only be sub-part of container has no meaningful independent existence drawn with filled diamond arrow head e.g., link elements in a linked list 21

example 22

collaboration diagram shows sample execution what instances how are they related how do they interact each instance is box Class:name inside :name is optional used to distingush instances all text always underlined 23

collaboration example Goalie watches Ball watches watches Forward teammate Forward 24

interaction diagrams derived from message sequence charts shows message flow 25

design patterns initially developed by gang of four (Gamma, Helms, Johnson, Vlissides) capture experience of class design mostly language independent 30-some patterns defined ongoing development by community hoped to develop common vocabulary limited success thus far 26

specification patterns specified with mostly structured text Name Classification below Intent what does it do? what problem does it address? Motivation typically an example 27

specification (cntd) Applicability when should this pattern be used Participants what classes participate Collaborations how the participants Diagram OMT or UML diagram of interactions 28

specification (cntd) Consequences what are the trade-offs involved Implementation hints for implementing this pattern Sample code example implementations Examples examples of usage in real systems See also closely related patterns alternatives and collaborators 29

classification group patterns to ease finding solutions given as jurisdiction X characterization jurisdiction how large of a domain Object, Class, Compound characterization type of activity Creational, Structural, Behavioral 30

classification table from the gang of four book Creational Structural Behavioral Object Abstract Factory Prototype Singleton Adapter Bridge Flyweight Chain of Resp. Command Mediator Memento Observer Proxy State, Strategy Composite Composite Decorator Facade Iterator Visitor Class Factory Method Builder Template 31

factory - problem want to write code in terms of superclass isolate from knowledge of subclasses one goal of OO design/programming but must know specific class for new often painful to expose correct subclass system dependent classes when private state indicates correct class when possibilities determined at runtime 32

factory - example abstract class java.util.calendar is example describes dates actual info/format depends on locality subclass needed depends on implementation what class should be instantiated? Calendar could break encapsulation Calendar could return flag saying what class 33

factory - problem both are unfortunate choices first breaks major reason for OO second limits subclasses to fixed set documented third choice is to create instance in method pass in necessary info getcalendar() call in this example 34

factory patterns getcalendar called a factory method common pattern often static methods isolates knowledge/choice of subclasses factory classes contain many factory methods may return many different kinds of objects objects will be compatible with each other factory object is instance of factory class methods are not static 35

factory - when use factory method when multiple possibilities localize decision process use factory if subclass is hidden part of implementation (iterators) local version platform/internationalization use factory class/object when multiple objects must cooperate / be from same family 36

classification table from the gang of four book Creational Structural Behavioral Object Abstract Factory Prototype Singleton Adapter Bridge Flyweight Chain of Resp. Command Mediator Memento Observer Proxy State, Strategy Composite Composite Decorator Facade Iterator Visitor Class Factory Method Builder Template 37

flyweight -problem ideally want to treat everything as an object every bit of data objects have a non-trivial overhead especially in memory usage using lots & lots uses lots & lots of memory a traditional complaint about OO too inefficient to use on everything 38

flyweight - example problem consider baseball database record every ball put in play want where runners are want count (balls/strikes) at time ideally want count, runners as objects takes way too much space common hack encode data as int count = #balls*4 + #strikes runners 1=first 2=second 4=third (or bits) 39

flyweight example ugly design exposed representation hard to add extra data you want to record total pitches really need objects so share them 2-0 count is same object in every case only need 19 count objects, 8 runner positions removes memory consideration 40

flyweight pattern flyweight pattern uses this form of sharing called flyweight because incremental cost near 0 just cost of one reference to point to instance about same cost as one int full object for no extra charge need way to get that one instance may need to create if first reference use factory method returns shared instance if existing saves references to each 41

flyweight - when flyweight useful whenever many references to relatively few objects at least few objects actually used instances must be immutable otherwise cannot be shared provide operations to find new object Count.ballCalled() returns another count flyweights make equals very cheap 42

singleton patten suppose have an index of items insert into it when new item created use it to find existing items better have only one or lookup may fail called singleton class if only one instance can be created may actually allow few instances each with defined role 43

singleton pattern make constructor private to enforce limit no one else can create an instance use factory method to instantiate or find closely related to flyweight singleton instances can be mutable want to share changes logically sharing object 44

classification table done so far, plus singleton, state to start today Creational Structural Behavioral Object Abstract Factory Prototype Singleton Adapter Bridge Flyweight Chain of Resp. Command Mediator Memento Observer Proxy State, Strategy Composite Composite Decorator Facade Iterator Visitor Class Factory Method Builder Template 45