UNIT-1 Introduction To Software Architecture

UNIT-1
INTRODUCTION TO SOFTWARE ARCHITECTURE
Contents
 What is Software Architecture?
 The Goals of Architecture
 The Principles of Architecture Design
What is Software Architecture?

Software application architecture is the process of defining a structured solution
that meets all of the technical and operational requirements, while optimizing
common quality attributes such as performance, security, and manageability. It
involves a series of decisions based on a wide range of factors, and each of these
decisions can have considerable impact on the quality, performance,
maintainability, and overall success of the application.
Their definition is:
“Software architecture encompasses the set of significant decisions about the
organization of a software system including the selection of the structural elements
and their interfaces by which the system is composed; behavior as specified in
collaboration among those elements; composition of these structural and behavioral
elements into larger subsystems; and an architectural style that guides this
organization. Software architecture also involves functionality, usability, resilience,
performance, reuse, comprehensibility, economic and technology constraints,
tradeoffs and aesthetic concerns.”
In Patterns of Enterprise Application Architecture, Martin Fowler outlines some
common recurring themes when explaining architecture. He identifies these themes
as:
“The highest-level breakdown of a system into its parts; the decisions that are hard
to change; there are multiple architectures in a system; what is architecturally
significant can change over a system's lifetime; and, in the end, architecture boils
down to whatever the important stuff is.”
Bass, Clements, and Kazman define architecture as follows:
“The software architecture of a program or computing system is the structure or
structures of the system, which comprise software elements, the externally visible
Software Architecture & Design Patterns 1 Dept of CSE, SVColleges, Tirupathi

properties of those elements, and the relationships among them. Architecture is
concerned with the public side of interfaces; private details of elements—details
having to do solely with internal implementation—are not architectural.”
Why is Architecture Important?

Like any other complex structure, software must be built on a solid foundation.
Failing to consider key scenarios, failing to design for common problems, or failing
to appreciate the long term consequences of key decisions can put your application
at risk. Modern tools and platforms help to simplify the task of building applications,
but they do not replace the need to design your application carefully, based on your
specific scenarios and requirements. The risks exposed by poor architecture include
software that is unstable, is unable to support existing or future business
requirements, or is difficult to deploy or manage in a production environment.
Systems should be designed with consideration for the user, the system (the IT
infrastructure), and the business goals. For each of these areas, you should outline
key scenarios and identify important quality attributes (for example, reliability or
scalability) and key areas of satisfaction and dissatisfaction. Where possible,
develop and consider metrics that measure success in each of these areas.
Figure 1
User, business, and system goals
Tradeoffs are likely, and a balance must often be found between competing
requirements across these three areas. For example, the overall user experience of
the solution is very often a function of the business and the IT infrastructure, and

changes in one or the other can significantly affect the resulting user experience.
Similarly, changes in the user experience requirements can have significant impact
on the business and IT infrastructure requirements. Performance might be a major
user and business goal, but the system administrator may not be able to invest in
the hardware required to meet that goal 100 percent of the time. A balance point
might be to meet the goal only 80 percent of the time.
Architecture focuses on how the major elements and components within an
application are used by, or interact with, other major elements and components
within the application. The selection of data structures and algorithms or the
implementation details of individual components are design concerns. Architecture
and design concerns very often overlap. Rather than use hard and fast rules to
distinguish between architecture and design, it makes sense to combine these two
areas. In some cases, decisions are clearly more architectural in nature. In other
cases, the decisions are more about design, and how they help you to realize that
architecture.
By following the processes described in this guide, and using the information it
contains, you will be able to construct architectural solutions that address all of the
relevant concerns, can be deployed on your chosen infrastructure, and provide
results that meet the original aims and objectives.
Consider the following high level concerns when thinking about software
architecture:
 How will the users be using the application?

 How will the application be deployed into production and managed?
 What are the quality attribute requirements for the application, such as
security, performance, concurrency, internationalization, and configuration?
 How can the application be designed to be flexible and maintainable over
time?
 What are the architectural trends that might impact your application now or
after it has been deployed?
The Goals of Architecture:

Application architecture seeks to build a bridge between business requirements and
technical requirements by understanding use cases, and then finding ways to

implement those use cases in the software. The goal of architecture is to identify
the requirements that affect the structure of the application. Good architecture
reduces the business risks associated with building a technical solution. A good
design is sufficiently flexible to be able to handle the natural drift that will occur
over time in hardware and software technology, as well as in user scenarios and
requirements. An architect must consider the overall effect of design decisions, the
inherent tradeoffs between quality attributes (such as performance and security),
and the tradeoffs required to address user, system, and business requirements.
Keep in mind that the architecture should:
 Expose the structure of the system but hide the implementation details.
 Realize all of the use cases and scenarios.
 Try to address the requirements of various stakeholders.
 Handle both functional and quality requirements.
The Architectural Landscape

It is important to understand the key forces that are shaping architectural decisions
today, and which will change how architectural decisions are made in the future.
These key forces are driven by user demand, as well as by business demand for
faster results, better support for varying work styles and workflows, and improved
adaptability of software design.
Consider the following key trends:
 User empowerment. A design that supports user empowerment is flexible,

