SlideShare ist ein Scribd-Unternehmen logo
1 von 44
Downloaden Sie, um offline zu lesen
Design PatternsDesign Patterns
6 March 20076 March 2007
National University of SingaporeNational University of Singapore
School of ComputingSchool of Computing
OH KWANG SHINOH KWANG SHIN
Design Patterns 6 March 2007 2
AgendaAgenda
• Origin of Pattern
• Software Design Patterns
• Why Use Patterns?
• Describing Design Patterns
• Architectural Pattern
• Pattern System
• Drawbacks of Patterns
Design Patterns 6 March 2007 3
Origin of PatternOrigin of Pattern
Design Patterns 6 March 2007 4
Origin of PatternOrigin of Pattern
Design Patterns 6 March 2007 5
Origin of PatternOrigin of Pattern
Design Patterns 6 March 2007 6
Origin of PatternOrigin of Pattern

Each pattern describes a problem which
occurs over and over again in our
environment, and then describes the core of
the solution to that problem, in such a way that
you can use this solution a million times over,
without ever doing it the same way twice
- Christopher Alexander (Architect) [AIS+
77, page x]
“
”
Design Patterns 6 March 2007 7
Origin of PatternOrigin of Pattern
• “A Pattern Language”
– Berkeley architecture professor
Christopher Alexander in 1977
– Patterns for
• City planning
• Landscaping
– Architecture
• In an attempt to capture
principles for “living” design
Design Patterns 6 March 2007 8
Example 167 (page 783)Example 167 (page 783)
6ft Balcony6ft Balcony
Design Patterns 6 March 2007 9
History ofHistory of
Software Design PatternSoftware Design Pattern
• “Using Pattern Languages for Object-
Oriented Programs”
– Kent Beck and Ward Cunningham,
Tektronix, Inc.
– OOPSLA-87 Workshop
– Used Alexander’s “Pattern” ideas for
designing window-based user interfaces
– Lack of the concrete illustration
Design Patterns 6 March 2007 10
History ofHistory of
Software Design PatternSoftware Design Pattern
• “Design Patterns: Elements of
Reusable Object-Oriented Software”
– Erich Gamma, Richard Helm,
Ralph Johnson, John Vlisssides
– GoF – “Gang of Four”
– Standardization of Pattern
– Four essential elements of Pattern
• Pattern Name, Problem,
Solution, Consequences
Design Patterns 6 March 2007 11
Software Design PatternSoftware Design Pattern

………The design patterns in this
book are descriptions of communicating
objects and classes that are customized
to solve a general design problem in a
particular context. ………
- Design Patterns:
Elements of Reusable Object-Oriented Software
[Addison Wesley, 1995]
“
”
Design Patterns 6 March 2007 12
Why Use Patterns?Why Use Patterns?
• Proven
– Patterns reflect the experience, knowledge and
insights of developers who have successfully
used these patterns in their own work.
• Reusable
– Patterns provide a ready-made solution that
can be adapted to different problems as
necessary.
• Expressive
– Patterns provide a common vocabulary of
solutions that can express large solutions
succinctly.
Design Patterns 6 March 2007 13
Describing Design PatternsDescribing Design Patterns
Alexandrian FormAlexandrian Form
• Name
– meaningful name
• Problem
– the statement of the problem
• Context
– a situation giving rise to a problem
• Forces
– a description of relevant forces and constraints
• Solution
– proven solution to the problem
Design Patterns 6 March 2007 14
Describing Design PatternsDescribing Design Patterns
Alexandrian FormAlexandrian Form
• Examples
– sample applications of the pattern
• Resulting context (force resolution)
– the state of the system after
pattern has been applied
• Rationale
– explanation of steps or rules in the pattern
• Related patterns
– static and dynamic relationship
• Known use
– occurrence of the pattern and
its application within existing system
Design Patterns 6 March 2007 15
Describing Design PatternsDescribing Design Patterns
GoF FormatGoF Format
• Pattern Name and Classification
• Intent
– what does pattern do / when the
solution works
• Also Known As
– other known names of pattern (if any)
• Motivation
– the design problem / how class and
object structures solve the problem
Design Patterns 6 March 2007 16
Describing Design PatternsDescribing Design Patterns
GoF FormatGoF Format
• Applicability
– situations where pattern can be applied
• Structure
– a graphical representation of classes in the
pattern
• Participants
– the classes/objects participating and their
responsibilities
• Collaborations
– how the participants collaborate to carry out
responsibilities
Design Patterns 6 March 2007 17
Describing Design PatternsDescribing Design Patterns
GoF FormatGoF Format
• Consequences
– trade-offs, results, concerns
• Implementation
– hints, techniques
• Sample Code
– code fragment showing possible
implementation
• Known Uses
– patterns found in real systems
• Related Patterns
– closely related patterns
Design Patterns 6 March 2007 18
Design Pattern SpaceDesign Pattern Space
Purpose
Creational Structural Behavioral
Scope Class Factory Method Adapter (class) Interpreter
Template Method
Object Abstract Factory
Builder
Prototype
Singleton
Adapter (object)
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Design Patterns 6 March 2007 19
Design PatternDesign Pattern
SingletonSingleton
• Intent
– Ensure a class only has one instance,
and provide a global point of access to
it.
• Motivation
– Although there can be many printers in
a system, there should be only one
printer spooler
– There should be only one file system
and one window manager
Design Patterns 6 March 2007 20
Design PatternDesign Pattern
SingletonSingleton
• Applicability
– There must be exactly one instance of a
class, and it must be accessible to
clients from a well-known access point
– When the sole instance should be
extensible by subclassing, and clients
should be able to use an extended
instance without modifying their code
Design Patterns 6 March 2007 21
Design PatternDesign Pattern
SingletonSingleton
• Structure
Design Patterns 6 March 2007 22
Design PatternDesign Pattern
SingletonSingleton
• Participants
– Singleton
• Collaborations
– Clients access a Singleton instance
solely through Singleton’s Instance
operation.
Design Patterns 6 March 2007 23
Design PatternDesign Pattern
SingletonSingleton
• Consequences
– Controlled access to sole instance
– Reduced name space
– Permits refinement of operations and
representation
– Permits a variable number of instances
– More flexible than class operations
Design Patterns 6 March 2007 24
Design PatternDesign Pattern
SingletonSingleton
• Implementation - Java
Design Patterns 6 March 2007 25
Design PatternDesign Pattern
SingletonSingleton
• Known Uses
– The set of changes to the code
(ChangeSet current) in Smalltalk-80
– The relationship between classes and
metaclasses
– InterViews user interface toolkit to
access the unique instance of its Session
and WidgetKit classes
Design Patterns 6 March 2007 26
Design PatternDesign Pattern
SingletonSingleton
• Related Patterns
– Many patterns can be implemented
using the Singleton pattern
– Abstract Factory
– Builder
– Prototype
Design Patterns 6 March 2007 27
Architectural PatternArchitectural Pattern

