Software Engineering

Software Design
Design Patterns

• In software engineering, a design pattern is a general reusable

solution to a commonly occurring problem in software design.
• A design pattern is not a finished design that can be transformed
directly into code. It is a description or template for how to solve
a problem that can be used in many different situations.
• Object-oriented design patterns typically show relationships and
interactions between classes or objects, without specifying the
final application classes or objects that are involved.
---[Link]
What Is a Design Pattern?

• A design pattern
• Is a common solution to a recurring problem in design
• Abstracts a recurring design structure
• Comprises class and/or object
• Dependencies
• Structures
• Interactions
• Conventions
• Names & specifies the design structure explicitly
• Distils design experience
Re-use Code VS. Design

• Code re-use
• Don’t reinvent the wheel
• Requires clean, elegant, understandable, general, stable code
• leverage previous work
• Design re-use
• Don’t reinvent the wheel
• Requires a precise understanding of common, recurring designs
• leverage previous work
Patterns vs “Design”

• Patterns are design

• But: patterns transcend the “identify classes and
associations” approach to design
• Instead: learn to recognize patterns in the problem
space and translate to the solution
• Patterns can capture OO design principles within
a specific domain
• Patterns provide structure to “design”
 Design Patterns VS. Software Patterns

• Not all software patterns are design patterns.

• For instance, algorithms solve computational problems
rather than software design problems.
• Design problem
• Programming problem
• Computational problem
What Makes it a Pattern?

• A Pattern must:
• Solve a problem and be useful
• Have a context and can describe where the solution can
be used
• Recur in relevant situations
• Provide sufficient understanding to tailor the solution
• Have a name and be referenced consistently
 Description of a Design Pattern

• Description of communicating objects and classes that are

customized to solve a general design problem in a
particular context.
• Language- & implementation-independent
• A “micro-architecture”
• Adjunct to existing methodologies (RUP, Fusion, SCRUM,
etc.)
 Description of a Design Pattern

• Graphical notation is generally not sufficient

• In order to reuse design decisions the alternatives and
trade-offs that led to the decisions are critical
knowledge
• Concrete examples are also important
• The history of the why, when, and how set the stage
for the context of usage
 Description of a Design Pattern

• Describe a recurring design structure

• Defines a common vocabulary
• Abstracts from concrete designs
• Identifies classes, collaborations, and responsibilities
• Describes applicability, trade-offs, and consequences
• Formats of pattern writers vary, but a pattern
description usually has at least these four things.
• pattern name
• problem
• solution
• Consequences
 Pattern Name

• A handle used to describe:

• a design problem
• its solutions
• its consequences
• Increases design vocabulary
• Makes it possible to design at a higher level of abstraction
• Enhances communication
• “The Hardest part of programming is coming up with good
variable [function, and type] names.”
 Problem

• Describes when to apply the pattern

• Explains the problem and its context
• May describe specific design problems and/or object
structures
• May contain a list of preconditions that must be met
before it makes sense to apply the pattern
 Solution

• Describes the elements that make up the

• design
• relationships
• responsibilities
• collaborations
• Does not describe specific concrete implementation
• Abstract description of design problems and how the
pattern solves it
Consequences

• Results and trade-offs of applying the pattern

• Critical for:
• evaluating design alternatives
• understanding costs
• understanding benefits of applying the pattern
• Includes the impacts of a pattern on a system’s:
• flexibility
• extensibility
• portability
 Design Pattern Template 16
• Pattern Name and Classification:
• A descriptive and unique name that helps in identifying and referring to the
pattern.
• Intent:
• A description of the goal behind the pattern and the reason for using it.
• Also Known As:
• Other names for the pattern.
• Motivation (Forces):
• A scenario consisting of a problem and a context in which this pattern can be
used.
• Applicability:
• Situations in which this pattern is usable; the context for the pattern.
• Structure:
• A graphical representation of the pattern. Class diagrams and Interaction
diagrams may be used for this purpose.
• Participants:
• A listing of the classes and objects used in the pattern and their roles in the
design.
Design Pattern Template
• Collaboration:
• A description of how classes and objects used in the pattern interact with
each other.
• Consequences:
• A description of the results, side effects, and trade offs caused by using
the pattern.
• Implementation:
• A description of an implementation of the pattern; the solution part of the
pattern.
• Sample Code:
• An illustration of how the pattern can be used in a programming language.
• Known Uses:
• Examples of real usages of the pattern.
• Related Patterns:
• Other patterns that have some relationship with the pattern; discussion of
the differences between the pattern and similar patterns.
Goals of Design Patterns

• Codify good design

• Distil and disseminate experience
• Aid to novices and experts alike
• Abstract how to think about design
• Give design structures explicit names
• Common vocabulary
• Reduced complexity
• Greater expressiveness
• Capture and preserve design information
• Articulate design decisions succinctly
• Improve documentation
• Facilitate restructuring/refactoring
• Patterns are interrelated
• Additional flexibility
Goals of Design Patterns

• Design patterns can speed up the development