configurable, and focused on the user experience. Design your application
with appropriate levels of user personalization and options in mind. Allow the
user to define how they interact with your application instead of dictating to
them, but do not overload them with unnecessary options and settings that
can lead to confusion. Understand the key scenarios and make them as
simple as possible; make it easy to find information and use the application.
 Market maturity. Take advantage of market maturity by taking advantage
of existing platform and technology options. Build on higher level application
frameworks where it makes sense, so that you can focus on what is uniquely
valuable in your application rather than recreating something that already

exists and can be reused. Use patterns that provide rich sources of proven
solutions for common problems.
 Flexible design. Increasingly, flexible designs take advantage of loose
coupling to allow reuse and to improve maintainability. Pluggable designs
allow you to provide post-deployment extensibility. You can also take
advantage of service orientation techniques such as SOA to provide
interoperability with other systems.
 Future trends. When building your architecture, understand the future
trends that might affect your design after deployment. For example, consider
trends in rich UI and media, composition models such as mashups,
increasing network bandwidth and availability, increasing use of mobile
devices, continued improvement in hardware performance, interest in
community and personal publishing models, the rise of cloud-based
computing, and remote operation.
The Principles of Architecture Design

Current thinking on architecture assumes that your design will evolve over time and
that you cannot know everything you need to know up front in order to fully
architect your system. Your design will generally need to evolve during the
implementation stages of the application as you learn more, and as you test the
design against real world requirements. Create your architecture with this evolution
in mind so that it will be able to adapt to requirements that are not fully known at
the start of the design process.
Consider the following questions as you create an architectural design
 What are the foundational parts of the architecture that represent the
greatest risk if you get them wrong?
 What are the parts of the architecture that are most likely to change, or
whose design you can delay until later with little impact?
 What are your key assumptions, and how will you test them?
 What conditions may require you to refactor the design?
Do not attempt to over engineer the architecture, and do not make assumptions
that you cannot verify. Instead, keep your options open for future change. There

will be aspects of your design that you must fix early in the process, which may
represent significant cost if redesign is required. Identify these areas quickly and
invest the time necessary to get them right.
Key Architecture Principles
Consider the following key principles when designing your architecture:
 Build to change instead of building to last. Consider how the application

may need to change over time to address new requirements and challenges,
and build in the flexibility to support this.
 Model to analyze and reduce risk. Use design tools, modeling systems
such as Unified Modeling Language (UML), and visualizations where
appropriate to help you capture requirements and architectural and design
decisions, and to analyze their impact. However, do not formalize the model
to the extent that it suppresses the capability to iterate and adapt the design
easily.
 Use models and visualizations as a communication and collaboration
tool. Efficient communication of the design, the decisions you make, and
ongoing changes to the design, is critical to good architecture. Use models,
views, and other visualizations of the architecture to communicate and share
your design efficiently with all the stakeholders, and to enable rapid
communication of changes to the design.
 Identify key engineering decisions. Use the information in this guide to
understand the key engineering decisions and the areas where mistakes are
most often made. Invest in getting these key decisions right the first time so
that the design is more flexible and less likely to be broken by changes.
Consider using an incremental and iterative approach to refining your architecture.

Start with a baseline architecture to get the big picture right, and then evolve
candidate architectures as you iteratively test and improve your architecture. Do
not try to get it all right the first time—design just as much as you can in order to
start testing the design against requirements and assumptions. Iteratively add
details to the design over multiple passes to make sure that you get the big
decisions right first, and then focus on the details. A common pitfall is to dive into
the details too quickly and get the big decisions wrong by making incorrect

assumptions, or by failing to evaluate your architecture effectively. When testing
your architecture, consider the following questions:
 What assumptions have I made in this architecture?

 What explicit or implied requirements is this architecture meeting?
 What are the key risks with this architectural approach?
 What countermeasures are in place to mitigate key risks?
 In what ways is this architecture an improvement over the baseline or the
last candidate architecture?
Key Principles of Software Architecture:
For information about the incremental and iterative approach to architecture,

baseline and candidate architectures, and representing and communicating the
design.
Architectural pattern
An architectural pattern is a general, reusable solution to a commonly occurring
problem in software architecture within a given context. Architectural patterns are
similar to software design pattern but have a broader scope. The architectural patterns
address various issues in software engineering, such as computer hadware performance
limitations, high availability and minimization of a business risk. Some architectural
patterns have been implemented within software frameworks.
Contents
 1.Definition
 2.Architectural style
 3.Examples
Architectural style
Following traditional building architecture, a 'software architectural style' is a

specific method of construction, characterized by the features that make it notable"
(Architectural style). "An architectural style defines: a family of systems in terms of
a pattern of structural organization; a vocabulary of components and connectors,
with constraints on how they can be combined.

"An architectural pattern is a named collection of architectural design decisions that
are applicable in a given development context, constrain architectural design
decisions that are specific to a particular system within that context, and elicit
beneficial qualities in each resulting system.
Some treat architectural patterns and architectural styles as the same, some treat
styles as specializations of patterns. What they have in common is both patterns
and styles are idioms for architects to use, they "provide a common language"[5] or
"vocabulary"[4] with which to describe classes of systems.
The main difference is that a pattern can be seen as a solution to a problem, while
a style is more general and does not require a problem to solve for its appearance.
Here is a list of architecture patterns, and corresponding design

