Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving
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
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
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
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
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]
“
”
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.
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.
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
Information Systems
-. Presentation
-. Application logic
-. Domain layer
-. Database