An architectural pattern expresses a
fundamental structure organization schema for
software systems. It provides a set of predefined
subsystems, specifies their responsibilities, and
includes rules and guidelines for organizing the
relationships between them.
- PATTERN-ORIENTED SOFTWARE ARCHITECTURE:
A System of Patterns - Volume 1
[WILEY, 1996]
“
”
Design Patterns 6 March 2007 28
Architectural PatternArchitectural Pattern
LayersLayers
• Example – OSI 7-Layer Model
Design Patterns 6 March 2007 29
Architectural PatternArchitectural Pattern
LayersLayers
• Context
– A large system that requires decomposition
• Problem
– The system we are building is divided by mix
of low- and high-level issues, where high-level
operations reply on the lower-level ones
• Solution
– Structure your system into an appropriate
number of layers and place them on top of
each other
Design Patterns 6 March 2007 30
Architectural PatternArchitectural Pattern
LayersLayers
• Structure
– An individual layer can be described by the
following CRC card:
Class Collaborator
Layer J  Layer J-1
Responsibility
 Provides services
Used by Layer J+1
 Delegates subtasks
to Layer J-1
Class Collaborator
Layer J  Layer J-1
Responsibility
 Provides services
Used by Layer J+1
 Delegates subtasks
to Layer J-1
Design Patterns 6 March 2007 31
Architectural PatternArchitectural Pattern
LayersLayers
• Variants
– Relaxed Layered System
– Layering Through Inheritance
• Known Uses
– Virtual Machines
– APIs
– Information Systems (IS)
– Windows NT
Design Patterns 6 March 2007 32
Architectural PatternArchitectural Pattern
LayersLayers
• Consequences
– Benefits
• Reuse of layers
• Support for standardization
• Dependencies are kept local
• Exchangeability
– Liabilities
• Cascades of changing behavior
• Lower efficiency
• Unnecessary work
• Difficulty of establishing the correct granularity of
layers
Design Patterns 6 March 2007 33
Design PatternDesign Pattern
RelationshipsRelationships
Design Patterns 6 March 2007 34
Pattern CatalogPattern Catalog

………a collection of related
patterns, where patterns are
subdivided into small number of
broad categories………
- PATTERN-ORIENTED SOFTWARE ARCHITECTURE:
A System of Patterns - Volume 1
[WILEY, 1996]
“
”
Design Patterns 6 March 2007 35
Core J2EE Pattern CatalogCore J2EE Pattern Catalog
Design Patterns 6 March 2007 36
Pattern SystemPattern System

