Transcript SYS466 - Seneca College

BTS430 Systems Analysis
and Design using UML
Design Patterns
Patterns

“…a pattern is a named problem/solution
pair that can be applied in new contexts,
with advice on how to apply it in novel
situations and discussion of its trade-offs.”
*
*Larman, page 218
Design Patterns

“The best way to use patterns is to load
your brain with them and then recognize
places in your design and existing
applications where you can apply them.
Instead of code reuse, with patterns you
get experience reuse.”*
*Head First Design Patterns, p. xi
References for Pattern theory

The “Bible”

Design Patterns, Elements of Reusable
Object-Oriented Software
Erich Gamma
 Richard Helm
 Ralph Johnson
 John Vlissides




Authors known as the Gang of Four so the
patterns are called the GoF patterns
First book – 1995
Most complete
References for Pattern theory

Head First Design Patterns



Eric Freeman and Elisabeth Freeman
(“must have” for BTS530 and 630)
Applying UML and Patterns, third
edition

Craig Larman
Beginnings of Patterns

Started with Christopher Alexander, a
Professor of Architecture at Berkeley.



Invented patterns for building living
architectures, e.g., houses, towns, cities
Books: The Timeless Way of Building and A
Pattern Language
Direct analogies between creating “living
architecture” and flexible, extensible software*
*Head First Design Patterns, p. 602
GRASP Patterns

“A learning aid to help you understand
essential object design and apply design
reasoning in a methodical, rational,
explainable way”. *

Patterns of assigning object
responsibilities
*Larman, p. 277
GRASP Patterns
 “GRASP is an acronym that stands for
General Responsibility Assignment
Software Patterns”
The name was chosen to suggest the
importance of grasping these principles to
successfully design object-oriented
software
Larman, p. 222
GRASP Patterns


Do not state new ideas
Name and codify widely used basic
principles*
*Larman, p. 279
Responsibilities


UML defines a responsibility as “a
contract or obligation of a
classifier”.
A class embodies a set of
responsibilities that define the
behaviour of the objects in the
class.
Responsibilities


“A responsibility is not the same thing as
a method, but methods are implemented
to fulfill responsibilities.”
“Responsibilities are implemented using
methods that either act alone or
collaborate with other methods and
objects.”
Larman, p. 217
Fig. 17.2: Responsibilities and methods are
related
: Register
: Sale
makePayment(cashTendered)
makePayment(cashTendered)
create(cashTendered)
Implies Sale
objects have
a
responsibility
To create
Payments
: Payment
Responsibilities revolve around



Doing
Knowing
Collaboration
“Doing” responsibilities



Doing something itself, such as creating
an object or doing a calculation
Initiating action in other objects
Controlling and co-coordinating activities
in other objects
Larman, p. 216
“Knowing” responsibilities




Knowing about private encapsulated data
Knowing about related objects
Knowing about things that it can derive or
calculate
Larman, p. 216
GRASP Patterns

Key three:



Creator
Controller
Information Expert
Creator


Who should be responsible for creating an
new instance of some class?
Some options:

Assign B the responsibility to create A if one or
more of the following is/are true:
 B “contains” A (e.g. Invoice creates
InvoiceLineItem)
 B records A
 B closely uses A
 B has the initializing data for A that will be
passed to A when it is created (thus B is the
Expert with respect to creating A). (e.g. Sale
creates Payment)
p. 291
Creating a SalesLineItem
: Register
: Sale
:
SalesLineItem
makeLineItem(quantity)
create(quantity)
Controller

What first object beyond the UI
layer receives and coordinates a
system operation?

Use Case or Session Controller

Use case/session (e.g. Register)*
Larman, p. 286 and 302
Guidelines/Issues


Controller usually delegates work to other
objects—it controls, coordinates, it does not
do much work itself
Danger: Bloated controller




a single controller receives all system events (and
there are many)
a controller that does the work itself
a controller that has many attributes; maintains
significant information
Among Cures for Bloat

more controllers, use case controllers, more
delegation
Information Expert


What is the general principle of
assigning responsibilities to objects?
A Solution:


Assign a responsibility to the class that
has the information necessary to fulfill
it—the “information expert”
(note: start this process by clearly
stating the responsibility!)
Larman, p. 294
Information Expert

Example: Sale has the responsibility of
knowing its total, expressed with the
method named getTotal
Larman, p. 222
Information Expert
: Register
: Sale
:
SalesLineItem
:
ProductDescription
getTotal( )
getSubtotal( )
getPrice( )
p. 222
Collaboration



Fulfillment of a responsibility often requires
information from different classes of objects
Example, sales total requires the collaboration of 3
classes of objects: Sale, SalesLineItem,
ProductDescription
Interact via messages*
*Larman, p. 297
Facade


Hides all of the complexity of one or more classes
in a simple interface*
Provides a simplified interface to a subsystem
while still exposing the full functionality of the
system to those who may need it*
*Head First Design Patterns, p. 254
*Head First Design Patterns, p. 260
Database Facade
: control or
handler
: data1
: data2
: DBFacade
: Database