ptterns and solution patterns.
Architecture
Sub-Domain Solution Related
Pattern Design Patterns
Area Patterns Patterns
Name
 EAI
 Error
 Master
handling
 Change Data Data Hub
Capture  Job
 ETL (Data  Operation
scheduling
Extraction  Near Real- al Data
Time ETL  Data
Transforma Store
validation
tion &  Batch ETL (ODS)
Loading)  Slowly
 Data  Data Mart
Changing
Discovery  Data
Data Dimensions
Warehou
Integration/S Load
se
OA
 MFT
 One-Way
 Publish/subscri
 Synchronous
be
Request/Res
 Request/reply
 EAI/ESB ponse  SOA
 Message
 Basic
Exchange
Callback
Patterns
 Claim Check
 Transactio  Custom  ETL
Data n Data Applications
 EAI
Architecture Stores Databases
 SOA
(TDS/OLTP  Packaged

) Application
 Master Databases
Data Store
 Operationa
l Data
Store
 Data Mart
 Data
Warehouse
 Transactional
Reporting
Data Access
 Operational
Reporting  Real-Time
 Transactio  ETL
Data Access Dashboards
nal  EAI
 Analytical  In-Memory
Reporting  TDS
Business Reporting Analytics
 Operationa  Operation
Intelligence Data Access  Statistical
l Reporting al Data
 Analytical Analysis
 Analytical Store
Dashboard  Predictive
Reporting  Data Mart
Data Access analytics
 Operational
Dashboard
Data Access
 Data Mining
 Master Data
Replication  Change
 Master Data Data
Master data  Master Capture
Services
management Data Hub
 Master Data  EAI
Synchronizatio  STD
n
 Dimension  Modeling
al Data Standards
Data Modeling Modeling  Naming
 E-R Data Conventions
Modeling
Pipes and filters

very simple, yet powerful architecture, that is also very robust. It consists of any
number of components (filters) that transform or filter data, before passing it on via
connectors (pipes) to other components. The filters are all working at the same

time. The architecture is often used as a simple sequence, but it may also be used
for very complex structures.
The filter transforms or filters the data it receives via the pipes with which it is
connected. A filter can have any number of input pipes and any number of output
pipes.
The pipe is the connector that passes data from one filter to the next. It is a
directional stream of data that is usually implemented by a data buffer to store all
data, until the next filter has time to process it.
The pump or producer is the data source. It can be a static text file, or a keyboard
input device, continuously creating new data.
The sink or consumer is the data target. It can be another file, a database, or a
computer screen.
Examples
 Unix programs. The output of one program can be linked to the input of another
program.
 Compilers. The consecutive filters perform lexical analysis, parsing, semantic
analysis, and code generation.
Where does it come from?

The popularity of the architecture is mainly due to the Unix operating system. It
has become popular because Ken Thomson (who created Unix, together with
Dennis Ritchie) decided to limit the architecture to a linear pipeline. Using the
architecture at all was an idea of Doug McIlroy, their manager at Bell Labs at the
time (1972). Both filters (coroutines) and pipes (streams) were not new, but it is

not clear to me who designed the architecture of linking the coroutines by streams.
As far as I can see, the design was made by Doug McIlroy.
When should you use it?

This architecture is great if you have a lot of transformations to perform and you
need to be very flexible in using them, yet you want them to be robust.
How does it work?

The application links together all inputs and outputs of the filters by pipes, and then
spawns separate threads for each filter to run in.Here's an idea of the relationships
that can be created between the different filter processes, through pipes.
Object-Oriented Organization
Data structures and their associated operations are encapsulated in an abstract

data type (ADT) or object. The components of a system are instances of an ADT
and they interact through procedure (or method) calls an object is responsible for
preserving the integrity of its data structures and also these data structures are
hidden from other objects. Objects may operate concurrently or not obj methods
method calls.
Heterogeneous Architectures
The computing industry is approaching a formidable obstacle course where anyone

wishing to drive advances in computing technology must carefully negotiate several
key trade-offs. First, reducing power consumption is increasingly critical across all
segments of computing. Consumers want improved battery life, size, and weight for
their laptops, tablets, and smart phones. Likewise data center power demands and
cooling costs continue to rise.
At the same time, we demand constantly improving performance to enable

compelling new user experiences. We want to access our devices through more
natural interfaces (speech and gesture), and we want devices to manage ever-
expanding volumes of data (home movies, pictures, and a world of content
available in the cloud).To deliver these new user experiences, programmer
productivity is another essential element that must be delivered. It must be easy