A pattern system for software architecture
is a collection of patterns for software architecture,
together with guidelines for their implementation,
combination and practical use in software
development.
- PATTERN-ORIENTED SOFTWARE ARCHITECTURE:
A System of Patterns - Volume 1
[WILEY, 1996]
“
”
Design Patterns 6 March 2007 37
Pattern SystemPattern System
• Motivation
– Individual patterns & pattern catalogs are
insufficient
• Benefits
– Define a vocabulary for talking about
software development problems
– Provide a process for the orderly resolution of
these problems
– Help to generate & reuse software
architectures
Design Patterns 6 March 2007 38
Pattern System – POSA2Pattern System – POSA2
Design Patterns 6 March 2007 39
Drawbacks of PatternsDrawbacks of Patterns
• Pattern is not a Silver Bullet!
• Patterns do not lead to direct code reuse.
• Individual Patterns are deceptively simple.
• Composition of different patterns can be
very complex.
• Teams may suffer from pattern overload.
• Patterns are useful starting points,
but they are not destinations.
Design Patterns 6 March 2007 40
Drawbacks of PatternsDrawbacks of Patterns
• Patterns are validated by experience
and discussion rather than by
automated testing.
• Integrating patterns into a software
development process is a human-
intensive activity.
Design Patterns 6 March 2007 41
ReferencesReferences
• Douglas Schmidt and Frank Buschmann, “Patterns, Frameworks,
and Middleware: Their Synergistic Relationships” Proceedings of
25th
International Conference on Software Engineering, 2003.
• E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns:
Elements of Reusable Object-Oriented Software. MA: Addison-
Wesley, 1995.
• C. Alexander, The Timeless Way of Building. New York, NY:
Oxford University Press, 1979.
• C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-
King, and S. Angel, A Pattern Language. New York, NY: Oxford
University Press, 1977.
Design Patterns 6 March 2007 42
ReferencesReferences
• Kent Beck and Ward Cunningham, “Using Pattern Languages for
Object-Oriented Programs” Submitted to the OOPSLA-87
workshop on the Specification and Design for Object-Oriented
Programming. Available: http://c2.com/doc/oopsla87.html
• J2EE Design Patterns.
Available: http://java.sun.com/blueprints/patterns/index.html
• Douglas C. Schmidt’s Home Page.
Available: http://www.cs.wustl.edu/~schmidt/
• Design pattern – Wikipedia, the free encyclopedia.
Available: http://en.wikipedia.org/wiki/Design_pattern
• Frank Buschmann, Regine Meunier, Hans Rohnert, Peter
Sommerlad, Michael Stal, PATTERN-ORIENTED SOFTWARE
ARCHITECTURE - A System of Patterns. New York: WILEY,
1996.
Design Patterns 6 March 2007 43
ReferencesReferences
• DEEPAK ALUR, JOHN CRUPI, DAN MALKS, CORE J2EE
PATTERNS – Best Practices and Design Strategies. Prentice Hall
PTR, 2001.
• Martin Fowler, PATTERNS OF ENTERPRISE APPLICATION
ARCHITECTURE. Addison-Wesley, 2003.
• GREGOR HOHPE, BOBBY WOOLF, ENTERPRISE
INTEGRATION PATTERNS – DESIGNING, BUILDING, AND
DEPLOYING MESSAGING SOLUTIONS. Addison-Wesley, 2004.
Design Patterns 6 March 2007 44

Weitere ähnliche Inhalte

Was ist angesagt?

WORKFLOW OF THE PROCESS IN SPM
 WORKFLOW OF THE PROCESS IN SPM WORKFLOW OF THE PROCESS IN SPM
WORKFLOW OF THE PROCESS IN SPMgarishma bhatia
 
Architecture design in software engineering
Architecture design in software engineeringArchitecture design in software engineering
Architecture design in software engineeringPreeti Mishra
 
Software component reuse repository
Software component reuse repositorySoftware component reuse repository
Software component reuse repositorySandeep Singh
 
Unit iii-Architecture in the lifecycle
Unit iii-Architecture in the lifecycleUnit iii-Architecture in the lifecycle
Unit iii-Architecture in the lifecycleDhivyaa C.R
 
Spiral model presentation
Spiral model presentationSpiral model presentation
Spiral model presentationSayedFarhan110
 
Architectural styles and patterns
Architectural styles and patternsArchitectural styles and patterns
Architectural styles and patternsHimanshu
 
Agile Software Development Life Cycle
Agile Software Development Life CycleAgile Software Development Life Cycle
Agile Software Development Life CycleUTKARSHSRIVASTAVA235
 
System Models in Software Engineering SE7
System Models in Software Engineering SE7System Models in Software Engineering SE7
System Models in Software Engineering SE7koolkampus
 
Architectural Styles and Case Studies, Software architecture ,unit–2
Architectural Styles and Case Studies, Software architecture ,unit–2Architectural Styles and Case Studies, Software architecture ,unit–2
Architectural Styles and Case Studies, Software architecture ,unit–2Sudarshan Dhondaley
 
Incremental model
Incremental modelIncremental model
Incremental modelHpibmx
 

Was ist angesagt? (20)

WORKFLOW OF THE PROCESS IN SPM
 WORKFLOW OF THE PROCESS IN SPM WORKFLOW OF THE PROCESS IN SPM
WORKFLOW OF THE PROCESS IN SPM
 
Architecture design in software engineering
Architecture design in software engineeringArchitecture design in software engineering
Architecture design in software engineering
 
