Software Architecture and

Design Pattern
Patterns and Software Architecture : Basics
• Patterns are an important vehicle for constructing high-quality
software architectures.
• However, several other techniques, methods, and processes for
software architecture already exist.
• How do patterns build on these techniques, methods, and processes,
and how do patterns complement them?
• Do patterns even define the state of the art in software architecture?
• In this chapter we discuss how patterns are integrated into the larger
field of software architecture.
Patterns and Software Architecture : Introduction
Some important aspects related to the discipline of software architecture

Software Architecture
Component
Relationship
View
Functional Property
Non-functional Property
Software Design
Patterns and Software Architecture : Introduction
Software Architecture:
A software architecture is a description of the subsystems and
components of a software system and the relationships between
them.
Subsystems and components are typically specified in different views
to show the relevant functional and non-functional properties of a
software system.
The software architecture of a system is an artifact. It is the result of
the software design activity.
Patterns and Software Architecture : Introduction
Component:
A component is an encapsulated part of a software system.
A component has an interface.
Components serve as the building blocks for the structure of a
system.
At a programming-language level, components may be represented
as modules, classes, objects or a set of related functions.
Patterns and Software Architecture : Introduction
Component:
The following figure shows three different components
Patterns and Software Architecture : Introduction
Component:
three different kinds of components, called elements:
• Processing elements : supply transformations of the data elements
that contain the information that is transformed
• Data elements
• Connecting elements : which at any time may be either processing
elements, data elements or both - constitute the 'glue' that holds the
different pieces together.
Patterns and Software Architecture : Introduction
Component:
Another categorization of components developed for the object
oriented programming paradigm is as follows:
• Controller components
• Coordinator components
• Interface components
• Service provider components
• Information holder components
• Structuring components
Patterns and Software Architecture : Introduction
Relationship:
A relationship denotes a connection between components.
A relationship may be static or dynamic.
Static relationships show directly in source code. They deal with the placement
of components within an architecture.
Dynamic relationships deal with temporal connections and dynamic
Interaction between components. They may not be easily visible from the
static structure of source code
• Aggregation and inheritance are examples of static relationships.
• Object creation, communication between objects, and data transfer are usually
dynamic relationships.
Patterns and Software Architecture : Introduction
Relationship:
The following figure shows three static relationships in OMT notation
Patterns and Software Architecture : Introduction
View:
• A view represents a partial aspect of a software architecture that shows
specific properties of a software system
• Examples of views are the state view of a component, or the
communication or data flow views of the relationships between
components
Patterns and Software Architecture : Introduction
View:
[SNH95] propose describing software architectures by taking the following
four different views:
• Conceptual architecture: components, connectors.. ..
• Module architecture: subsystems, modules, exports, imports..,.
• Code architecture: files, directories. libraries, includes ...
• Execution architecture: tasks, threads, processes ...
Patterns and Software Architecture : Introduction
View:
A similar approach is taken in [Kru951]. Four different views-- enhanced
by selected use case describe the software architecture.
• Logical view: the design's object model, or a corresponding model such
as an entity relationship diagram.
• Process view: concurrency and synchronization aspects.
• Physical view: the mapping of the software onto the hardware and its
distributed aspects.
• Development view: the software's static organization in its development
environment.
Patterns and Software Architecture : Introduction
Functional and Non-functional Properties:
• A functional property deals with a particular aspect of a system's
functionality, and is usually related to a specified functional requirement.
• A functional property may either be made directly visible to users of an
application by means of a particular function, or it may represent aspects
of its implementation, such as the algorithm used to compute the
function.
Patterns and Software Architecture : Introduction
Functional and Non-functional Properties:
• A non-functional property denotes a feature of a system that is not
covered, by its functional description.
• A non-functional property typically addresses aspects related to the
reliability, compatibility, cost, ease of use, maintenance or development
of a software system.
Patterns and Software Architecture : Introduction
Functional and Non-functional Properties:
Non-functional Properties of Software Architecture
we discuss the following non-functional properties at length:
• Changeability
• Interoperability
• Reliability
• Testability
• Reusability
• Efficiency
Patterns and Software Architecture : Introduction
Software Design :
• Software design is the activity performed by a software developer that
results in the software architecture of a system.
• It is concerned with specifying the components of a software system and
the relationships between them within given functional and non-
functional properties
Patterns in Software Architecture
Methodologies
Software Processes
Architectural Styles
Frameworks
Patterns in Software Architecture : Methodologies
A common question asked about patterns is how they relate to existing
analysis and design methods
• Methodologies provide many useful steps and guidelines for
constructing high-quality software.
• The implementation sections of our patterns loosely follow these steps,
adapted to the needs of the specific problems the patterns address.
• In addition, these methods define an overall process for software
development that you can adapt and extend to integrate your use of
patterns.
Patterns in Software Architecture : Software
Processes
A defined process has its benefits, but becomes a liability when it causes
organizational overheads or enforces a way of working that doesn't fit
your project's goals
Strict methodologies like the waterfall model can hinder software
architecture by preventing iterative improvements.
Flexible, incremental approaches align better with dynamic software
development needs.
Design patterns enhance software architecture by providing reusable
solutions and improving design stability.
Architectural patterns are used early in development, followed by design
patterns and implementation-level idioms.
Patterns in Software Architecture : Architectural
Styles
• An architectural style defines a family of software systems in terms of
their structural organization.
• An architectural style expresses components and the relationships
between them, with the constraints of their application, and the
associated composition and design rules for their construction
• Generally speaking, an architectural style expresses a particular kind of
fundamental structure for a software system together with an associated
method that specifies how to construct it
Patterns in Software Architecture : Architectural
Styles
Example Multi-phase architectural style
The multi-phase architectural style consists of processing elements and
data elements that are exchanged between processing elements

