Patterns and

Categories
M2 – Design thinking
What is a pattern?
• A pattern addresses a recurring design problem that arises in specific design situations, and
presents a solution to it

• Context: a situation giving rise to a problem.

• Problem: the recurring problem arising in that context.
• Solution: a proven resolution of the problem.

Eg:
• The Model-View-Controller pattern specifies two forces:
• it should be easy to modify the user interface,
• but the functional core of the software should not be affected by its modification.
What is a pattern?
Properties of patterns for software architecture

• Patterns document existing, well-proven design experience.

• Patterns are a means of documenting software architectures
• Patterns identify and specify abstractions that are above the level of single classes and
instances, or of components
• Patterns support the construction of software with defined properties.
• Patterns help you build complex and heterogeneous software architectures
• Patterns help you to manage software complexity
What is a pattern?
Pattern categories
Three categories

1. Architectural patterns
2. Design patters
3. Idioms
Types of Patterns
1. An architectural pattern expresses a fundamental structural organization schema for
software systems. It provides a set of predefined subsystems, specifies their
responsibilities, and includes rules and guidelines for organizing the relationships between
them.
• Eg; MVC

2. A design pattern provides a scheme for refining the subsystems or components of a

software system, or the relationships between them. It describes a commonly-recurring
structure of communicating components that solves a general design problem within a
particular context.
• Small in scale, independent of programming language,
• Eg; Publish-subscribe.
Types of Patterns
3. Idioms
An idiom is a low-level pattern specific to a programming language. An idiom describes how
to implement particular aspects of components or the relationships between them using the
features of the given language.
• Lowest level pattern, addresses design and implementation, are language specific.
• Eg: Reference counting in C++, Garbage collection in smalltalk, java etc.
Layers
The Layers architectural pattern helps to structure applications that can be decomposed into
groups of subtasks in which each group of subtasks is at a particular level of abstraction.
• Eg: Networking
a protocol consists of a set of rules and conventions that
describe how computer programs communicate across
machine boundaries.
Layers
1. Define the abstraction criterion for grouping tasks into
layers T
2. Determine the number of abstraction levels according to
your abstraction criterion. Each abstraction level
corresponds to one layer of the pattern
3. Name the layers and assign tasks to each of them
4. Specify the services. The most important implementation
principle is that layers are strictly separated from each
other
5. Refine the layering. Iterate over steps 1 to 4
6. Specify an interface for each layer. If Layer J should be a
'black box’ for Layer J+1, design a flat interface that offers
all Layer J's services
7. Structure individual layers
8. Specify the communication between adjacent layers.
9. Decouple adjacent layer
10. Design a n error-handling strategy.
Layers
1. Define the abstraction criterion for grouping tasks into
layers T
2. Determine the number of abstraction levels according to
your abstraction criterion. Each abstraction level
corresponds to one layer of the pattern
3. Name the layers and assign tasks to each of them
4. Specify the services. The most important implementation
principle is that layers are strictly separated from each
other
5. Refine the layering. Iterate over steps 1 to 4
6. Specify an interface for each layer. If Layer J should be a
'black box’ for Layer J+1, design a flat interface that offers
all Layer J's services
7. Structure individual layers
8. Specify the communication between adjacent layers.
9. Decouple adjacent layer
10. Design a n error-handling strategy.
Pipes and Filters
• The Pipes and Filters architectural pattern provides a structure for systems that process
a stream of data. Each processing step is encapsulated in a filter component.

• Data is passed through pipes between adjacent filters.

• Recombining filters allows you to build families

of related systems.
Pipes and Filters
• Filter components are the processing units of the pipeline.
• A filter enriches, refines or transforms its input data. It enriches data by computing and adding information,
refines data by concentrating or extracting information, and transforms data by delivering the data in some
other representation
• Pipes denote the connections between filters, between the data source and the first filter, and between the last
filter and the data sink. If two active components are joined, the pipe synchronizes them.
• The data source represents the input to the system, and provides a sequence of data values of the same
structure or type
• The data sink collects the results from the end of the pipeline
Pipes and Filters
Blackboard
• The Blackboard architectural pattern is useful for
problems for which no deterministic solution
strategies are known.
• In Blackboard several specialized subsystems
assemble their knowledge to build a possibly
partial or approximate solution.