Software component reuse repository
Software component reuse repositorySoftware component reuse repository
Software component reuse repository
 
Unit iii-Architecture in the lifecycle
Unit iii-Architecture in the lifecycleUnit iii-Architecture in the lifecycle
Unit iii-Architecture in the lifecycle
 
Spiral model presentation
Spiral model presentationSpiral model presentation
Spiral model presentation
 
Architectural styles and patterns
Architectural styles and patternsArchitectural styles and patterns
Architectural styles and patterns
 
Software Development Process
Software Development ProcessSoftware Development Process
Software Development Process
 
Documenting Software Architectures
Documenting Software ArchitecturesDocumenting Software Architectures
Documenting Software Architectures
 
Introduction to UML
Introduction to UMLIntroduction to UML
Introduction to UML
 
Spiral model
Spiral modelSpiral model
Spiral model
 
Agile model
Agile modelAgile model
Agile model
 
Software Architecture
Software ArchitectureSoftware Architecture
Software Architecture
 
Oomd unit1
Oomd unit1Oomd unit1
Oomd unit1
 
software engineering
software engineeringsoftware engineering
software engineering
 
Unified Modeling Language
Unified Modeling LanguageUnified Modeling Language
Unified Modeling Language
 
Agile Software Development Life Cycle
Agile Software Development Life CycleAgile Software Development Life Cycle
Agile Software Development Life Cycle
 
System Models in Software Engineering SE7
System Models in Software Engineering SE7System Models in Software Engineering SE7
System Models in Software Engineering SE7
 
software engineering
 software engineering software engineering
software engineering
 
Architectural Styles and Case Studies, Software architecture ,unit–2
Architectural Styles and Case Studies, Software architecture ,unit–2Architectural Styles and Case Studies, Software architecture ,unit–2
Architectural Styles and Case Studies, Software architecture ,unit–2
 
Incremental model
Incremental modelIncremental model
Incremental model
 

Andere mochten auch

Test Patterns - What is a Pattern?
Test Patterns - What is a Pattern?Test Patterns - What is a Pattern?
Test Patterns - What is a Pattern?Rafael Pires
 
Software Testing: Models, Patterns, Tools
Software Testing: Models, Patterns, ToolsSoftware Testing: Models, Patterns, Tools
Software Testing: Models, Patterns, ToolsBob Binder
 
Software Test Patterns: Successes and Challenges
Software Test Patterns: Successes and ChallengesSoftware Test Patterns: Successes and Challenges
Software Test Patterns: Successes and ChallengesBob Binder
 
Patterns in Test Automation
Patterns in Test AutomationPatterns in Test Automation
Patterns in Test AutomationAnand Bagmar
 

Andere mochten auch (6)

GUI Test Patterns
GUI Test PatternsGUI Test Patterns
GUI Test Patterns
 
Test Patterns - What is a Pattern?
Test Patterns - What is a Pattern?Test Patterns - What is a Pattern?
Test Patterns - What is a Pattern?
 
Software Testing: Models, Patterns, Tools
Software Testing: Models, Patterns, ToolsSoftware Testing: Models, Patterns, Tools
Software Testing: Models, Patterns, Tools
 
JavaScript Patterns
JavaScript PatternsJavaScript Patterns
JavaScript Patterns
 
Software Test Patterns: Successes and Challenges
Software Test Patterns: Successes and ChallengesSoftware Test Patterns: Successes and Challenges
Software Test Patterns: Successes and Challenges
 
Patterns in Test Automation
Patterns in Test AutomationPatterns in Test Automation
Patterns in Test Automation
 

Ähnlich wie CS6201 Software Reuse - Design Patterns

Module 2 design patterns-2
Module 2   design patterns-2Module 2   design patterns-2
Module 2 design patterns-2Ankit Dubey
 
Cs 1023 lec 9 design pattern (week 2)
Cs 1023 lec 9 design pattern (week 2)Cs 1023 lec 9 design pattern (week 2)
Cs 1023 lec 9 design pattern (week 2)stanbridge
 
Design Pattern - Introduction
Design Pattern - IntroductionDesign Pattern - Introduction
Design Pattern - IntroductionMudasir Qazi
 
Design Patterns - General Introduction
Design Patterns - General IntroductionDesign Patterns - General Introduction
Design Patterns - General IntroductionAsma CHERIF
 
Online TechTalk  "Patterns in Embedded SW Design"
Online TechTalk  "Patterns in Embedded SW Design"Online TechTalk  "Patterns in Embedded SW Design"
Online TechTalk  "Patterns in Embedded SW Design"GlobalLogic Ukraine
 
12266422.ppt
12266422.ppt12266422.ppt
12266422.pptCSEC5
 
Design pattern
Design patternDesign pattern
Design patternOmar Isaid
 
Object-Oriented Design Fundamentals.pptx
Object-Oriented Design Fundamentals.pptxObject-Oriented Design Fundamentals.pptx
Object-Oriented Design Fundamentals.pptxRaflyRizky2
 