for software developers to tap into new capabilities by using familiar, powerful
programming models.Finally, it is increasingly important that software be supported
across a broad spectrum of devices. Developers cannot sustain today’s trend of re-
writing code for an ever expanding number of different platforms.To navigate this
complex set of requirements, the computer industry needs a different approach – a
more efficient approach to computer architecture. We need an approach that
promises to deliver improvement across all 4 of these vectors: power, performance,
programmability and portability.
Systems Integration
Large software systems are often integrated from pre-existing systems. The designer of
such a system must accommodate very different-often incompatible-conceptual models,
representations, and protocols in order to create a coherent synthesis. Systems
integration is a problem-solving activity that entails harnessing and coordinating the
power and capabilities of information technology to meet a customer's needs. It
develops mega systems in which pre-existing independent systems become
subsystems--components that must interact with other components. Successful
integration requires solution of both organizational and technical problems:
"* understanding the current organizational capabilities and processes
"* re-engineering and simplification of processes with a system view "* standardizing
on common data languages and system architectures "• automation of processes and
systems
Five kinds of issues motivate companies to invest in systems integration:
• For many organizations, experiences with information technology have not lived up to

expectations.
"• The proliferation of information technology products and vendors has produced the
need for connectivity and interoperability.
"• An installed base of information technology has to accommodate new technology
and new capabilities.
"* Advances in technology, combined with growing appreciation of what can be
accomplished with that technology, have prompted firms to search for new applications
and sources of competitive advantage.
“In an increasingly global economy, firms must rely on telecommunications and
information technology to manage and coordinate their operations and to stay abreast
of international competitors.
The essential enabling technologies are of several kinds:

*Architecture: System organization; kinds of components, kinds of interactions, and
patterns of overall organization; ability to evolve; consistency with available modular
building blocks for hardware, software, and databases; standardization and open
systems
* Semantics: Representations; conceptual consistency; semantic models; means for
handing inconsistencies
* Connectivity: Mechanisms for moving data between systems and initiating action in
other systems; communication platforms with flexible linkages or interfaces; network
management and reliability; security.
* Interaction: Granularity; user interfaces; interoperability; simplicity; underlying
consistency of
presentation
Shared Information Systems:

One particularly significant class of large systems is responsible for collecting,
manipulating, and preserving large bodies of complex information. These are shared
information systems. Systems of this kind appear in many different domains; this paper
examines three. The earliest shared information systems consisted of separate
programs for separate subtasks. Later, multiple independent processing steps were
composed into larger tasks by passing data in a known, fixed format from one step to

another. This organization is not flexible in responding to variations or discrepancies in
data. Nor is it tolerant of structural modification, especially the addition of components
developed under different assumptions. It is also not responsive to the needs of
interactive processing, which must handle individual requests as they arrive.
Still later, often when requirements for interaction appear, new organizations allowed
independent processing subsystems to interact through a shared data store. While this
organization is an improvement, it still encounters integration problems-especially when
multiple data stores with different representations must be shared, when the system is
distributed, when many user tasks must be served, and when the suite of processing
and data subsystems changes regularly.
Database Integration:
Business data processing has traditionally been dominated by database management,
in particular by database updates. Originally, separate databases served separate
purposes, and implementation issues revolved around efficient ways to do massive
coordinated periodic updates. As time passed, interactive demands required individual
transactions to complete in real time. Still later, as databases proliferated and
organizations merged, information proved to have value far beyond its original needs.
Diversity in representations and interfaces arose, information began to appear
redundantly in multiple databases, and geographic distribution added communication
complexity. As this happened, the challenges shifted from individual transaction
processing to integration.
Individual database systems must support transactions of predetermined types and
periodic summary reports. Bad requests require a great deal of special handling.
Originally the updates and summary reports were collected into batches, with database
updates and reports produced during periodic batch runs. However, when interactive
queries became technologically possible, the demand for interaction made generated
demand for on-line processing of both individual requests and exceptions.
Batch Sequential:
Some of the earliest large computer applications were databases. In these
applications individual database operations-transactions-were collected into large
batches. The application consisted of a small number of large standalone programs
that performed sequential updates on flat (unstructured) files.

A typical organization included:
 a massive edit program, which accepted transaction inputs and performed
such validation as was possible without access to the database
 a massive transaction sort, which got the transactions into the same order as
the records on the sequential master file
 a sequence of update programs, one for each master file; these huge
programs actually executed the transactions by moving sequentially through
the master file, matching each type of transaction to its corresponding
account and updating the account records
 a print program that produced periodic reports
Evolution of Shared Information Systems in Business Data Processing:

These business data processing applications exhibit a pattern of development
Driven by changing technology and changing needs. The pattern was:
* Batch processing: Standalone programs; results are passed from one to
another on magtape.
Batch sequential model.
• Interactive processing: Concurrent operation and faster updates preclude
batching, so updates
Are out of synchronization with reports. Repository model with external control.
* Unified schemas: Information becomes distributed among many Different
databases. One
Virtual repository defines (passive) consistent Conversion mappings to multiple
databases.
*Multi-database: Databases have many users; passive mappings don't suffice;
active agents mediate interactions. Layered hierarchy with client-server interaction.
Integration in Software Development Environments:
Software development has relied on software tools for almost as long as
data processing has relied on on-line databases. Initially these tools only supported
the translation from source code to object code; they included compilers, linkers,
and libraries. As time passed, many steps in the software development process
became sufficiently routine to be partially or wholly automated, and tools now

