Download Lecture 2 for Chapter 8, Object Design: Reusing Pattern

Using UML, Patterns, and Java
Object-Oriented Software Engineering
Chapter 8, Object Design:
Design Patterns II
Recall: Why reusable Designs?
A design…
…enables flexibility to change (reusability)
…minimizes the introduction of new problems when
fixing old ones (maintainability)
…allows the delivery of more functionality after an
initial delivery (extensibility)
…encapsulates software engineering knowledge.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
2
How can we describe Software Engineering
Knowledge?
• Software Engineering Knowledge is not only a set of
algorithms
• It also contains a catalog of patterns describing
generic solutions for recurring problems
• Not described in a programming language.
• Description usually in natural language. A pattern is
presented in form of a schema consisting of sections of text
and pictures (Drawings, UML diagrams, etc.)
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
3
Algorithm vs Pattern
• Algorithm:
• A method for solving a problem using a finite sequence of
well-defined instructions for solving a problem
• Starting from an initial state, the algorithm proceeds
through a series of successive states, eventually terminating
in a final state
• Pattern:
• „A 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, A Pattern language.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
4
Pattern Definition
Original definition (Christopher Alexander): A
pattern is a three-part rule, which expresses a relation
between a certain context, a problem, and a solution
for conflicting forces (design tradeoffs)
Examples:
• The conflicting forces between a sunny room and a room that
does not overheat on on a sunny sommer afternoon
• The conflicting forces between a portable and an efficient
software system.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
5
Pattern Language and Pattern Catalogs
• Pattern Language:
• A collection of patterns that forms a vocabulary for
understanding and communicating ideas
• A collection of patterns and the rules to combine them into
an architectural style. Pattern languages describe software
frameworks or families of related systems.
• Pattern Catalog:
• A pattern catalog is a collection of related patterns. It
typically subdivides the patterns into at least a small
number of broad categories and may include some amount
of cross referencing between patterns.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
6
Schemata for Describing Patterns
Alexander’s Schema (“Alexandrian Form”)
A Pattern Language – Towns Buildings Construction, Christopher
Alexander, Sara Ishikawa, Murray Silverstein, Vol. 2, Oxford
University Press, New York, 1977
Gang of Four Schema
Design Patterns: Elements of Reusable Object-Oriented Software
by Erich Gamma, Richard Helm, Ralph Johnson, and John
Vlissides, Addison Wesley, October 1994
Gang of Five Schema
Pattern-Oriented Software Architecture - A System of Patterns,
Frank Buschmann, Regine Meunier, Hans Rohnert, Peter
Sommerlad, Michael Stal, Wiley and Sons Ltd., 1996.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
7
Patterns originated in Architecture
• Christopher Alexander’s
Philosophy:
• Buildings have been built for thousands
of years by users who where not
architects
• Users know more about what they
need from buildings and towns than
an architect
• Good buildings are based on a set of
design principles that can be described
with a pattern language
Christopher Alexander
* 1936 Vienna, Austria
- More 200 building projects
- Creator of the „Pattern language"
- Professor emeritus at UCB.
Although Alexanders patterns are about architecture and
urban planning, they are applicable to many
other disciplines, including software development.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
8
Alexander’s Schema (“Alexandrian Form”)
•
•
•
•
•
•
Name of the Pattern
Picture of an example for the pattern
Context
Problem: Short description and elaborate description
Solution: Description and Diagram
Conclusion
• Sections don‘t have explicit headings, sections are
separated by symbols
• 3 diamonds between context and problem and after the
solution
• 3 diamonds between solution and conclusion
• Keyword “Therefore” to separate the problem from
the solution.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
9
Example of a Pattern (Alexander’s Schema)
Source http://www.patternlanguage.com/leveltwo/patterns.htm (Subscription required)
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
10
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
11
Name of the Pattern
Problem
Picture of an
example for the
pattern
Separation of Problem from Solution
Solution:
Diagram
Solution:
Description
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
12
Context
Bernd Bruegge & Allen H. Dutoit
Separation between
Solution and Context
Object-Oriented Software Engineering: Using UML, Patterns, and Java
13
More Context
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
14
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
15
Conclusion 151 Small Meeting Rooms
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
16
Design Patterns
• Design Patterns are the foundation for all SE patterns
• Based on Christopher Alexander‘s patterns
• Book by John Vlissedes, Erich Gamma, Ralph Johnson
and Richard Helm, also called the Gang of Four
• Idea for the book at a BOF "Towards an Architecture
Handbook“ (Bruce Anderson at OOPSLA’90)
John Vlissedes
•* 1961-2005
•Stanford
•IBM Watson
Research Center
Erich Gamma
•* 1961
•ETH
•Taligent, IBM
• JUnit, Eclipse,
• Jazz
Bernd Bruegge & Allen H. Dutoit
Ralph Johnson
•* 1955
•University of Illinois,
•Smalltalk, Design
Patterns, Frameworks,
OOPSLA veteran
Richard Helm
• University of Melbourne
•IBM Research, Boston
Consulting Group (Australia)
•Design Patterns
Object-Oriented Software Engineering: Using UML, Patterns, and Java
17
3 Types of Design Patterns (GoF Patterns)
• Structural Patterns
• Reduce coupling between two or more classes
• Introduce an abstract class to enable future extensions
• Encapsulate complex structures
• Behavioral Patterns
• Allow a choice between algorithms and the assignment of
responsibilies to objects (“Who does what?”)
• Characterize complex control flows that are difficult to follow
at runtime
• Creational Patterns
• Allow to abstract from complex instantiation processes
• Make the system independent from the way its objects are
created, composed and represented.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
18
Taxonomy of Design Patterns (23 Patterns)
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
19
Many design patterns use a
combination of inheritance and
delegation
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
20
Adapter Pattern
Client
ClientInterface
LegacyClass
Request()
ExistingRequest()
adaptee
Inheritance
Adapter
Delegation.
Request()
The adapter pattern uses inheritance as well as delegation:
- Interface inheritance: Adapter inherits Request() from ClientInterface
- Delegation: Binds LegacyClass to the Adapter.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
21
Adapter Pattern
• The adapter pattern lets classes work together that
couldn’t otherwise because of incompatible interfaces
• “Convert the interface of a class into another interface expected
by a client class.”
• Used to provide a new interface to existing legacy components
(Interface engineering, reengineering).
• Two adapter patterns:
• Class adapter:
• Uses multiple inheritance to adapt one interface to another
• Object adapter:
• Uses single inheritance and delegation
• Object adapters are much more frequent.
• We cover only object adapters (and call them adapters).
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
22
Taxonomy of Design Patterns
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
23
Bridge Pattern
Delegation
Inheritance
Inheritance
Taxonomy in
Application Domain
Bernd Bruegge & Allen H. Dutoit
Taxonomy in
Solution Domain
Object-Oriented Software Engineering: Using UML, Patterns, and Java
24
Why the Name Bridge Pattern?
It provides a bridge between the Abstraction (in the application
domain) and the Implementor (in the solution domain)
Taxonomy in
Application Domain
Bernd Bruegge & Allen H. Dutoit
Taxonomy in
Solution Domain
Object-Oriented Software Engineering: Using UML, Patterns, and Java
25
Using a Bridge
• The bridge pattern can be used to provide multiple
implementations under the same interface
• Example: Interface to a component that is incomplete, not yet
known or unavailable during testing
• GetPosition() is needed by VIP, but the class Seat is only
available by two simulations (AIMSeat and SARTSeat). To
switch between these, the bridge pattern can be used:
Seat
VIP
GetPosition()
SetPosition()
imp
SeatImplementation
AIMSeat
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
SARTSeat
26
Another use of the Bridge Pattern:
Supporting multiple Database Vendors
Arena
LeagueStore
ODBC Store
Implementor
Bernd Bruegge & Allen H. Dutoit
imp
LeagueStoreImplementor
XML Store
Implementor
JDBC Store
Implementor
Object-Oriented Software Engineering: Using UML, Patterns, and Java
28
Use of the Bridge Pattern:
Supporting multiple Database Vendors
Arena
LeagueStore
ODBC Store
Implementor
Bernd Bruegge & Allen H. Dutoit
imp
LeagueStoreImplementor
XML Store
Implementor
JDBC Store
Implementor
Object-Oriented Software Engineering: Using UML, Patterns, and Java
29
The Bridge Pattern allows to postpone Design
Decisions to the startup time of a system
• Many design decisions are made at design time
(“design window”), or at the latest, at compile time
• Bind a client to one of many implementation classes of an
interface
• The bridge pattern is useful to delay this binding
between client and interface implementation until
run time
• Usually the binding occurs at the start up of the system
(e.g. in the constructor of the interface class).
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
30
Adapter vs Bridge
• Similarities:
• Both hide the details of the underlying implementation
• Difference:
• The adapter pattern is geared towards making unrelated
components work together
• Applied to systems that are already designed (reengineering,
interface engineering projects)
• “Inheritance followed by delegation”
• A bridge, on the other hand, is used up-front in a design to let
abstractions and implementations vary independently
• Green field engineering of an “extensible system”
• New “beasts” can be added to the “zoo” (“application and
solution domain zoo”, even if these are not known at
analysis or system design time
• “Delegation followed by inheritance”.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
31
Taxonomy of Design Patterns (23 Patterns)
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
32
Facade Pattern
• Provides a unified interface to a set of classes in a subsystem
• A façade consists of a set of public operations
• Each public operation is delegated to one or more operations
in the classes behind the facade
• A facade defines a higher-level interface that makes the
subsystem easier to use (i.e. it abstracts out the gory details).
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
33
Subsystem Design with Façade, Adapter,
Bridge
• The ideal structure of a subsystem consists of
• an interface object
• a set of application domain objects (entity objects) modeling
real entities or existing systems
• Some of these application domain objects are interfaces
to existing systems
• one or more control objects
• We can use design patterns to realize this subsystem
structure
• Realization of the interface object: Facade
• Provides the interface to the subsystem
• Interface to the entity objects: Adapter or Bridge
• Provides the interface to an existing system (legacy system)
• The existing system is not necessarily object-oriented!
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
34
Good Design with Façade, Adapter and Bridge
• A façade should be offered by all subsystems in a
software system which provide a set of services
• The façade delegates requests to the appropriate components
within the subsystem. The façade usually does not have to be
changed, when the components are changed
• The adapter pattern should be used to interface to
existing components and legacy systems
• Example: A smart card software system should use an adapter
for a smart card reader from a specific manufacturer
• The bridge pattern should be used to interface to a set
of objects with a large probability of change
• When the full set of objects is not completely known at
analysis or design time (-> Mock Object Pattern)
• When there is a chance that a subsystem or component must
be replaced later after the system has been deployed and
client programs use it in the field.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
35
Design Example
VIP
• Subsystem 1 VIP can call on
any component or class
operation look in Subsystem 2
(Vehicle Subsystem).
Vehicle Subsystem
Seat
Card
AIM
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
SART
36
Realizing an Opaque Architecture with a
Facade
• The Vehicle Subsystem
decides exactly how it is
accessed
• No need to worry about
misuse by callers
• A subsystem with a façade
can be used in an early
integration test
• We need to write only
stubs for each of the
public methods in the
façade.
VIP Subsystem
Vehicle Subsystem Facade
Seat
AIM
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Card
SA/RT
37
Taxonomy of Design Pattern
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
38
Strategy Pattern
• Different algorithms exists for a specific task
• We can switch between the algorithms at run time
• Examples of tasks:
• Different collision strategies for objects in video games
• Parsing a set of tokens into an abstract syntax tree (Bottom up,
top down)
• Sorting a list of customers (Bubble sort, mergesort, quicksort)
• Different algorithms will be appropriate at different
times
• First build, testing the system, delivering the final product
• If we need a new algorithm, we can add it without
disturbing the application or the other algorithms.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
39
Strategy Pattern
Policy
Context
*
Strategy
AlgorithmInterface
ContextInterface()
ConcreteStrategyA
ConcreteStrategyB
ConcreteStrategyC
AlgorithmInterface()
AlgorithmInterface()
AlgorithmInterface()
Policy decides which ConcreteStrategy is best in the current Context.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
40
Using a Strategy Pattern to Decide between
Algorithms at Runtime
Policy
Client
DevelopmentTimeIsImportant
ExecutionTimeIsImportant
SpaceIsImportant
Database
*
SelectSortAlgorithm()
Sort()
Sort()
BubbleSort
Sort()
Bernd Bruegge & Allen H. Dutoit
SortInterface
QuickSort
Sort()
MergeSort
Sort()
Object-Oriented Software Engineering: Using UML, Patterns, and Java
41
Supporting Multiple implementations of a
Network Interface
Context =
{Mobile, Home, Office}
LocationManager
Application
NetworkConnection
NetworkInterface
open()
close()
send()
receive()
send()
receive()
setNetworkInterface()
Ethernet
open()
close()
send()
receive()
Bernd Bruegge & Allen H. Dutoit
WaveLAN
open()
close()
send()
receive()
Object-Oriented Software Engineering: Using UML, Patterns, and Java
UMTS
open()
close()
send()
receive()
42
Taxonomy of Design Patterns
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
43
Abstract Factory Pattern Motivation
• Consider a user interface toolkit that supports
multiple looks and feel standards for different
operating systems:
• How can you write a single user interface and make it
portable across the different look and feel standards for
these window managers?
• Consider a facility management system for an
intelligent house that supports different control
systems:
• How can you write a single control system that is
independent from the manufacturer?
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
44
Abstract Factory
AbstractFactory
Client
AbstractProductA
CreateProductA
CreateProductB
ProductA1
ConcreteFactory1
ProductA2
AbstractProductB
CreateProductA
CreateProductB
ProductB1
ProductB2
ConcreteFactory2
CreateProductA
CreateProductB
Initiation Assocation:
Class ConcreteFactory2 initiates the
associated classes ProductB2 and ProductA2
Applicability for Abstract Factory Pattern
•
•
•
•
Independence from Initialization or Representation
Manufacturer Independence
Constraints on related products
Cope with upcoming change
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
46
Example: A Facility Management System for a House
IntelligentHouse
HouseFactory
createBulb()
createBlind()
EIBFactory
createBulb()
createBlind()
LuxmateFactory
createBulb()
createBlind()
LightBulb
EIBBulb
Bernd Bruegge & Allen H. Dutoit
LuxmateBulb
Blind
EIBBlind
Object-Oriented Software Engineering: Using UML, Patterns, and Java
LuxmateBlind
47
Clues in Nonfunctional Requirements for the
Use of Design Patterns
• Text: “manufacturer independent”,
“device independent”,
“must support a family of products”
=> Abstract Factory Pattern
• Text: “must interface with an existing object”
=> Adapter Pattern
• Text: “must interface to several systems, some
of them to be developed in the future”,
“ an early prototype must be demonstrated”
=>Bridge Pattern
• Text: “must interface to existing set of objects”
=> Façade Pattern
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
48
Clues in Nonfunctional Requirements for use of
Design Patterns (2)
• Text: “complex structure”,
“must have variable depth and width”
=> Composite Pattern
• Text: “must provide a policy independent from
the mechanism”
Strategy Pattern
• Text: “must be location transparent”
=> Proxy Pattern
• Text: “must be extensible”,
“must be scalable”
=> Observer Pattern (MVC Architectural Pattern)
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
49
Summary
• Composite, Adapter, Bridge, Façade, Proxy
(Structural Patterns)
• Focus: Composing objects to form larger structures
• Realize new functionality from old functionality,
• Provide flexibility and extensibility
• Command, Observer, Strategy, Template
(Behavioral Patterns)
• Focus: Algorithms and assignment of responsibilities to
objects
• Avoid tight coupling to a particular solution
• Abstract Factory, Builder (Creational Patterns)
• Focus: Creation of complex objects
• Hide how complex objects are created and put together
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
50
Conclusion
Design patterns
• provide solutions to common problems
• lead to extensible models and code
• can be used as is or as examples of interface inheritance
and delegation
• apply the same principles to structure and to behavior
• Design patterns solve a lot of your software
development problems
• Pattern-oriented development
• My favorites: Observer, Composite, Strategy and
Builder.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
51
Additional Design Heuristics
• Never use implementation inheritance, always use
interface inheritance
• A subclass should never hide operations
implemented in a superclass
• If you are tempted to use implementation
inheritance, use delegation instead
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
52
Example: Modeling Electrical Outlets and
Plugs
• The Type F electrical plug is
identified by two round pins
spaced 19mm apart
• A Type F outlet has two earth
(ground) clips on its side, rather
than a female earth contact.
Bernd Bruegge & Allen H. Dutoit
• The type F electric frequency is
in Hertz (Hz, cycles per second).
Even if voltages are similar, a
60 Hz device may not function
properly on a 50 Hz current, so
check if the type F wall plug is
compatible with your
electronics.
• Otherwise, one needs a type F
plug adaptor that can lower the
internal current. Type F
adapters cannot, however,
change the number of cycles.
Object-Oriented Software Engineering: Using UML, Patterns, and Java
53
Plugs, Transformers
and Adapters
• An electric plug has a prong which can be inserted into the
receptable of an electrical outlet
• A power transformer allows an appliance to get a specific voltage
(110 V) from an electrical outlet providing another voltage (220 V)
• A plug adapter connects appliances and electrical outlets that are
incompatible with each other. One end of the adapter is attached to
the plug used by the appliance, while the other end of the adapter
is connected with the electrical outlet
• Provide a UML model for a plug adapter that converts an
appliance using a type F electrical plug (Germany) with a Type A
electrical outlet (USA).
• A power adapter is an electrical system consisting of a plug adapter
and a power transformer
• Model a power adapter that connects a computer notebook (of
your choice) outlet with a Type F (Germany) electrical outlet as
well as Type A electrical outlet (USA).
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
54
Plugs, Transformers
and Adapters
• An electric plug has a prong which can be inserted into the
receptable of an electrical outlet
• A power transformer allows an appliance to get a specific voltage
(110 V) from an electrical outlet providing another voltage (220 V)
• A plug adapter connects appliances and electrical outlets that are
incompatible with each other. One end of the adapter is attached to
the plug used by the appliance, while the other end of the adapter
is connected with the electrical outlet
• Provide a UML model for a plug adapter that converts an
appliance using a type F electrical plug (Germany) with a Type A
electrical outlet (USA).
• A power adapter is an electrical system consisting of a plug adapter
and a power transformer
• Model a power adapter that connects a computer notebook (of
your choice) outlet with a Type F (Germany) electrical outlet as
well as Type A electrical outlet (USA).
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
55
Universal Adapters
•
A universal adapter offers all the prongs available in the world and can be
inserted into all the electrical outlets anywhere in the world
•
•
Many 220 V countries have converted to the EU standard of 230 V. Legacy 220
V appliances tolerate small variations above or below the rated voltage. But
severe current variations can damage these appliances
•
•
Model a universal adapter that can be inserted into outlets with 2 thin, 3 thin, 2 thick or 3 thick hole
receptables and that provides 2 thin, 3 thin, 2 thick and 3 thick prongs
How do you model severe current variations? How do you prevent them?
Model both, the power transformer as well as the universal power adapter, in a
single system model. You can choose UML or SysML as modeling language.
Which one is better for the modeling task? Justify your answer.
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
56
Example of an Algorithm: Solving the Rubic
Cube
• Speed: Rubik’s Cube in 6 seconds
•
http://www.youtube.com/watch?v=jI_zjWssn2g&feature=related
• Concurrency: 2 Rubik Cubes at the same time
•
http://www.youtube.com/watch?v=RW3akfdEGI8&feature=related
• Scalability: 3 Rubik Cubes in a row
• http://www.youtube.com/watch?v=api7yyAoAug&feature=channel
• Scalability: 10 Rubik Cubes in a row
• http://www.youtube.com/watch?v=51z0Tf76f3Y&feature=channel
• Miscellaneous categories:
• Rubik cube by a 3 year old
• http://www.youtube.com/watch?v=uNcf7KD3QUg&feature=related
• Rubik Cube blindfolded
• http://www.youtube.com/watch?v=JCkI2qh1SF4&NR=1
• Rubik Cube by a Robot
• http://www.youtube.com/watch?v=bNAnUygqOYc&feature=channel
Bernd Bruegge & Allen H. Dutoit
Object-Oriented Software Engineering: Using UML, Patterns, and Java
57