Cse 6007 fall2012
Cse 6007 fall2012Cse 6007 fall2012
Cse 6007 fall2012rhrashel
 
Design Patterns from 10K feet
Design Patterns from 10K feetDesign Patterns from 10K feet
Design Patterns from 10K feetNaresha K
 
Introduction to design patterns
Introduction to design patternsIntroduction to design patterns
Introduction to design patternsAmit Kabra
 
Design patterns Structural
Design patterns StructuralDesign patterns Structural
Design patterns StructuralUMAR ALI
 
OMG Essence in systems engineering courses
OMG Essence in systems engineering coursesOMG Essence in systems engineering courses
OMG Essence in systems engineering coursesAnatoly Levenchuk
 
Interaction design patterns
Interaction design patternsInteraction design patterns
Interaction design patternsDCU_MPIUA
 

Ähnlich wie CS6201 Software Reuse - Design Patterns (20)

Design Patterns.ppt
Design Patterns.pptDesign Patterns.ppt
Design Patterns.ppt
 
Design patterns
Design patternsDesign patterns
Design patterns
 
Module 2 design patterns-2
Module 2   design patterns-2Module 2   design patterns-2
Module 2 design patterns-2
 
Cs 1023 lec 9 design pattern (week 2)
Cs 1023 lec 9 design pattern (week 2)Cs 1023 lec 9 design pattern (week 2)
Cs 1023 lec 9 design pattern (week 2)
 
Design Pattern - Introduction
Design Pattern - IntroductionDesign Pattern - Introduction
Design Pattern - Introduction
 
Software Design
Software DesignSoftware Design
Software Design
 
Patterns Overview
Patterns OverviewPatterns Overview
Patterns Overview
 
Design Patterns - General Introduction
Design Patterns - General IntroductionDesign Patterns - General Introduction
Design Patterns - General Introduction
 
Online TechTalk  "Patterns in Embedded SW Design"
Online TechTalk  "Patterns in Embedded SW Design"Online TechTalk  "Patterns in Embedded SW Design"
Online TechTalk  "Patterns in Embedded SW Design"
 
12266422.ppt
12266422.ppt12266422.ppt
12266422.ppt
 
Design pattern
Design patternDesign pattern
Design pattern
 
Object-Oriented Design Fundamentals.pptx
Object-Oriented Design Fundamentals.pptxObject-Oriented Design Fundamentals.pptx
Object-Oriented Design Fundamentals.pptx
 
Cse 6007 fall2012
Cse 6007 fall2012Cse 6007 fall2012
Cse 6007 fall2012
 
Design engineering
Design engineeringDesign engineering
Design engineering
 
Design Patterns from 10K feet
Design Patterns from 10K feetDesign Patterns from 10K feet
Design Patterns from 10K feet
 
Introduction to design patterns
Introduction to design patternsIntroduction to design patterns
Introduction to design patterns
 
Design patterns Structural
Design patterns StructuralDesign patterns Structural
Design patterns Structural
 
OMG Essence in systems engineering courses
OMG Essence in systems engineering coursesOMG Essence in systems engineering courses
OMG Essence in systems engineering courses
 
L05 Design Patterns
L05 Design PatternsL05 Design Patterns
L05 Design Patterns
 
Interaction design patterns
Interaction design patternsInteraction design patterns
Interaction design patterns
 

Mehr von Kwangshin Oh

Ruby Programming Language - Introduction
Ruby Programming Language - IntroductionRuby Programming Language - Introduction
Ruby Programming Language - IntroductionKwangshin Oh
 
핀테크 코리아 2014 후기 - 오광신
핀테크 코리아 2014 후기 - 오광신핀테크 코리아 2014 후기 - 오광신
핀테크 코리아 2014 후기 - 오광신Kwangshin Oh
 
CS6270 Virtual Machines - Java Virtual Machine Architecture and APIs
CS6270 Virtual Machines - Java Virtual Machine Architecture and APIsCS6270 Virtual Machines - Java Virtual Machine Architecture and APIs
CS6270 Virtual Machines - Java Virtual Machine Architecture and APIsKwangshin Oh
 
CS6270 Virtual Machines - Retargetable Binary Translators
CS6270 Virtual Machines - Retargetable Binary TranslatorsCS6270 Virtual Machines - Retargetable Binary Translators
CS6270 Virtual Machines - Retargetable Binary TranslatorsKwangshin Oh
 
CS5261 Group 8 Presentation - US Mobile Industry
CS5261 Group 8 Presentation - US Mobile IndustryCS5261 Group 8 Presentation - US Mobile Industry
CS5261 Group 8 Presentation - US Mobile IndustryKwangshin Oh
 
Jini Network Technology
Jini Network TechnologyJini Network Technology
Jini Network TechnologyKwangshin Oh
 
Object-Oriented Programming Concepts
Object-Oriented Programming ConceptsObject-Oriented Programming Concepts
Object-Oriented Programming ConceptsKwangshin Oh
 

Mehr von Kwangshin Oh (7)

Ruby Programming Language - Introduction
Ruby Programming Language - IntroductionRuby Programming Language - Introduction
Ruby Programming Language - Introduction
 
핀테크 코리아 2014 후기 - 오광신
핀테크 코리아 2014 후기 - 오광신핀테크 코리아 2014 후기 - 오광신
핀테크 코리아 2014 후기 - 오광신
 
CS6270 Virtual Machines - Java Virtual Machine Architecture and APIs
CS6270 Virtual Machines - Java Virtual Machine Architecture and APIsCS6270 Virtual Machines - Java Virtual Machine Architecture and APIs
CS6270 Virtual Machines - Java Virtual Machine Architecture and APIs
 
CS6270 Virtual Machines - Retargetable Binary Translators
CS6270 Virtual Machines - Retargetable Binary TranslatorsCS6270 Virtual Machines - Retargetable Binary Translators
CS6270 Virtual Machines - Retargetable Binary Translators
 
CS5261 Group 8 Presentation - US Mobile Industry
CS5261 Group 8 Presentation - US Mobile IndustryCS5261 Group 8 Presentation - US Mobile Industry
CS5261 Group 8 Presentation - US Mobile Industry
 
Jini Network Technology
Jini Network TechnologyJini Network Technology
Jini Network Technology
 
Object-Oriented Programming Concepts
Object-Oriented Programming ConceptsObject-Oriented Programming Concepts
Object-Oriented Programming Concepts
 

Kürzlich hochgeladen

20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-pyJamie (Taka) Wang
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxGDSC PJATK
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?IES VE
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
AI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarAI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarPrecisely
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsSafe Software
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8DianaGray10
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 

Kürzlich hochgeladen (20)

20230202 - Introduction to tis-py
20230202 - Introduction to tis-py20230202 - Introduction to tis-py
20230202 - Introduction to tis-py
 
Cybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptxCybersecurity Workshop #1.pptx
Cybersecurity Workshop #1.pptx
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?How Accurate are Carbon Emissions Projections?
How Accurate are Carbon Emissions Projections?
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
AI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity WebinarAI You Can Trust - Ensuring Success with Data Integrity Webinar
AI You Can Trust - Ensuring Success with Data Integrity Webinar
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration WorkflowsIgniting Next Level Productivity with AI-Infused Data Integration Workflows
Igniting Next Level Productivity with AI-Infused Data Integration Workflows
 
20150722 - AGV
20150722 - AGV20150722 - AGV
20150722 - AGV
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 