support analysis, configuration control, debugging, testing, and documentation as
well. As with databases, the individual tools grew up independently.
Batch Sequential:
The earliest software development tools were standalone programs. Often their
output appeared only on paper and perhaps in the form of object code on cards or
paper tape. Eventually most of the tools' results were at least in some magnetic-
universally readable-form, but the output of each tool was most likely in the wrong
format, the wrong units, or the wrong conceptual model for other tools to use. Even
today, execution profiles are customarily provided in human-readable form but not
propagated back to the compiler for optimization. Effective sharing of information
was thus limited by lack of knowledge about how information was encoded in
representations. As a result, manual translation of one tool's output to another
tool's input format was common.
Evolution of Shared Information Systems in Software Development Environments:
Software development ha different requirements from database processing. As

compared to databases, Software development involves more different types of
data, fewer instances of each distinct type, and slower query rates. The units of
information are larger, more complex, and less discrete than in traditional
databases. The lifetime of software development information, however, is not (or at
least should not be) shorter than database lifetimes. Despite the differences in
application area and characteristics of the supporting data, the essential problem of
collecting, storing, and retrieving shared data about an ongoing process is common
to the two areas. It is therefore not surprising to find comparable evolutionary
stages in their architectures.
Here the forces for evolution were:

• The advent of on-line computing, which drove the shift from batch to interactive
processing for many functions
• The concern for efficiency, which is driving a reduction in the granularity of
operations, shifting from complete processing of systems to processing of modules
to incremental development

• The need for management control over the entire software development process,
which is driving coverage to increase from compilation to the full life cycle.
Architectural Structures for Shared Information Systems:
While examining examples of software integration, we have seen a variety

of general architectural patterns, or idioms for software systems. In this section we
re-examine the data flow and repository idioms to see the variety that can occur
within a single idiom.
Current software tools do not distinguish among different kinds of
components at this level. These tools treat all modules equally, and they mostly
assume that modules interact only via procedure calls and perhaps shared
variables. By providing only a single model of component, they tend to blind
designers to useful distinctions among modules. Moreover, by supporting only a
fixed pair of low-level mechanisms for module interaction, they tend to blind
designers to the rich classes of high-level interactions among components. These
tools certainly
Provide little support for documenting design intentions in such a way that they
become visible in the resulting software artifacts.
By making the richness of these structures explicit, we focus the attention of

designers on the need for coherence and consistency of the system's design.
Incorporating this information explicitly in a system design should provide a record
that simplifies subsequent changes and increases the likelihood that later
modifications will not compromise the integrity of the design. The architectural
descriptions focus on design issues such as the gross structure of the system, the
kinds of parts from which it is composed, and the kinds of interactions that take
place.
The use of well-known patterns leads to a kind of reuse of design templates. These
templates capture intuitions that are a common part of our folklore: it is now
common practice to draw box-and-line diagrams that depict the architecture of a
system, but no uniform meaning is yet associated with these diagrams. Many
anecdotes suggest that simply providing some vocabulary to describe parts and
patterns is a good first step.

Unit-II
INTRODUCTION TO DESIGN PATTERNS
 Design is a Plan
 Pattern is a Model
 Design Pattern is a recurring solution to design problems which occur over

and over.
 Christopher Alexander invented a Pattern- Language which consists of 2543

Patterns in 1977
 Christopher Alexander says, "Each pattern describes a problem which occurs

over and over again in our environment”
In the year 1995, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.
Gang Of Four (GOF) are invented 23 Design Patterns.
History
– The concept of a "pattern" was first expressed in Christopher
Alexander's work, a Pattern Language in 1977 (2543 patterns)
– in 1995 a group called the Gang of Four or "GoF" (Gamma, Helm,

Johnson, Vlissides) compile a catalog of design patterns
– Buschmann et al: Pattern Oriented Software Construction (1996)
 “Gang of Four” Design Patterns – total 23 patterns

 Creational Patterns (5) : The process of object creation
 Structural Patterns (7) : The composition of objects or classes
 Behavioral Patterns (11) : The way in which objects or classes interact and
distribute responsibility
Creational Patterns
1. Abstract factory
2. Builder
3. Factory method
4. Prototype
5. Singleton
Structural Patterns
1. Adapter
2. Bridge
3. Composite

4. Decorator
5. Facade
6. Flyweight
7. Proxy
Behavioral Patterns
1. Chain of responsibility
2. Command
3. Interpreter
4. Iterator
5. Mediator
6. Memento
7. Observer
8. State
9. Strategy
10.Template method
11.Visitor
ANATOMY OF DESIGN PATTERNS

1) Pattern Name
2) Pattern Problem 3)
Pattern Solution ANATOMY OF
DESIGN
PATTERNS 4) Pattern Consequences

 Every Design Pattern consists of four important elements. They are :
1. Pattern Name : The Name of the Pattern
2. Pattern Problem : The Problem Definition
3. Pattern Solution : The Solution to Problem
4. Pattern Consequences : The Advantages and Disadvantages of the Pattern

WHY DESIGN PATTERNS ?
 Design Patterns can be reused in the contribution of solutions
 It provide common vocabulary and understanding
 It provide a detailed documentation.
 It provide a high level Potential
 It support construction of s/w with defined properties.
 It provide high efficient and elegant solution
 Standard solutions to common problems
 Design Pattern is nearly a universal standard.
 It is mainly used in Object Oriented programming.
 It provides solutions to recurring problems
 These are applicable where automation exists.
 Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides in their
Design Patterns (gang of four) book defined 23 design patterns divided into
three types:
1. Creational Patterns
2. Structural Patterns and
3. Behavioral Patterns
 Creational Patterns: concerned with abstracting the object-instantiation
process.(or) deal with initializing and configuring classes and objects
 Structural Patterns : concerned with how objects/classes can be combined

to form larger structures.(or) deal with decoupling the interface and
implementation of classes and objects
 Behavioral Patterns: concerned with communication between objects (or)

deal with dynamic interactions among societies of classes and objects.
1.Creational Patterns
1. Abstract Factory: Creates an instance of several families of classes
2. Builder: Separates object construction from its representation
3. Factory Method: Creates an instance of several derived classes
4. Prototype: A fully initialized instance to be copied or cloned
5. Singleton: A class of which only a single instance can exist

2. Structural Patterns
1. Adapter: Match interfaces of different classes and objects
2. Bridge: Separates an object’s interface from its implementation
3. Composite: A tree structure of simple and composite objects
4. Decorator: Add responsibilities to objects dynamically
5. Facade: A single class that represents an entire subsystem
6. Flyweight: A fine-grained instance used for efficient sharing
7. Proxy: provide a placeholder for other object to ctrl access
3. Behavioral Patterns
1. Chain of Responsibility: passing a request b/w a chain of objects
2. Command: Encapsulate a command request as an object
3. Interpreter: A way to include language elements in a program
4. Iterator: Sequentially access the elements of a collection
5. Mediator: Defines simplified communication between classes/objects
6. Memento: Capture and restore an object's internal state
7. Observer: A way of notifying change to a number of classes
8. State: Alter an object's behavior when its state changes
9. Strategy: Encapsulates an algorithm inside a class
10.Template Method: Defer the exact steps of an algorithm to a subclass
11.Visitor: Defines a new operation to the objects without changing class.
A Good Design is...

1. Maintainable
2. Extensible
3. Reusable
4. Reliable
5. Efficient
6. Elegant

 Maintenance = fixing bugs
 Extensibility = new requirements
 Reuse = using common code across projects
 Reliability = bug free code
 Efficient = fast and/or small
 Elegant = simple and stylish yet powerful
 Patterns solve software structural problems like:
– Abstraction, Encapsulation
– Information hiding
– Separation of concerns
– Coupling and cohesion
– Separation of interface and implementation
– Single point of reference
– Divide and conquer
 Patterns also solve non-functional problems like:
– Object-Oriented design
– Software Architecture
– Re-reading them over time helps
– As does applying them in your own designs!
Benefits
* Common design jargon
* Consistent format
* Coded infrastructures
* Enhance understanding
* Restructuring & team communication
* Improves thinking about Object Oriented design
* Reuse of solutions to common problems

* Communication tool
* Basis for automation
* Patterns help improve developer communication
* Pattern names form a common vocabulary
Characteristics
* Easy to Design
* Easy to Modify
* Easy to Understand
* Easy to Maintain
* Easy to Execute
* Easy to Visualize
* Easy to Document
* Easy to Model
* Easy to Specify
* Easy to Construct
Advantages
* Reusability
* Reliability
* Flexibility
* Adaptability
* Maintainability
* Efficiency
* Extensibility
* Modifiability
* Understandability
* Portability
Applications

* Automation
* ATM
* Online Banking
* Industry
* Defense
* Aeronautics
* Engineering
* Medical
* Online reservations like Railway and Airway
* Different Managements
* High-level application architecture
* User interfaces
* Software testing
* Project organization and management
* Web sites

UNIT-III
STRUCTURAL PATTERNS
BRIDGE:
 It is a structural design pattern with 151 catalog number and used for
implementation of an object.
 Separates an object’s interface from its implementation.
 Decouple an abstraction from its implementation so that the two can vary
independently.
 Decouples interface from implementation.
 Abstraction creates and initializes the Concrete Implementations. Ex: stub
code, slow code, and optimized code. it describes the design pattern is
 Pattern Name : Bridge(151)
 Classification : Object Structural Pattern
 Intent : Decouple an abstraction from its implementation so that the two can
vary independently.
 Separates an object’s interface from its implementation.
 Also Known As: Handle/Body.
 5. Motivation: Inheritance helps when an abstraction can have multiple possible
implementations but is sometimes not flexible enough. The bridge
patterns puts an abstraction and its implementation in separate class
hierarchies.
Example: There is one class hierarchy for Window interfaces (Window, Icon
Window, Transient Window) and a separate hierarchy for platform-specific
windows implementations (with Window Imp as root).

6. Applicability: Use the Bridge pattern when
 You want to avoid a permanent binding between an abstraction and its
implementation.
 Both the abstractions and their implementations should be extensible by sub-
classing.
 You want to hide the implementation of an abstraction completely from clients.
 You want to share an implementation among multiple objects.
7. Structure:Cla ss and interaction diagrams
8. Participants: Objects/classes and their responsibilities.

 Abstraction (Window)
 Refined Abstraction (IconWindow)
 Implementer (WindowImp)
 ConcreteImplementor (XWindowImp, PMWindowImp)
 Collaborations: How participants collaborate
 collaborate with Abstraction forwards client requests to its Implementor
object.

10.Consequences: Trade-offs and results.
 Decoupling interface and implementation.
 Improved extensibility.
 Hiding implementation details from clients.
11. Implementation: Consider the following implementation issues when
applying the Bridge pattern:
1. Only one Implementer.
2. Creating the right Implementer object.
3. Sharing implementers.
4. Using multiple inheritance.
12. Sample Code: Programs in C++
class Window
{ public: Window(View* contents);
virtual void DrawContents();
virtual void Open();
virtual void Close();
virtual void Iconify();
virtual void Deiconify();
virtual void SetOrigin(const Point& at);
virtual void SetExtent(const Point& extent); virtual void Raise(); virtual void
Lower();
};
13.Known Uses: Examples of pattern in real systems.
 WindowImp is called "WindowPort" and has subclasses such as XWindowPort and
SunWindowPort.
 Defines classes that implement common data structures, such as Set, LinkedSet,
HashSet, LinkedList, and HashTable.
 Known use is the Bridge pattern in the implementation of display of graphical
images.
14.Related Patterns: Related patterns are Abstract Factory (87) and Adapter (139).
 Abstract Factory (87) can create and configure a particular Bridge.
 Adapter (139) pattern is geared toward making unrelated classes
work together.

Composite:
 It is a structural design pattern with 163 catalog number and used for structure
and composition of an object.
 A tree structure of simple and composite objects
 Compose objects into tree structures to represent part-whole hierarchies.
Composite lets clients treat individual objects and compositions of objects
uniformly.
1. Pattern Name : Composite(163)
2. Classification : Object Structural Pattern
3. Intent : Compose objects into tree structures to represent part-whole
hierarchies. A tree structure of simple and composite objects
4. Also Known As: The other well-known name.
5. Motivation: App’s often allow grouping of objects into more complex structures.
 Single implementation could define classes for graphical primitives (Text, Lines)
plus other classes that act as containers for primitives.
 But: code that uses these classes must treat primitive objects and containers
differently (even if user treats them identically).

6.Applicability: Use the Composite pattern when
 You want to represent part-whole hierarchies of objects.
 You wants clients to be able to ignore the difference between compositions of
objects and individual objects.
 Clients will treat all objects in the composite structure uniformly.
7. Structure: Class and interaction diagrams
8. Participants: Objects/classes and their responsibilities.

 Participants are Component (Graphic),
 Leaf (Rectangle, Line, Text, etc.),
 Composite (Picture) and Client.
9. Collaborations: How participants collaborate
 Participants are Component (Graphic), Leaf (Rectangle, Line, Text, etc.),
Composite (Picture) and Client collaborating with Clients use the Component
class interface to interact with objects in the composite structure.
10. Consequences: Trade-offs and results.
 defines class hierarchies i.e. primitive objects and composite objects.
 makes the client simple.
 makes it easier to add new kinds of components.
 can make your design overly general.
11.Implementation: There are many issues to consider when implementing the

Composite pattern:
 Explicit parent references.
 Sharing components.

 Maximizing the Component interface.
 Declaring the child management operations.
 Should Component implement a list of Components?
 Child ordering.
 Caching to improve performance.
 Who should delete components?
 What's the best data structure for storing components?
Decorator:
• It is a structural design pattern with 175 catalogs number and used for
responsibilities of an object without sub classing.
• Add responsibilities to objects dynamically
• Decorators provide a flexible alternative to sub classing for extending
functionality.
• Decorator pattern describes
1. Pattern Name : Decorator(175)
2. Classification : Object Structural Pattern
3. Intent : Attach additional responsibilities to an object dynamically. It provides a
flexible alternative to subclassing for extending functionality.
4. Also Known As: Wrapper
5. Motivation: A graphical user interface toolkit, for example, should let you add
properties like borders or behaviors like scrolling to any user interface
component. A more flexible approach is to enclose the component in another
object that adds the border.
6. Applicability: Use Decorator
• To add responsibilities to individual objects dynamically and transparently.
• For responsibilities that can be withdrawn.
• When extension by sub-classing is impractical.

• Collaborations: Decorator forwards requests to its Component object. It may
optionally perform additional operations before and after forwarding the request.
• Participants are Component ,ConcreteComponent, Decorator, and
ConcreteDecorator classes are collaborate with Clients at run time..
• 10. Consequences: The Decorator pattern has at least two key benefits and
two liabilities:
1. More flexibility than static inheritance.
2. Avoids feature-laden classes high up in the hierarchy.
3. A decorator and its component aren't identical.
4. Lots of little objects.
Façade:
• It is a structural Design pattern design pattern with 185 catalog number and
used for interface to a subsystem.
• A single class that represents an entire subsystem .
• Provide a unified interface to a set of interfaces in a subsystem.
• Facade defines a higher-level interface that makes the subsystem easier to use.
• Facade pattern describes
• Pattern Name : Facade(185)
• Classification : Object Structural Pattern
• Intent : Provide a unified interface to a set of interfaces in a subsystem. It
defines a higher-level interface that makes the subsystem easier to use. A single

class that represents an entire subsystem.
• Also Known As: --
• Motivation: Structuring a system into subsystems helps reduce complexity. A
common design goal is to minimize the communication and dependencies
between subsystems. To provide a higher-level interface that can shield clients
from these classes, the compiler subsystem also includes a Compiler class.
• 6. Applicability: Use the Facade pattern when

• You want to provide a simple interface to a complex subsystem.
• You want to layer your subsystems.
8. Participants: Participants are Facade (Compiler) and subsystem classes
(Scanner, Parser, Program Node, etc.)
9. Collaborations: Clients communicate with the subsystem by sending requests

to Facade, which forwards them to the appropriate subsystem object(s).
• Clients that use the facade don't have to access its subsystem objects directly.
• Participants are Facade and subsystem classes collaborate with clients at run
time.
10.Consequences: The Facade pattern offers the following benefits:
• It shields clients from subsystem components.
• It promotes weak coupling between the subsystem and its clients.
• It doesn't prevent applications from using subsystem classes if they need to.
11. Implementation: Consider the following issues when implementing a

facade:
1. Reducing client-subsystem coupling.
2. Public versus private subsystem classes.
13. Known Uses:
• An application can have built-in browsing tools for inspecting its objects at run-
time.
• Application can also forgo built-in browsing support.
• Uses facades to compose many frameworks into one.

UNIT-1 Introduction To Software Architecture

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

UNIT-1 Introduction To Software Architecture

Transféré par

Droits d'auteur :

Formats disponibles

UNIT-1

INTRODUCTION TO SOFTWARE ARCHITECTURE

What is Software Architecture?

Software Architecture & Design Patterns 1 Dept of CSE, SVColleges, Tirupathi

Why is Architecture Important?

Software Architecture & Design Patterns 2 Dept of CSE, SVColleges, Tirupathi

 How will the users be using the application?

The Goals of Architecture:

Software Architecture & Design Patterns 3 Dept of CSE, SVColleges, Tirupathi

The Architectural Landscape

 User empowerment. A design that supports user empowerment is flexible,

Software Architecture & Design Patterns 4 Dept of CSE, SVColleges, Tirupathi

The Principles of Architecture Design

Software Architecture & Design Patterns 5 Dept of CSE, SVColleges, Tirupathi

 Build to change instead of building to last. Consider how the application

Consider using an incremental and iterative approach to refining your architecture.

Software Architecture & Design Patterns 6 Dept of CSE, SVColleges, Tirupathi

 What assumptions have I made in this architecture?

Key Principles of Software Architecture:

For information about the incremental and iterative approach to architecture,

Following traditional building architecture, a 'software architectural style' is a

Software Architecture & Design Patterns 7 Dept of CSE, SVColleges, Tirupathi

Here is a list of architecture patterns, and corresponding design

Software Architecture & Design Patterns 8 Dept of CSE, SVColleges, Tirupathi

Pipes and filters

Software Architecture & Design Patterns 9 Dept of CSE, SVColleges, Tirupathi

for very complex structures.

Where does it come from?

Software Architecture & Design Patterns 10 Dept of CSE, SVColleges, Tirupathi

When should you use it?

How does it work?

Data structures and their associated operations are encapsulated in an abstract

The computing industry is approaching a formidable obstacle course where anyone

At the same time, we demand constantly improving performance to enable

Software Architecture & Design Patterns 11 Dept of CSE, SVColleges, Tirupathi

Software Architecture & Design Patterns 12 Dept of CSE, SVColleges, Tirupathi

The essential enabling technologies are of several kinds:

Shared Information Systems:

Software Architecture & Design Patterns 13 Dept of CSE, SVColleges, Tirupathi

Software Architecture & Design Patterns 14 Dept of CSE, SVColleges, Tirupathi

Evolution of Shared Information Systems in Business Data Processing:

Software Architecture & Design Patterns 15 Dept of CSE, SVColleges, Tirupathi

Evolution of Shared Information Systems in Software Development Environments:

Software development ha different requirements from database processing. As

Here the forces for evolution were:

Software Architecture & Design Patterns 16 Dept of CSE, SVColleges, Tirupathi

Architectural Structures for Shared Information Systems:

While examining examples of software integration, we have seen a variety

By making the richness of these structures explicit, we focus the attention of

Software Architecture & Design Patterns 17 Dept of CSE, SVColleges, Tirupathi

 Design Pattern is a recurring solution to design problems which occur over

 Christopher Alexander invented a Pattern- Language which consists of 2543

 Christopher Alexander says, "Each pattern describes a problem which occurs

– in 1995 a group called the Gang of Four or "GoF" (Gamma, Helm,

– Buschmann et al: Pattern Oriented Software Construction (1996)

 “Gang of Four” Design Patterns – total 23 patterns

Software Architecture & Design Patterns 18 Dept of CSE, SVColleges, Tirupathi

ANATOMY OF DESIGN PATTERNS

 Every Design Pattern consists of four important elements. They are :

1. Pattern Name : The Name of the Pattern

2. Pattern Problem : The Problem Definition

3. Pattern Solution : The Solution to Problem