Patterns and Frameworks

Download as pdf or txt
Download as pdf or txt
You are on page 1of 12

Patterns and Frameworks

Patterns and Frameworks

• All well-structured systems are full of patterns.


• A pattern provides a common solution to a common problem
in a given context.
• A mechanism is a design pattern that applies to a society of
classes.
• A framework is typically an architectural pattern that provides
an extensible template for applications within a domain.
• You use patterns to specify mechanisms and frameworks that
shape the architecture of your system.
Mechanisms and Frameworks
• In the UML, you will
typically model design
patterns, also called
mechanisms which you can
represent as collaborations.
• Similarly, you will typically
model architectural patterns
as frameworks, which you
can represent as stereotyped
packages.
Patterns and architecture

• Helps to visualize , specify , construct and


document the artifacts of a software intensive
system.
• Two different patterns
– Design patterns – specify the structure and
behavior of a society of classes
– Architectural patterns (Frameworks) – specify the
structure and behavior of an entire system.
Mechanisms

• A mechanism is just another name for a design pattern that


applies to a society of classes.
• A mechanism simply names a set of abstractions that work
together to carry out some common and interesting behavior.
You model these mechanisms as plain collaborations because
they just name a society of classes.
• Zoom into that collaboration, and you'll see its structural
aspects (typically rendered as class diagrams), as well as its
behavioral aspects (typically rendered as interaction
diagrams).
Figure shows a mechanism names a template for a set of abstractions that work
together to carry out some common and interesting behavior. In this example,
the Subject and the Observer of the pattern are bound to the concrete classes
TaskQueue and SliderBar, respectively.
Frameworks
• A framework is bigger than a mechanism.
• In fact, you can think of a framework as a kind of micro
architecture that encompasses a set of mechanisms that work
together to solve a common problem for a common domain.
• When you specify a framework, you specify the skeleton of
an architecture, together with the slots, tabs, knobs, and dials
that you expose to users who want to adapt that framework to
their own context.
• A framework as a stereotyped package.
Figure illustrates such a framework, named CyclicExecutive. Among other
things, this framework includes a collaboration (CommonEvents)
encompassing a set of event classes, along with a mechanism (EventHandler)
for processing these events in a cyclic fashion. A client that builds on this
framework (such as Pacemaker) could build on the abstractions in
CommonEvents via subclassing and could also apply an instance of the
EventHandler mechanism.
Modeling Design Patterns
• To model a design pattern,
– Identify the common solution to the common problem and
reify it as a mechanism.
– Model the mechanism as a collaboration, providing its
structural as well as its behavioral aspects.
– Identify the elements of the design pattern that must be
bound to elements in a specific context and render them as
parameters to the collaboration.
Modelling a Design Pattern
Figure shows a use of the Command design pattern. As the model indicates, this
design pattern has four parameters that, when you apply the pattern, must be bound
to elements in a given context. This model shows such a binding, in which
Application, PasteCommand, OpenCommand, MenuItem, and Document are bound
to the design pattern's parameters.
Modeling Architectural Patterns
• To model an architectural pattern,
– Harvest the framework from an existing, proven architecture.
– Model the framework as a stereotyped package, containing all the
elements (and especially the design patterns) that are necessary and
sufficient to describe the various views of that framework.
– Expose the plug-ins, interfaces, and parameters necessary to adapt the
framework in the form of design patterns and collaborations. For the
most part, this means making it clear to the user of the pattern which
classes must be extended, which operations must be implemented, and
which signals must be handled.
Modelling an Architectural Pattern
Figure shows a specification of the Blackboard architectural pattern. The heart of
this architecture is the Blackboard design pattern, which dictates how
KnowledgeSources, a Blackboard, and a Controller collaborate. This framework
also includes the design pattern Reasoning engine, which specifies a general
mechanism for how each KnowledgeSource is driven. Finally, as the figure shows,
this framework exposes one use case, Apply new knowledge sources, which
explains to a client how to adapt the framework itself.

References:
Booch, Grady. The unified modeling language user guide. Pearson Education India,
2005.

You might also like