• Processing elements: lexer, parser, semantor, optimizer, code generator.

• Data elements: characters, tokens, phrases, correlated phrases,
annotated phrases, object code.
If the multi-phase architectural style is organized sequentially, it also uses
the following connecting elements:
• Connecting elements: procedure calls and parameters
Patterns in Software Architecture : Architectural
Styles
• The form of an architectural style is expressed by weighted properties
and relationships among its architectural elements
• Architectural styles are very similar to our architectural patterns
Patterns in Software Architecture : Architectural
Styles
Architectural styles differ from patterns in several important respects:
Architectural styles provide high-level structural frameworks for
applications, independent of specific design contexts.
In contrast, patterns for software architecture address recurring design
problems at various scales, from overarching structures to detailed
implementation.
Patterns are more problem-oriented, offering solutions tailored to
specific contexts, whereas architectural styles focus on abstract
techniques.
Patterns also depend on interactions with other patterns at different
scales, forming interconnected hierarchies.
Patterns in Software Architecture : Frameworks
A framework is a partially complete software (sub-) system that is
intended to be instantiated.
It defines the architecture for a family of (sub-) systems and provides the
basic building blocks to create them.
It also defines the places where adaptations for specific functionality
should be made.
In an object-oriented environment a framework consists of abstract and
concrete classes.
Patterns in Software Architecture : Frameworks
• The instantiation of a framework involves composing and subclassing the
existing classes.
• A framework for applications in a specific domain is called an application
framework.
Enabling Techniques for Software Architecture
• The construction of software is based on several fundamental principles.
We call these principles enabling techniques, since the principles
involved have become blurred over time
• All enabling techniques are independent of a specific software
development method, and most of them have been known for years
Enabling Techniques for Software Architecture
Most important enabling techniques for software architecture:
• Abstraction
• Encapsulation
• Information Hiding
• Modularization
• Separation of Concerns
• Coupling and Cohesion
• Sufficiency, Completeness and Primitiveness
• Separation of Policy and implementation
• Separation of Interface and implementation
• single Point of Reference
• Divide-and-Conquer
Enabling Techniques for Software Architecture
Abstraction :
• Grady Booch defines abstraction as The essential characteristics of an
object that distinguish It from all other kinds of objects and thus provide
crisply defined conceptual boundaries relaUve to the perspective of the
viewer
Enabling Techniques for Software Architecture
Encapsulation :
• Encapsulation deals with grouping the elements of an abstraction that
constitute its structure and behavior, and with separating different
abstractions from each other.
• Encapsulation provides explicit barriers between abstractions
• Encapsulation fosters non-functional properties like changeability and
reusability
Enabling Techniques for Software Architecture
Information Hiding
• Information hiding involves concealing the details of a component's
implementation from its clients, to handle system complexity better and
to minimize coupling between components
• Any details of a component that clients do not need to know in order to
use it properly should be hidden by the component
• The principle of encapsulation is often used as a way to achieve
information hiding.
• Information hiding can also be achieved using the principle of separation
of interface and implementation
Enabling Techniques for Software Architecture
Modularization

• Decomposition of a software system and with its grouping into

subsystems and components.
• The main objective of modularization is to handle system complexity by
introducing well-defined and documented boundaries within a program.
• Modules serve as physical containers for functionalities or responsibilities
of an application
Enabling Techniques for Software Architecture
Separation of Concerns
• Different or unrelated responsibilities should be separated from each
other within a software system, for example by attaching them to
different components.
• Collaborating components that contribute to the solution of a specific
task should be separated from components that are involved in the
computation of other tasks
Enabling Techniques for Software Architecture
Coupling and Cohesion
• Coupling focuses on inter-module aspects, whereas cohesion emphasizes
intra-module characteristics
• Coupling is the measure of the strength of association established by a
connection from one module to another.
• Strong coupling complicates a system, since a module is harder to
understand, change, or to correct if it is highly interrelated with other
modules
• Cohesion measures the degree of connectivity between the functions
and elements of a single module
Enabling Techniques for Software Architecture
Coupling and Cohesion
• There are several forms of cohesion.
• The most desirable form is functional cohesion, in which the elements of
a module or component 'all work together to provide some well bounded
behavior' [Boo94].
• The worst form is coincidental cohesion, in which entirely unrelated
abstractions are thrown into the same module.
• Other types of cohesion-logical cohesion, temporal cohesion, procedural
cohesion, communicational cohesion, sequential cohesion and informal
cohesion
Enabling Techniques for Software Architecture
Sufficiency, Completeness and Primitiveness
[Boo941 states that 'Every component of a software system should be
sufficient, complete, and primitive'.
• 'Sufficient' means that the component should capture those
characteristics of an abstraction that are necessary to permit a
meaningful and efficient interaction with the component.
• 'Completeness' means that a component should capture all relevant
characteristics of its abstraction.
• By 'primitiveness'. Booch means that all the operations a component can
perform can be implemented easily
Enabling Techniques for Software Architecture
Separation of Policy and implementation
• A component of a software system should deal with policy or
implementation, but not both:
• A policy component deals with context-sensitive decisions, knowledge
about the semantics and interpretation of information, the assembly of
many disjoint computations into a result or the selection of parameter
values
• An implementation component deals with the execution of a fully
specified algorithm in which no context-sensitive decisions have to be
made
Enabling Techniques for Software Architecture
Separation of Interface and implementation
Any component should consist of two parts:
• An interface part that defines the functionality provided by the
component and specifies how to use it. This interface is accessible by the
clients of the component. An exported interface of this type usually
consists of function signatures.
• An implementation part that includes the actual code for the
functionality provided by the component.
• The implementation part may also comprise additional functions and
data structures that are only used internally to the component.
• The implementation part is not accessible by the component's clients.
Enabling Techniques for Software Architecture
Separation of Interface and implementation
• The main objective of this principle is to protect a component's clients
from its implementation details, and only to provide clients with the
component's interface specification and guidelines for use
• Separation of interface and implementation is, like encapsulation, a
technique to achieve information hiding, the principle that states that 'A
client should only know what it needs to know
• Separation of interface and implementation also supports changeability-
a component is much easier to change if its interface is separated from
its Implementation
Enabling Techniques for Software Architecture
single Point of Reference
• Any item within a software system should be declared and defined only
once.
• The main objective of this principle is to avoid problems of inconsistency.
Enabling Techniques for Software Architecture
Divide-and-Conquer

• Divides a task or component into smaller parts that can be designed

independently (Merge Sort)
• Divide-and-Conquer also often provides a way to realize the principle of
separation of concerns
Non-functional Properties of Software Architecture
Non-functional properties of a software system have a great impact on its
development and maintenance
Most important non-functional properties of software architecture in relation to
patterns

• Changeability
• Interoperability
• Efficiency
• Reliability
• Testability
• Reusability
Non-functional Properties of Software Architecture
Changeability
• To reduce maintenance costs and the workload involved in changing an
application, it is important to prepare its architecture for modification
and evolution.
Parnas lists two reasons why software ages:
• Lack of movement-software ages if it is not frequently updated.
• Ignorant surgery-changes made by people who do not understand the
original design gradually destroy the architecture.
Non-functional Properties of Software Architecture
Changeability
We consider that changeability has four aspects
• Maintainability : A software architecture that is well-prepared for
maintainability tends to localize changes and minimize their side effects on
other components
• Extensibility : structure that allows you to exchange components without
affecting their clients
• Restructuring : allow you to configure components flexibly without affecting
major parts of their implementation.
• Portability: a software system needs to be organized in such a way that
dependencies on hardware, other software systems and environments are
factored out into special components such as system and user interface
libraries.
Non-functional Properties of Software Architecture
Interoperability : a software architecture must be designed to offer well-
defined access to externally-visible functionality and data structures
Non-functional Properties of Software Architecture
Efficiency
• Deals with the use of the resources available for the execution of
software, and how this impacts response times, throughput and storage
consumption
• Efficiency also plays a significant role in distributed software systems
Non-functional Properties of Software Architecture
Reliability: Deals with the general ability of a software system to
maintain its functionality, both in the face of application or system errors
and in situations of unexpected or incorrect usage
Fault tolerance: This aims at ensuring correct behavior in the went of
errors, and their internal 'repair', such as losing a connection to a remote
component in a distributed software system and subsequently
reconnecting to it.
Robustness: This deals with protecting an application against incorrect
usage and degenerate input, and keeping it in a defined state in the went
of unexpected errors
Non-functional Properties of Software Architecture
Testability : Software structures that support testability allow for better
fault detection and fixing, and also for temporary integration of debugging
code and debugging components
Non-functional Properties of Software Architecture
Reusability : It promises a reduction of both cost and development time
for software systems, as well as better software quality
Non-functional Properties of Software Architecture
Reusability has two major aspects-software development with reuse and
software development for reuse:
1. Software development with reuse means reusing existing components
and results from previous projects or commercial libraries, design
analyses, design specifications or code components
2. Software development for reuse focuses on producing components
that are potentially reusable in future projects as part of the current
software development
The Pattern Community
• Many software developers document patterns with which they are
familiar and share them with colleagues world-wide.
• Together they form a community that shares a common interest in
software patterns.
The Pattern Community : The Roots
• Christopher Alexander's pattern-based approach to design, developed
over two decades, introduced over 250 patterns in architecture and
urban planning. His work, using a Context-Problem-Solution structure,
influenced software design, despite some differences in application.
• Ward Cunningham and Kent Beck adapted Alexander's patterns to
software development, starting with user interface design patterns.
Cunningham focused on business systems, while Beck explored Smalltalk
idioms.
• Erich Gamma’s early work on object-oriented design patterns, outlined in
his 1991 thesis, laid the foundation for the "Gang of Four" book on
design patterns in software.
The Pattern Community : Leading Figures and their
Work
• The "Gang-of-Four" (Erich Gamma, Richard Helm, Ralph Johnson, and John
Vlissides) significantly influenced the acceptance of design patterns in software
engineering with their book *Design Patterns: Elements of Reusable Object-
Oriented Software*. Their work is foundational, and many patterns today build
on their ideas.

• James O. Coplien, another pattern expert, pioneered C++ idioms in his book
*Advanced C++ Programming Styles and Idioms* and is now focusing on
patterns for organizational structures and software projects.

• Douglas C. Schmidt is known for his work on patterns related to distributed

applications and high-speed networking, particularly through the ACE
framework.
The Pattern Community : Leading Figures and their
Work
• Robert Martin also contributed patterns for C++, which blend design patterns
and idioms, derived from practical applications.

• Peter Coad, a pioneer in patterns, published a book with around 200 patterns
focused on application domain analysis and object-oriented development.

• Wolfgang Pree categorized structural principles of design patterns into "meta-

patterns" and focused on framework development.

• Many other publications on patterns exist and more are expected in the future,
spanning papers, books, and conference proceedings.
The Pattern Community : The Community
• This pattern community recently found Its own forum, the PLOP (Pattern
Languages of Programming) conference
• PLoP also has a European arm, EuroPLoP, and its proceedings will also be
part of the series
The Pattern Community : The Community
PLoP and EuroPLoP differ from other conferences in the following respects:
• Focus on practicability. The conference looks for pattern descriptions of proven
solutions to problems, rather than on presenting the latest scientific results.
• Aggressive disregard of originality. Pattern authors do not need to be the original
developers of the solutions they describe.
• Non-anonymous review. Submissions are 'shepherded' rather than reviewed. The
'shepherd' contacts the authors of submitted papers and discusses the submissions
with them. The goal is to improve the paper such that it can be accepted for review at
the conference and suffer as little rejection as possible.
• Writer's workshops instead of presentations. All patterns are discussed In writer's
workshops made up of conference attendees. rather than being presented by their
authors in open forum.
• Careful editing. Authors get the chance to include the feedback from the writer's
workshops. and all patterns are copy-edited before they appear in the ha1
conference proceedings
The Pattern Community : The Community
To discuss patterns and pattern-related issues. the pattern community
offers several mailing lists and a World Wide Web page. The URL of the
pattern home page is:
The Pattern Community : The Community
• Most members of the pattern community work in the software industry,
and are software developers with experience in designing and building
large-scale applications.
• Academic members are mainly involved in industrial projects-they do not
just teach how to build software systems, they also do it.
• The pattern community is the only community in computer science that
is based on interest in a literal form, the pattern form for describing well-
proven knowledge.
• This brings people with different backgrounds and fields of expertise
together.