process by providing tested, proven development
paradigms.
• Effective software design requires considering issues
that may not become visible until later in the
implementation.
• Reusing design patterns helps to prevent subtle
issues that can cause major problems, and it also
improves code readability for coders and architects
who are familiar with the patterns.
 Why Design Patterns?
20
• Designing OO software is hard
• Designing reusable OO software – harder
• Experienced OO designers make good design
• New designers tend to fall back on non-OO techniques
used before
• Experienced designers know something – what is it?
• Expert designers know not to solve every problem from
first principles.
• They reuse solutions.
• These patterns make OO designs more flexible, elegant,
and ultimately reusable.
Design Patterns
Designing for Change

• A design that doesn’t take change into account risks major

redesign in the future.
• Design patterns help you avoid this by ensuring that a
system can change in specific ways.
Common causes of redesign

• Creating an object by specifying a class explicitly.

• Abstract Factory, Factory Method, Prototype.
• Dependence on specific operations:
• Chain of Responsibility, Command.
• Dependence on hardware and software platform
• Chain of Responsibility, Command
• Dependence on object representations or implementations
• Abstract Factory, Bridge, Memento, Proxy.
• Algorithm dependencies
• Builder, Iterator, Strategy, Template Method, Visitor.
• Tight coupling
• Abstract Factory, Bridge, Chain of Responsibility, Command, Facade,
Mediator, Observer.
• Extending functionality by subclassing
• Bridge, Chain of Responsibility, Composite, Decorator, Observer,
Strategy.
• Inability to alter conveniently
• Adapter, Decorator, Visitor
Benefits of Design Patterns
• Design patterns enable large-scale reuse of
software architectures and also help document
systems
• Patterns explicitly capture expert knowledge and
design tradeoffs and make it more widely
available
• Patterns help improve developer communication
• Pattern names form a common vocabulary
• Patterns help ease the transition to OO technology
Benefits of Design Patterns 25

• Enhance understanding, restructuring, & team

communication
• Basis for automation
• Transcends language-centric biases/myopia
• Abstracts away from many unimportant details
 Drawbacks to Design Patterns

• Patterns do not lead to direct code reuse

• Patterns are deceptively simple
• Teams may suffer from pattern overload
• Patterns are validated by experience and discussion
rather than by automated testing
• Integrating patterns into a software development process
is a human-intensive activity.
• Require significant tedious & error-prone human effort to
handcraft pattern implementations design reuse
• May limit design options
• Leaves some important details unresolved
Design Patterns are NOT

• Designs that can be encoded in classes and

reused as is (i.e., linked lists, hash tables)
• Complex domain-specific designs (for an entire
application or subsystem)

• They are:
• “Descriptions of communicating objects and classes that
are customized to solve a general design problem in a
particular context.”
Characteristics of Good Design 28

• Component independence
• High cohesion
• Low coupling
• Exception identification and handling
• Fault prevention and fault tolerance
• Design for change
M1 M2

M3
Design Principles

• Abstraction
• Modularity, coupling and cohesion
• Information hiding
• Limit complexity
• Hierarchical structure
Abstraction 30

• procedural abstraction: natural consequence of stepwise

refinement: name of procedure denotes sequence of
actions

abstraction subproblems

time
SE, Design, Hans van Vliet, ©2008
Abstraction 31

• data abstraction: aimed at finding a hierarchy in the data

application-oriented
data structures

simpler data
general structure
data structures

SE, Design, Hans van Vliet, ©2008

Modularity 32

• structural criteria which tell us something about individual

modules and their interconnections

• cohesion and coupling

• cohesion: the glue that keeps a module together

• coupling: the strength of the connection between modules

SE, Design, Hans van Vliet, ©2008
Cohesion 33

• Definition
• The degree to which all elements of a component are directed
towards a single task.
• The degree to which all elements directed towards a task are
contained in a single component.
• The degree to which all responsibilities of a single class are related.
• Internal glue with which component is constructed
• All elements of component are directed toward and
essential for performing the same task.

33
Type of Cohesion 34
High Cohesion
Functional

Sequential

Communicational

Procedural

Temporal

Logical

Coincidental Low
34
 Functional
Sequential
Communicational

Coincidental Cohesion 35
Procedural
Temporal
Logical
Coincidental

• Definition: Parts of the component are unrelated (unrelated

functions, processes, or data)
• Parts of the component are only related by their location in
source code.
• Elements needed to achieve some functionality are
scattered throughout the system.
• Accidental
• Worst form

35
 Functional
Sequential
Communicational

Logical Cohesion 36
Procedural
Temporal
Logical
Coincidental

• Definition: Elements of component are related

logically and not functionally.
• Several logically related elements are in the same
component and one of the elements is selected by
the client component.

36
Example 37
• A component reads inputs from tape, disk, and
network.
• All the code for these functions are in the same
component.
• Operations are related, but the functions are
significantly different.
Improvement?

37
 Functional
Sequential
Communicational

Temporal Cohesion 38
Procedural
Temporal
Logical
Coincidental

• Definition: Elements are related by timing involved

• Elements are grouped by when they are processed.
• Example: An exception handler that
• Closes all open files
• Creates an error log
• Notifies user
• Lots of different activities occur, all at same time