CS6201 Software Reuse - Design Patterns

  • 1. Design PatternsDesign Patterns 6 March 20076 March 2007 National University of SingaporeNational University of Singapore School of ComputingSchool of Computing OH KWANG SHINOH KWANG SHIN
  • 2. Design Patterns 6 March 2007 2 AgendaAgenda • Origin of Pattern • Software Design Patterns • Why Use Patterns? • Describing Design Patterns • Architectural Pattern • Pattern System • Drawbacks of Patterns
  • 3. Design Patterns 6 March 2007 3 Origin of PatternOrigin of Pattern
  • 4. Design Patterns 6 March 2007 4 Origin of PatternOrigin of Pattern
  • 5. Design Patterns 6 March 2007 5 Origin of PatternOrigin of Pattern
  • 6. Design Patterns 6 March 2007 6 Origin of PatternOrigin of Pattern  Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice - Christopher Alexander (Architect) [AIS+ 77, page x] “ ”
  • 7. Design Patterns 6 March 2007 7 Origin of PatternOrigin of Pattern • “A Pattern Language” – Berkeley architecture professor Christopher Alexander in 1977 – Patterns for • City planning • Landscaping – Architecture • In an attempt to capture principles for “living” design
  • 8. Design Patterns 6 March 2007 8 Example 167 (page 783)Example 167 (page 783) 6ft Balcony6ft Balcony
  • 9. Design Patterns 6 March 2007 9 History ofHistory of Software Design PatternSoftware Design Pattern • “Using Pattern Languages for Object- Oriented Programs” – Kent Beck and Ward Cunningham, Tektronix, Inc. – OOPSLA-87 Workshop – Used Alexander’s “Pattern” ideas for designing window-based user interfaces – Lack of the concrete illustration
  • 10. Design Patterns 6 March 2007 10 History ofHistory of Software Design PatternSoftware Design Pattern • “Design Patterns: Elements of Reusable Object-Oriented Software” – Erich Gamma, Richard Helm, Ralph Johnson, John Vlisssides – GoF – “Gang of Four” – Standardization of Pattern – Four essential elements of Pattern • Pattern Name, Problem, Solution, Consequences
  • 11. Design Patterns 6 March 2007 11 Software Design PatternSoftware Design Pattern  ………The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. ……… - Design Patterns: Elements of Reusable Object-Oriented Software [Addison Wesley, 1995] “ ”
  • 12. Design Patterns 6 March 2007 12 Why Use Patterns?Why Use Patterns? • Proven – Patterns reflect the experience, knowledge and insights of developers who have successfully used these patterns in their own work. • Reusable – Patterns provide a ready-made solution that can be adapted to different problems as necessary. • Expressive – Patterns provide a common vocabulary of solutions that can express large solutions succinctly.
  • 13. Design Patterns 6 March 2007 13 Describing Design PatternsDescribing Design Patterns Alexandrian FormAlexandrian Form • Name – meaningful name • Problem – the statement of the problem • Context – a situation giving rise to a problem • Forces – a description of relevant forces and constraints • Solution – proven solution to the problem
  • 14. Design Patterns 6 March 2007 14 Describing Design PatternsDescribing Design Patterns Alexandrian FormAlexandrian Form • Examples – sample applications of the pattern • Resulting context (force resolution) – the state of the system after pattern has been applied • Rationale – explanation of steps or rules in the pattern • Related patterns – static and dynamic relationship • Known use – occurrence of the pattern and its application within existing system
  • 15. Design Patterns 6 March 2007 15 Describing Design PatternsDescribing Design Patterns GoF FormatGoF Format • Pattern Name and Classification • Intent – what does pattern do / when the solution works • Also Known As – other known names of pattern (if any) • Motivation – the design problem / how class and object structures solve the problem
  • 16. Design Patterns 6 March 2007 16 Describing Design PatternsDescribing Design Patterns GoF FormatGoF Format • Applicability – situations where pattern can be applied • Structure – a graphical representation of classes in the pattern • Participants – the classes/objects participating and their responsibilities • Collaborations – how the participants collaborate to carry out responsibilities
  • 17. Design Patterns 6 March 2007 17 Describing Design PatternsDescribing Design Patterns GoF FormatGoF Format • Consequences – trade-offs, results, concerns • Implementation – hints, techniques • Sample Code – code fragment showing possible implementation • Known Uses – patterns found in real systems • Related Patterns – closely related patterns
  • 18. Design Patterns 6 March 2007 18 Design Pattern SpaceDesign Pattern Space Purpose Creational Structural Behavioral Scope Class Factory Method Adapter (class) Interpreter Template Method Object Abstract Factory Builder Prototype Singleton Adapter (object) Bridge Composite Decorator Façade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor
  • 19. Design Patterns 6 March 2007 19 Design PatternDesign Pattern SingletonSingleton • Intent – Ensure a class only has one instance, and provide a global point of access to it. • Motivation – Although there can be many printers in a system, there should be only one printer spooler – There should be only one file system and one window manager
  • 20. Design Patterns 6 March 2007 20 Design PatternDesign Pattern SingletonSingleton • Applicability – There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point – When the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code
  • 21. Design Patterns 6 March 2007 21 Design PatternDesign Pattern SingletonSingleton • Structure
  • 22. Design Patterns 6 March 2007 22 Design PatternDesign Pattern SingletonSingleton • Participants – Singleton • Collaborations – Clients access a Singleton instance solely through Singleton’s Instance operation.
  • 23. Design Patterns 6 March 2007 23 Design PatternDesign Pattern SingletonSingleton • Consequences – Controlled access to sole instance – Reduced name space – Permits refinement of operations and representation – Permits a variable number of instances – More flexible than class operations
  • 24. Design Patterns 6 March 2007 24 Design PatternDesign Pattern SingletonSingleton • Implementation - Java
  • 25. Design Patterns 6 March 2007 25 Design PatternDesign Pattern SingletonSingleton • Known Uses – The set of changes to the code (ChangeSet current) in Smalltalk-80 – The relationship between classes and metaclasses – InterViews user interface toolkit to access the unique instance of its Session and WidgetKit classes
  • 26. Design Patterns 6 March 2007 26 Design PatternDesign Pattern SingletonSingleton • Related Patterns – Many patterns can be implemented using the Singleton pattern – Abstract Factory – Builder – Prototype
  • 27. Design Patterns 6 March 2007 27 Architectural PatternArchitectural Pattern  An architectural pattern expresses a fundamental structure organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them. - PATTERN-ORIENTED SOFTWARE ARCHITECTURE: A System of Patterns - Volume 1 [WILEY, 1996] “ ”
  • 28. Design Patterns 6 March 2007 28 Architectural PatternArchitectural Pattern LayersLayers • Example – OSI 7-Layer Model
  • 29. Design Patterns 6 March 2007 29 Architectural PatternArchitectural Pattern LayersLayers • Context – A large system that requires decomposition • Problem – The system we are building is divided by mix of low- and high-level issues, where high-level operations reply on the lower-level ones • Solution – Structure your system into an appropriate number of layers and place them on top of each other
  • 30. Design Patterns 6 March 2007 30 Architectural PatternArchitectural Pattern LayersLayers • Structure – An individual layer can be described by the following CRC card: Class Collaborator Layer J  Layer J-1 Responsibility  Provides services Used by Layer J+1  Delegates subtasks to Layer J-1 Class Collaborator Layer J  Layer J-1 Responsibility  Provides services Used by Layer J+1  Delegates subtasks to Layer J-1
  • 31. Design Patterns 6 March 2007 31 Architectural PatternArchitectural Pattern LayersLayers • Variants – Relaxed Layered System – Layering Through Inheritance • Known Uses – Virtual Machines – APIs – Information Systems (IS) – Windows NT
  • 32. Design Patterns 6 March 2007 32 Architectural PatternArchitectural Pattern LayersLayers • Consequences – Benefits • Reuse of layers • Support for standardization • Dependencies are kept local • Exchangeability – Liabilities • Cascades of changing behavior • Lower efficiency • Unnecessary work • Difficulty of establishing the correct granularity of layers
  • 33. Design Patterns 6 March 2007 33 Design PatternDesign Pattern RelationshipsRelationships
  • 34. Design Patterns 6 March 2007 34 Pattern CatalogPattern Catalog  ………a collection of related patterns, where patterns are subdivided into small number of broad categories……… - PATTERN-ORIENTED SOFTWARE ARCHITECTURE: A System of Patterns - Volume 1 [WILEY, 1996] “ ”
  • 35. Design Patterns 6 March 2007 35 Core J2EE Pattern CatalogCore J2EE Pattern Catalog
  • 36. Design Patterns 6 March 2007 36 Pattern SystemPattern System  A pattern system for software architecture is a collection of patterns for software architecture, together with guidelines for their implementation, combination and practical use in software development. - PATTERN-ORIENTED SOFTWARE ARCHITECTURE: A System of Patterns - Volume 1 [WILEY, 1996] “ ”
  • 37. Design Patterns 6 March 2007 37 Pattern SystemPattern System • Motivation – Individual patterns & pattern catalogs are insufficient • Benefits – Define a vocabulary for talking about software development problems – Provide a process for the orderly resolution of these problems – Help to generate & reuse software architectures
  • 38. Design Patterns 6 March 2007 38 Pattern System – POSA2Pattern System – POSA2
  • 39. Design Patterns 6 March 2007 39 Drawbacks of PatternsDrawbacks of Patterns • Pattern is not a Silver Bullet! • Patterns do not lead to direct code reuse. • Individual Patterns are deceptively simple. • Composition of different patterns can be very complex. • Teams may suffer from pattern overload. • Patterns are useful starting points, but they are not destinations.
  • 40. Design Patterns 6 March 2007 40 Drawbacks of PatternsDrawbacks of Patterns • Patterns are validated by experience and discussion rather than by automated testing. • Integrating patterns into a software development process is a human- intensive activity.
  • 41. Design Patterns 6 March 2007 41 ReferencesReferences • Douglas Schmidt and Frank Buschmann, “Patterns, Frameworks, and Middleware: Their Synergistic Relationships” Proceedings of 25th International Conference on Software Engineering, 2003. • E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. MA: Addison- Wesley, 1995. • C. Alexander, The Timeless Way of Building. New York, NY: Oxford University Press, 1979. • C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl- King, and S. Angel, A Pattern Language. New York, NY: Oxford University Press, 1977.
  • 42. Design Patterns 6 March 2007 42 ReferencesReferences • Kent Beck and Ward Cunningham, “Using Pattern Languages for Object-Oriented Programs” Submitted to the OOPSLA-87 workshop on the Specification and Design for Object-Oriented Programming. Available: http://c2.com/doc/oopsla87.html • J2EE Design Patterns. Available: http://java.sun.com/blueprints/patterns/index.html • Douglas C. Schmidt’s Home Page. Available: http://www.cs.wustl.edu/~schmidt/ • Design pattern – Wikipedia, the free encyclopedia. Available: http://en.wikipedia.org/wiki/Design_pattern • Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, PATTERN-ORIENTED SOFTWARE ARCHITECTURE - A System of Patterns. New York: WILEY, 1996.
  • 43. Design Patterns 6 March 2007 43 ReferencesReferences • DEEPAK ALUR, JOHN CRUPI, DAN MALKS, CORE J2EE PATTERNS – Best Practices and Design Strategies. Prentice Hall PTR, 2001. • Martin Fowler, PATTERNS OF ENTERPRISE APPLICATION ARCHITECTURE. Addison-Wesley, 2003. • GREGOR HOHPE, BOBBY WOOLF, ENTERPRISE INTEGRATION PATTERNS – DESIGNING, BUILDING, AND DEPLOYING MESSAGING SOLUTIONS. Addison-Wesley, 2004.
  • 44. Design Patterns 6 March 2007 44

Hinweis der Redaktion

  1. A design pattern has 4 essential elements: 1. The pattern name is a handle we can use to describe a design problem, its solutions, and consequences; it usually consists of one or two words. 2. The problem describes when to apply the pattern. 3. The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. 4. The consequences are the results and trade-offs of applying the pattern.
  2. Design Pattern Space 1. Creational patterns -. Deal with initializing and configuring classes and objects 2. Structural patterns -. Deal with decoupling interface and implementation of objects 3. Behavioural patterns -. Deal with dynamic interactions among societies of classes and objects
  3. Information Systems -. Presentation -. Application logic -. Domain layer -. Database