The document discusses design patterns, including their basic structure and purpose. A design pattern is a generalized solution to a commonly occurring problem in software design that optimizes certain quality of service aspects. The basic structure of a design pattern includes its name, purpose, solution, and consequences. When facing design problems, developers can use pattern hatching to locate relevant patterns by identifying design criteria and alternatives. Developers can also create their own patterns through pattern mining. Patterns are applied to software through pattern instantiation. An example debouncing pattern addresses intermittent contact issues in mechanical devices.

1. DESIGN PATTERN

2. DESIGN PATTERN
• A design pattern is “a generalized solution to a commonly occurring
problem.”
• A design pattern is away of organizing a design that improves the
optimality of a design with respect to one or a small set of design
criteria, such as qualities of service(QoS).
• A design pattern always has a focused purpose–which is to take one or
a small set of these QoS properties and optimize them at the expense
of the others. Each pattern optimizes some aspect of a system at the
cost of deoptimizing some other aspects. These constitute a set of pros
and cons.

3. BASIC STRUCTURE OF DESIGN PATTERNS
• Name: The name provides a “handle” or means to reference the
pattern.
• Purpose: The purpose provides the problem context and the QoS
aspects the pattern seeks to optimize. The purpose identifies the kinds
of problem contexts where the pattern might be particularly
appropriate.
• Solution: The solution is the pattern itself.
• Consequences: The consequences are the set of pros and cons of the
use of the pattern.

4. NAME
• The pattern name brings us two things. First, it allows us to reference
the pattern in a clear, unambiguous way, with the details present, but
unstated.
• Secondly, it gives us a more abstract vocabulary to speak about our
designs.
• The statement “The system uses a Homogeneous Channel redundant
architecture with Cyclic Executive Concurrency distributed across a
set of processors with a Proxy Pattern” has a lot of information about
the overall structure of the system because we can discuss the
architecture in terms of these patterns.

5. PURPOSE
• The statement “The system uses a Homogeneous Channel redundant
architecture with Cyclic Executive Concurrency distributed across a
set of processors with a Proxy Pattern” has a lot of information about
the overall structure of the system because we can discuss the
architecture in terms of these patterns.
SOLUTION
• The solution specifies the structure and behavior of the pattern itself. It
identifies the elements of the pattern and their roles in the context of
the pattern.
• This pattern solution is integrated into your design in a process known
as pattern instantiation.

6. CONSEQUENCES
• The consequences are important because we always make trade offs
when we select one pattern over another.
• We must understand the pros and cons of the pattern to apply it
effectively.
• The pros and cons are usually couched in terms of improvement or
degradation of some design properties, as well as a possible
elaboration of problem contexts in which these consequences apply.

7. WHAT TO DO WHEN YOU’RE FACING DESIGN
PROBLEMS?

8. PATTERN HATCHING–LOCATING THE RIGHT
PATTERNS
• Familiarize yourself with the patterns: Before starting your design,
familiarize yourself with the patterns literature. Once you have increased
your vocabulary to include patterns likely to be relevant to your
application domain, you have more intellectual ammunition to face your
design challenges.
• Identify design criteria: In parallel with reading about potential design
alternatives, you must identify design criteria. This step identifies the
design optimizations that are important for this particular system in its
operational and development contexts.
• Rank design criteria: Not all optimizations are equally important.
For this reason, the design criteria must be ranked to enable good trade
off decisions to be made.

9. PATTERN HATCHING–LOCATING THE RIGHT
PATTERNS
• Identify potential design alternatives: This step finds patterns that
optimize the design criteria of importance at a cost that seems
reasonable. While it is possible to add a single pattern at a time in this
way and repeat the work flow, it is also common to consider a set of
compatible patterns together as a single design alternative.
• Evaluate the design alternatives: Using the trade study approach
suggested earlier, this step compares the design alternatives (consisting
of one or more design patterns) against each other on the basis of their
effectiveness against the design criteria, weighted with the relative
importance of each.

10. PATTERN HATCHING–LOCATING THE RIGHT
PATTERNS
• Select and apply design alternative: Once a design alternative is
selected, the patterns are usually added to the collaboration one at a
time, including verification of the efficacy of the solution.
• Verify design functionality: The collaboration of software elements
worked before applying the design patterns. This task ensures that it
still does.
• Verify design goals are met: Once the design functionality is verified,
we must also ensure that the optimization goals of the design decisions
result in the right trade offs. If we’ve optimized the code for memory
usage, the usage should be measured as the software runs.

11. PATTERN HATCHING–LOCATING THE RIGHT
PATTERNS

12. PATTERN MINING-ROLLING YOUR OWN
PATTERNS
• Creating your own pattern is
useful, especially when you have
a depth of experience to
understand the optimization
issues in a particular area, and
sufficient breadth to understand
the general properties of the
solutions enough to abstract them
in to a generalized solution.
• This is called pattern mining.

13. PATTERN INSTANTIATION–APPLYING
PATTERNS IN YOUR DESIGNS
• Pattern instantiation is the opposite of
pattern mining. It is applying the pattern to
a particular collaboration to gain the
benefits of the pattern.
• Patterns are normally applied to a
collaboration of software elements, such as
classes, types, functions, and/or variables.
• The application or instantiation of a pattern
in your design is a matter of identifying the
elements in your collaboration that fulfill
the pattern parameter roles.

14. AN EXAMPLE: DEBOUNCING PATTERN
• Abstract: Push buttons, toggle switches, and electromechanical relays are
input devices for digital systems that share a common problem–as metal
connections make contact, the metal deforms or “bounces”, producing
intermittent connections during switch open or closure. This pattern
addresses this concern by reducing the multiple signals into a single one
by waiting a period of time after the initial signal and then checking the
state.
• Problem: As the metal in input devices, used for embedded systems,
moves into contact, physical deformation occurs resulting in an
intermittent bouncing contact until the vibrations dampen down.

15. AN EXAMPLE: DEBOUNCING PATTERN
• Pattern Structure: The basic solution is to accept the initial event, wait
for the vibrations to dampen out, and then sample the data source for its
state.

16. AN EXAMPLE: DEBOUNCING PATTERN
• Collaboration Roles:
1. Application Client: This element is the ultimate recipient of the debounced
event. Its operation deviceEventReceive() is only activated when the event is
real (i.e., results in a changed device state).
2. Bouncing Device: The Bouncing Device represents the hardware for the device
itself. The most common implementation of this device is completely in
hardware.
3. Debouncer: The Debouncer is the software element that processes the
incoming event, debounces it, and makes sure that it represents an actual device
state change.
4. Debouncing Timer: This timer provides an on busy wait via its delay() service.
This is often done with an OS call but might be done with specialty timer
hardware as well.

17. AN EXAMPLE: DEBOUNCING PATTERN
• Consequences: This pattern is not necessary for hardware that debounces before
announcing events. In my experience, however, it often falls on the software to
perform this task. This is a simple pattern that performs the debouncing so that the
application need only concern itself with true events resulting from a change in
device state.
• Implementation Strategies: It is common for the device to use an interrupt
vector to contact its client. It is common for the Bouncing Device to be entirely
implemented in hardware so that when the event occurs, a hardware interrupt is
created, and the device state must be verified by reading a memory location or
portaddress. When the event interface is via an interrupt, the address of the
DeviceClient::eventReceive() operation must be installed in the proper location in
the interrupt vector table when the DeviceClient is initiated.

18. AN EXAMPLE: DEBOUNCING PATTERN
EXAMPLE: