Chapter 12 – Pattern-Based Design

Overview

Pattern-based design creates a new application by finding a set of proven solutions to a

clearly delineated set of problems. Each design pattern provides you with a proven set
of approach to solve one part of design problem. This avoids needlessly “reinventing the
wheel” in each new software project. Pattern-based design begins by examining the
requirements model to isolate the hierarchical set of problems to be solved. The
problem space is partitioned into a set of subproblems. Pattern repositories are
searched for existing design patterns that solve one of the subproblems. Applicable
design patterns are adapted to the specific needs of the software to be built. Custom
problem solutions are created when no design patterns can be found.The major work
product is a design model that depicts the architectural structure, user interface, and
component-level detail. Work products are reviewed for clarity correctness,
completeness, and requirement consistency after the application of each design pattern.

Design Patterns

• A design pattern can be characterized as a three-part rule which expresses a

relation between a certain context, a problem, and a solution.
• context allows the reader to understand the environment in which the problem
resides and what solution might be appropriate within that environment.
• A set of requirements, including limitations and constraints, acts as a system of
forces that influences how the problem can be interpreted within its context and how
the solution can be effectively applied.

Effective Design Patterns

• Solve a specific problem

• Is a proven concept
• Describe a solution isn’t obvious
• Describes a relationship
• Has a significant human component that minimizes human intervention

Pattern Types

• Non-generative - describes a context and a problem but it does not provide any
clear-cut solution.
• Generative - used to “generate” an application or computer-based system whose
architecture enables it to adapt to change.
• Architectural - describe broad-based design problems that are solved using a
structural approach.
• Data - describe recurring data-oriented problems and the data modeling solutions
that can be used to solve them.
• Component (also referred to as design patterns) - address problems associated with
the development of subsystems and components, the manner in which they
communicate with one another, and their placement within a larger architecture,
• Interface - describe common user interface problems and their solution with a
system of forces that includes the specific characteristics of end-users.
• WebApp - address a problem set that is encountered when building WebApps and
often incorporates many of the other patterns categories just mentioned.
• Creational - focus on the “creation, composition, and representation of objects.
• Structural - focus on problems and solutions associated with how classes and
objects are organized and integrated to build a larger structure.
• Behavioral - address problems associated with the assignment of responsibility
between objects and the manner in which communication is effected between
objects.

Frameworks

• Used to complete the design when design patterns are not detailed enough
• Implementation-specific skeletal infrastructure containing plug points (hooks or slots)
that enable it to be adapted to a specific problem domain
• Plug points allow developers to integrate problem specific classes or functionality
within the skeleton
• In object-oriented design a framework would be a set of cooperating classes

Design Pattern Template

• Name
• Intent
• Aliases
• Motivation
• Applicability
• Structure
• Participants
• Collaborators
• Consequences
• Related patterns

Pattern Languages and Repositories

• Pattern language is a collection of interrelated patterns described using

standardized templates that show how these patterns collaborate to solve problems
• Pattern language is analogous to a hypertext instruction manual for problem solving
in a specific application domain
• Pattern repositories provide indices to all design patterns and contain hypermedia
links that enable users to understand pattern collaborations

Thinking in Patterns

1. Be sure you understand the big picture (context in which the software will reside)
2. Extract the patterns that are present at that level of abstraction in the big picture.
3. Begin your design with ‘big picture’ patterns that establish a context or skeleton for
further design work.
4. “Work inward from the context” looking for patterns at lower levels of abstraction that
contribute to the design solution.
5. Repeat steps 1 to 4 until the complete design is fleshed out.
6. Refine the design by adapting each pattern to the specifics of the software you’re
trying to build.

Design Tasks

1. Examine the requirements model and develop a problem hierarchy.

2. Determine if a reliable pattern language has been developed for the problem
domain.
3. Beginning with a broad problem, determine whether one or more architectural
patterns are available for it
4. Using the collaborations provided for the architectural pattern, examine subsystem
or component level problems and search for appropriate patterns to address them.
5. Repeat steps 2 through 5 until all broad problems have been addressed. The
implication is to begin with the big picture, and elaborate to solve problems at
increasingly more detailed levels.
6. If user interface design problems have been isolated (this is almost always the
case), search the many user interface design pattern repositories for appropriate
patterns. Proceed in a manner similar to steps 3, 4, and 5.
7. Regardless of its level of abstraction, if a pattern language and/or patterns repository
or individual pattern shows promise, compare the problem to be solved against the
existing pattern(s) presented.
8. Be certain to refine the design as it is derived from patterns using design quality
criteria as a guide.

Pattern Organization Table

• Helps to categorize and organize candidate patterns from multiple patern languages
and repositories
• Table rows are labeled with abbreviated problem statements subdivided by the
categories data/content, architecture, component-level, user interface issues
• Columns are labeled with pattern types (e.g. database, application, implementation,
infrastructure)
• Candidate pattern names are entered the table cells preferably using a hyperlink or
URL for the pattern

Common Mistakes

• Not spending enough time understanding the problem which causes the selection of
an inappropriate pattern
• Refusing to recognize that a wrong pattern has been selected and trying to force fit
the pattern to the problem
• Applying a pattern too literally and not making the required adaptations to the current
problem space

Architectural Patterns

• Define a specific approach for handling some characteristic of the system

• Before selecting an architectural pattern it must be assessed for its appropriateness
to the application, overall architectural style, context, and system forces

Component-Level Design Patterns

• Provide you with a proven solution that addresses one or more subproblems
extracted from the requirements model
• Many time they focus on a functional element of the system

User Interface Design Pattern Categories

• Top-level navigation
• Card stack
• Fill-in-the-blanks
• Sortable table
• Bread crumbs
• Edit-in-place
• Simple search
• Wizard
• Shopping cart
• Progress indicator
WebApp Design Pattern Categories

• Design focus – identifies the aspect of the design model relevant to problem
o Information architecture patterns – relate to overall structure of information space
and ways in which users will interact with information
o Navigation patterns – define navigation link structures (e.g. hierarchies, rings,
tours)
o Interaction patterns – contribute to the design of the user interface
o Presentation patterns – assist in the presentation of the content via the user
interface
o Functional patterns – define workflows, behaviors, processing, communications,
and other WebApp algorithmic elements
• Granularity – identifies level of abstraction being considered
o Architectural patterns – define the overall WebApp structure and indicate
relationships among components or elements
o Design patterns – address relationships among page elements or mechanisms
for affecting component to component communication
o Component patterns – focuses on relationships among individual WebApp
elements (e.g. interaction elements, navigation items, functional elements)