Software Architecture and

Design Pattern
Introduction
• Patterns help you build on the collective experience of skilled
software engineers.
• They capture existing, well-proven experience in software
development and help to promote good design practise.
• Every pattern deals with a specific, recurring problem in the design or
implementation of a software system.
Contents
• What is a pattern?
• What types of pattern are there?
• Why do we use patterns in software architecture?
• What does a pattern look like?
• How can we use patterns in our work?
What is a pattern?
Definition:
A particular recurring design problem that arises in specific design
contexts, and presents a well-proven generic scheme for its solution.
The solution scheme is specified by describing its constituent
components, their responsibilities and relationships, and the ways in
which they collaborate.
Definition in English…
• A re-usable solution to a recurring problem
• Tried and tested
• Consider the solution to be a template
• It can be adapted and personalized for the problem domain

• It Is a natural way of coping with any kind of problem or social

Interaction
Pattern categories
3 categories of patterns defined by Buschmann et al.
1. Architectural patterns
2. Design patterns
3. Idioms

But there’s more…

Analysis patterns (Martin Fowler)
Organizational patterns
Three categories of patterns
Architectural Patterns
A high-level structure for software systems
Contains a set of predefined sub-systems
Defines the responsibilities of each sub-system
Details the relationships between sub-systems
Also similar to ‘conceptual patterns’ which cover the application
domain (defined in Understanding and Using Patterns in Software
Development, Riehle & Zullighoven)
Three categories of patterns (cont)
Design Patterns
• Mid-level construct
• Implementation-independent
• Designed for ‘micro-architectures’ – somewhere between sub-system
and individual components
• Several classic design patterns described in Design patterns :
elements of reusable object-oriented software, Erich Gamma et al.
Three categories of patterns (cont)
Idioms
• Earliest form of software pattern
• Comparatively low-level
• Gives a guide for implementing the components and relationships of
the pattern
• Considers the pattern at a programming language level– Describes
the pattern using the constructs of the specific language
• Also similar to ‘programming patterns’ (Riehle & Zullighoven again)
Pattern format
A pattern description should contain the following
• Name
• Problem
• Context
• Forces
• Solution
• Examples
• Resulting context
• Rationale
• Related patterns
• Known uses
• A pictorial representation may also be included, as may an abstract
Pattern elements
• Name– Meaningful, concise
• Problem– A description of intent: goals and objectives of the pattern
• Context– The preconditions of the problem and solution– Where the
pattern is applicable
• Forces– Motivations and trade-offs to be made in the design and
implementation; may be conflicting– For example: maintainability,
security, efficiency…
Pattern elements (cont)
• Solution
• consists of static relationships and dynamic rules– Described by
pictures, diagrams, text– Contains implementation guidelines (and
what to avoid doing)
• Examples: To help the user understand its application more fully
• Resulting context:The consequences of applying the pattern–
Resolves which forces have been addressed
• Rationale– A justification of how and why the pattern works
Pattern elements (cont)
• Related patterns
• Known uses
Example Window Place

If the room contains no window which is a 'place", a

person in the room will be torn between two forces:
1. He wants to sit down and be comfortable.
2. He Is drawn toward the light.

Obviously. If the comfortable places--those places in

the room where you most want to sit-are away from
the windows. there is no way of overcoming this
conflict.. .
Therefore: In every room where you spend any length
of time during the day. make at least one window into
a "window place"
 Example Window Place
Each pattern is a three-part rule, which expresses a relation between a certain
context, a problem, and a solution.
As an element in the world, each pattern is a relationship between a certain
context, a certain system of forces which occurs repeatedly in that context,
and a certain spatial configuration which allows these forces to resolve
themselves.
As an element of language, a pattern is an instruction, which shows how this
spatial configuration can be used, over and over again, to resolve the given
system of forces, wherever the context makes it relevant.
The pattern is, in short, at the same time a thing, which happens in the world,
and the rule which tells us how to create that thing. and when we must create
it.
Model-View-Controller

User interfaces are prone to change requests

For example, when extending the functionality of an application,
menus have to be modified to access new functions, and user
interfaces may have to be adapted for specific customers
Building a system with the required flexibility will be expensive and
error-prone if the user interface is tightly interwoven with the
functional core.
This can result in the development and maintenance of several
substantially different software systems, one for each user interface
implementation.
Model-View-Controller

When developing such an interactive software system, you have to

consider two aspects:
1. Changes to the user interface should be easy, and possible at run-
time.
2. Adapting or porting the user interface should not impact code in
the functional core of the application.
Model-View-Controller

To solve the problem, divide an interactive application into three areas:

processing, output and input:
The model component encapsulates core data and functionality. The
model is independent of specific output representations or input
behavior.
View components display information to the user. A view obtains the
data it displays from the model. There can be multiple views of the model.
Each view has an associated controller component. Controllers receive
input, usually as events that denote mouse movement, activation of
mouse buttons or keyboard input. Events are translated to service
requests, which are sent either to the model or to the view.
The user interacts with the system solely via controllers.
Model-View-Controller

The separation of the model from the view and controller components allows multiple
views of the same model.
Model-View-Controller
Model-View-Controller
 Change a subsystem of the application without causing major effects to
other subsystems.
 For example, you can change from a non-graphical to a graphical user
interface without modifying the model subsystem.
Model-View-Controller
We can derive several properties of patterns for software architecture

A pattern addresses a recurring design problem that arises in specific

design situations, and presents a solution to it.

 Supporting variability in user interfaces : when developing software systems -with

human-computer interaction
 Strict separation of responsibilities: the core functionality of the application is
separated from its user interface
Model-View-Controller
Patterns document existing, well-proven design experience (not invented or
created artificially)
 Provide a means to reuse the design knowledge gained by experienced practitioners
 Can apply them immediately to design problems without having to rediscover them
 The Model-View-Controller pattern, for example, presents experience gained over
many years of developing interactive systems.
 Many well-known applications already apply the Model- View-Controller pattern-it is
the classical architecture for many Smalltalk applications, and under several application
frameworks such as MacApp
Model-View-Controller
Patterns identify and specify abstractions that are above the level of single classes and
instances, or of components
Pattern describes several components, classes or objects, and details their responsibilities
and relationships, as well as their cooperation

Patterns provide a common vocabulary and understanding for design principles

Facilitate effective discussion of design problems and their solutions,
remove the need to n a solution to a particular problem with a lengthy and
complicated description
use a pattern name, and explain which parts of a solution correspond to which
components of the pattern, or to which relationships between them

Model-View-Controller and the associated pattern has been to the Smalltalk community
since the early '80s, and is used by many software engineers
Model-View-Controller
Patterns are a means of documenting software architectures
can describe the vision you have in mind when designing a software system
helps others to avoid violating this vision when extending and modifying the original
architecture
extend a new function: keep core functionality separate from user input and
information display

Patterns support the construction of software with defined properties

provide a skeleton of functional behavior and therefore help to implement the
functionality of your application
patterns exist for maintaining consistency between cooperating components and for
providing transparent peer-to-peer inter-process communication
patterns explicitly address non- functional requirements for software
systems(changeability, reliability, testability or reusability)
Model-View-Controller
Patterns help you build complex and heterogeneous software architectures
pattern provides a predefined set of components, roles and relationships between them
Patterns 'act as building-blocks for constructing more complex designs
supports the speed q d the quality of your design

Patterns help you to manage software complexity

pattern describes a proven way to handle the problem it addresses
the kinds of components needed, their roles, the details that should be hidden, the
abstractions that should be visible, and how everything works
A pattern for software architecture describes a particular recurring design problem that
arises in specific design contexts, and presents a well-proven generic scheme for its
solution.
The solution scheme is specified by describing its constituent components, their
responsibilities and relationships, and the ways in which they collaborate.
What Makes a Pattern?
Three-part schema that underlies every pattern
 Context: a situation giving rise to a problem.
 Problem: the recurring problem arising in that context.
 Solution: a proven resolution of the problem.

Context :
 Describing situations in which the problem occurs
 Specifying the correct context for a pattern is difficult
 A more pragmatic approach is to list all known situations where a problem that is
addressed by a particular pattern can occur
What Makes a Pattern?
Problem:
 Description schema describes the problem that arises repeatedly in the given
context
 Requirements the solution must fulfil-for example, that peer-to- peer inter-process
communication must be efficient.
 Constraints you must consider-for example, that inter-process communication must
follow a particular protocol.
 Desirable properties the solution should have-for changing software should be easy.

The Model-View-Controller pattern from the previous section specifies two forces:
1. It should be easy to modify the user interface,
2. But the functional core of the software should not be affected by its modification.
What Makes a Pattern?
Solution :
 Shows how to solve the recurring problem, or better, how to balance the forces
associated with it
 Every pattern specifies a certain structure, a spatial configuration of elements
Pattern Categories
Patterns into three categories:
1. Architectural patterns
2. Design patterns
3. Idioms
Architectural Patterns
 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

 Architectural patterns are templates for concrete software architectures

 Specify the system-wide structural properties of an application, and have an impact
on the architecture of its sub- systems
Design Patterns
 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

 Used in medium-scale patterns

 Independent of a particular programming language or programming paradigm
 Many design patterns provide structures for decomposing more complex services
or components
Design Patterns :Observer or Publisher-Subscriber
Name : Observer or Publisher-Subscriber
Context : A component uses data or information provided by another component
Problem: Changing the internal state of a component may introduce inconsistencies
between cooperating components

Two forces are associated with this problem:

1. The components should be loosely coupled-the information provider should not
depend on details of its collaborators.
2. The components that depend on the information provider are not known a priori.
Design Patterns :Observer or Publisher-Subscriber
Solution:
 Implement a change-propagation mechanism between the information provider-the
subject-and the components dependent on it-the observers
 Whenever the subject changes its state, it starts the change-propagation mechanism
to restore consistency with all registered observers
 To implement change propagation-the passing of data and state information from the
subject to the observers-you can use a pull-model, a push-model, or a combination of
both
Idioms
 Idioms deal with the implementation of particular design issues
 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.

Idioms represent the lowest-level patterns

Address aspects of both design and implementation
Most idioms are language-specific
Idioms : Counted Body
Name: Counted Body
Context: The interface of a class is separated from its implementation. A handle class
presents the class interface to the user. The other class embodies the implementation,
and is called body. The handle forwards member function invocations to the body

Problem: Assignment in C++ is defined recursively as member-by-member assignment

Smalltalk, it would be more efficient and more in the spirit of the language

Copying of bodies is expensive in both storage requirements and processing time.

Copying can be avoided by using pointers and references, but these leave a problem-who
is responsible for cleaning up the object? They also leave a user-visible distinction
between built-in types and user-defined types.
Sharing bodies on assignment is semantically incorrect if the shared body is modified
through one of the handles.
Idioms : Counted Body

Solution:
 A reference count is added to the body class to facilitate memory management.
 It is the responsibility of any operation that modifies the state of the body to break the
sharing of the body by making its own copy, decrementing the reference count of the
original body
Integration with Software Development
Architectural patterns can be used at the beginning of coarse-grained design, design
patterns during the whole design phase, and idioms during the implementation phase
Relationships between Patterns
A pattern solves a particular problem, but its application may raise new problems
Single components or relationships inside a particular pattern may therefore be
described by smaller patterns, all of them integrated by the larger pattern in which they
are contained
Relationships between Patterns
Example Refinement of the Model-View-Controller pattern
The Model-View-Controller pattern separates core functionality from human-computer
interaction to provide adaptable user interfaces  applying this pattern introduces a
new problem
 Views, and sometimes even controllers, depend on the state of the model
 The consistency between them must be maintained
 we must not lose the ability to change the user interface

Each pattern depends on the smaller patterns it contains and on the larger
patterns in which it is contained

A pattern may also be a variant of another

Relationships between Patterns
Example The Document-View variant of the Model-View-Controller pattern
 Interactive text editor using the Model-View-Controller pattern
 It is hard to separate controller functionality from view functionality

 In a strict Model-View-Controller structure, the controller must either implement this

'view-like' behavior by itself, or must cooperate with the view in which the selected
text appears

 In such a situation it is better to apply the Document-View variant of the Model-View-

Controller pattern, which unifies the view and controller functionality in a single
component, the view of the Document-View pattern
Relationships between Patterns
Example Transparent peer-to-peer inter-process communication
To develop a distributed application with high performance peer -to-peer inter -process
communication
The following forces must be balanced:
 The inter-process communication must be efficient. Spending time searching for the
location of remote servers is undesirable.
 Independence from a particular inter-process communication mechanism is desirable.
The mechanism must be exchangeable without affecting clients or servers.
 Clients should not be aware of, or dependent on, the name and location of their
servers. Instead, they should communicate with each other as if they were in the same
process.
Relationships between Patterns

 problem cannot be solved by any single pattern in isolation

 two patterns in combination can achieve this

 Forwarder- Receiver pattern resolves the first and second force

 general interface for sending and receiving messages and data across process
boundaries.
 The pattern hides the details of the concrete inter-process communication mechanism
Relationships between Patterns
Example Transparent peer-to-peer inter-process communication
The Proxy pattern (263) resolves the third force
 client communicates with a representative of the server that is located in the same
process
Relationships between Patterns
Example Transparent peer-to-peer inter-process communication
All the three kinds of relationship-refinement, variants and combination-help in using
patterns effectively.
 Refinement supports the implementation of a pattern,
 combination helps you compose complex design structures, and
 variants help when selecting the right pattern in a given design situation
Patterns Description
 Patterns must be presented in an appropriate form if we are to understand and
discuss them
 A good description also provides us with all the details necessary to implement a
pattern, and to consider the consequences of its application
 Patterns should also be described uniformly
Patterns Description
Patterns Description
Patterns and Software Architecture
 An important criterion for the success of patterns is how well they meet the
objectives of software engineering.
 Patterns must support the development, maintenance and evolution of complex,
large-scale systems

Patterns as mental building- blocks

 Patterns therefore address an important objective of software architecture-the
construction of specific software architectures with defined properties

 Consider the Model-View-Controller pattern again. It provides a structure that

supports the tailoring of the user interface of an interactive application
Patterns and Software Architecture
Constructing Heterogeneous Architectures

 A single pattern cannot enable the detailed construction of a complete software

architecture-it just helps you to design one aspect of your application
 To meet the needs of software architecture 'in the large' we need a rich set of
patterns that must cover many different design problems
 When applying one pattern, you want to know which other patterns can help refine
the structure it introduces. You also want to know which other patterns you can
combine with it
 To use patterns effectively, we therefore need to organize them into pattern systems.
 A pattern system describes patterns uniformly, classifies them, and most importantly,
shows how they are interwoven with each other.
 Pattern systems also help you to find the right pattern to solve a problem or to
identify alternative solutions to it
Patterns versus Methods
A good pattern description also includes guidelines for its implementation that you can
consider as a micro-method for creating the solution to a specific problem
Implementing Patterns
 Many current software patterns have a distinctly object-oriented flavor. It is tempting
to conclude that the only way we can implement a pattern effectively is in an object-
oriented programming language. However, we think such conclusions are false

 At the design level, most patterns only require certain abstraction facilities of a
programming language, such as modules or data abstraction.
 You can therefore implement patterns with almost any programming paradigm and in
almost any programming language

 In conclusion, we can say that there is no single paradigm or language for

implementing patterns