Example: Voice recognition and accents

• There is no consistent algorithm that combines all
the necessary procedures for recognizing speech
• To make matters worse, the problem is
characterized by the ambiguities of spoken
language, noisy data, and the individual
peculiarities of speakers such as vocabulary,
pronunciation, and syntax.
Blackboard
To implement the Blackboard pattern, carry out the following steps:
1. Define the problem
2. Define the solution space for the problem
3. Divide the solution process into steps: high-level solutions, abstractions, hypothesis, etc.
4. Divide the knowledge into specialized knowledge sources with certain subtasks. These subtasks often
correspond to areas of specialization.
5. Define the vocabulary of the blackboard. Elaborate your first definition of the solution space and the abstraction
levels of your solutions. Find a representation for solutions that allows all knowledge sources to read from and
contribute to the blackboard.
6. Specify the control of the system The Control component implements an opportunistic problem-solving strategy
that determines which knowledge sources are allowed to make changes to the blackboard.
7. Implement the knowledge sources. Split the knowledge sources into condition-parts and action-parts according
to the needs of the Control component. To maintain the independency and exchangeability of knowledge
sources, do not make any assumptions about other knowledge sources or the Control component.
Distributed - Broker
• The Broker architectural pattern can
be used to structure distributed
software systems with decoupled
components that interact by remote
service invocations.
• A broker component Is responsible
for coordinating communication,
such as forwarding requests, as well
as for transmitting results and
exceptions.
• Broker architectural pattern
comprises six types of participating
components: clients. servers,
brokers, bridges, client-side proxies
and server-side proxies.
Distributed - Broker
Interactive Systems
• Model View Controller
The Model-View-Controller pattern (MVC) (divides an interactive application into three
components.
The model contains the core functionality and data.
Views display information to the user.
Controllers handle user input.
Views and controllers together comprise the user interface. A change-propagation
mechanism ensures consistency between the user interface and the model.

Eg: Small talk and web applications

Interactive Systems
• Model View Controller

• Advantages
• Multiple views for same model
• Synchronized views
• Pluggable views and controllers
• Framework potential
• Disadvantages
• Increased complexity
• Excessive number of updates
• Closely connected view and controller
• Inefficient data access in view: multiple calls
Interactive Systems
• Presentation Abstraction Control
The Presentation-Abstraction-Control pattern (PAC) defines a structure for interactive software
systems in the form of a hierarchy of cooperating agents.
Every agent is responsible for a specific aspect of the application's functionality and consists of three
components: presentation, abstraction, and control.
This subdivision separates the human-computer interaction aspects of the agent from its functional
core and its communication with other agents.

Eg: AI agents
Interactive systems
• Presentation-Abstraction-Control
The main responsibility of the top-level PAC
agent is to provide the global data model of the
software. This is maintained in the abstraction
component of the top-level agent.
The control component of the top-level PAC
agent:
• Allow lower level to make use of services
of top level
• Coordinate hierarchy of PAC agents
• Maintains information about the
interaction of the user with the system
Microkernel
• The Microkernel architectural pattern applies to software systems that must be able to
adapt to changing system requirements.
• It separates a minimal functional core from extended functionality and customer-specific
parts.
• The microkernel also serves as a socket for plugging in these extensions and
coordinating their collaboration.

Advantages
Scalability, Reliability, Transparency
Disadvantages
Performance, Complexity
Microkernel - Virtualization

● Virtualization is a technology to run multiple virtual machines(VM) on the same

hardware

● VM is an efficient, isolated duplicate of the real machine

● The software layer that creates the virtual environment is called a Virtual Machine

Monitor (VMM) or Hypervisor

23
Microkernel - Types in virtualization
VM1

VM1 VM1
App App

App App App App Guest OS

Guest OS Guest OS
Type II
App App
Hypervisor
Type I Hypervisor Host OS

Hardware Hardware

● Hosted Hypervisor
● baremetal
● Eg: VMware workstation,
● Eg: Xen, Microkernel based
Oracle Virtual Box, Microsoft
virtual PC
24