38
 Functional
Sequential
Communicational

Procedural Cohesion 39
Procedural
Temporal
Logical
Coincidental

• Definition: Elements of a component are related

only to ensure a particular order of execution.
• Actions are still weakly connected and unlikely
to be reusable.
• Example:
• ...
• Write output record
• Read new input record
• Pad input with spaces
• Return new record
• ...

39
 Functional
Sequential
Communicational

Communicational Cohesion 40
Procedural
Temporal
Logical
Coincidental

• Definition: Functions performed on the same data

or to produce the same data.
• Examples:
• Update record in data base and send it to the printer
• Update a record on a database
• Print the record
• Fetch unrelated data at the same time.
• To minimize disk access

40
 Functional
Sequential
Communicational

Sequential Cohesion 41
Procedural
Temporal
Logical
Coincidental

• Definition: The output of one part is the input to

another.
• Data flows between parts (different from procedural
cohesion)
• Occurs naturally in functional programming
languages
• Good situation

41
 Functional
Sequential
Communicational

Functional Cohesion 42
Procedural
Temporal
Logical
Coincidental

• Definition: Every essential element to a single computation

is contained in the component.
• Every element in the component is essential to the
computation.
• Ideal situation
• What is a functionally cohesive component?
• One that not only performs the task for which it was designed but
• it performs only that function and nothing else.

42
Examples of Cohesion 43
Function A Function A Time t0
Function Function
B C logic Function A’ Time t0 + X
Function Function
D E Function A’’
Time t0 + 2X
Coincidental Logical Temporal
Parts unrelated Similar functions Related by time

Function A

Function B

Function C
Procedural
Related by order of functions
43
Examples of Cohesion (Cont.)
44
Function A Function A

Function B Function B

Function C Function C

Communicational Sequential
Access same data Output of one is input to another

Function A part 1

Function A part 2

Function A part 3

Functional
Sequential with complete, related functions
44
How to determine the cohesion type? 45

• describe the purpose of the module in one sentence

• if the sentence is compound, contains a comma or more than one verb

 it probably has more than one function: logical or communicational
cohesion
• if the sentence contains time-related words like “first”, “then”, “after”
 temporal cohesion
• if the verb is not followed by a specific object  probably logical
cohesion (example: edit all data)
• words like “startup”, “initialize” imply temporal cohesion
SE, Design, Hans van Vliet, ©2008
Coupling 46
• The degree of dependence such as the amount of
interactions among components

No dependencies Loosely coupled Highly coupled

some dependencies many dependencies
Coupling 47
• The degree of dependence such as the amount of
interactions among components
• How can you tell if two components are coupled?
Type of Coupling 48

High Coupling
Content Avoid
Common

External
Control
Loose
Stamp

Data Try to achieve

Low Uncoupled

48
 Content
Common
External
Control

Content Coupling Stamp

Data
Uncoupled
49

• Definition: One component modifies another.

• Example:
• Component directly modifies another’s data
• Component modifies another’s code, e.g., jumps (goto) into the
middle of a routine
• Question
• Language features allowing this?

49
Example 50
Part of a program handles lookup for customer.
When customer not found, component adds
customer by directly modifying the contents of
the data structure containing customer data.

Improvement?

50
 Content
Common
Common Coupling External
Control
Stamp
Data
Uncoupled
51
• Definition: More than one component share
data such as global data structures
• Usually a poor design choice because
• Lack of clear responsibility for the data
• Reduces readability
• Difficult to determine all the components that affect a
data element (reduces maintainability)
• Difficult to reuse components
• Reduces ability to control data accesses

51
Example
52
Process control component maintains current data
about state of operation. Gets data from multiple
sources. Supplies data to multiple sinks. Each source
process writes directly to global data store. Each sink
process reads directly from global data store.
Improvement?

52
 Content
Common

External Coupling
External
Control
Stamp
Data
Uncoupled
53
• Definition: Two components share something
externally imposed, e.g.,
• External file
• Device interface
• Protocol
• Data format
• Improvement?
 Content
Common
External
Control

Control Coupling Stamp

Data
Uncoupled
54
• Definition: Component passes control parameters
to coupled components.
• May be either good or bad, depending on
situation.
• Bad if parameters indicate completely different behavior
• Good if parameters allow factoring and reuse of
functionality

• Good example: sort that takes a comparison

function as an argument.
• The sort function is clearly defined: return a list in sorted
order, where sorted is determined by a parameter.

54
 Content
Common
External
Control

Stamp Coupling Stamp

Data
Uncoupled
55
• Definition: Component passes a data structure to
another component that does not have access to the
entire structure.
• Requires second component to know how to
manipulate the data structure (e.g., needs to know
about implementation).
• The second has access to more information that it
needs.
• May be necessary due to efficiency factors: this is a
choice made by insightful designer, not lazy
programmer.

55
Example 56
Customer Billing System
The print routine of the customer billing
accepts customer data structure as an
argument, parses it, and prints the name,
address, and billing information.

Improvement?

56