Software Architecture
The Role of Architecture
What is Architecture?
• Software Architecture is the structure and
organization of high-level components in a
software system. This includes high level
components and the relationships between
these components.
• High level components are typically subsystems
or programs. Key classes may also be considered
architecture components.
• The relationships between components includes
interaction between components and the nature
of this interaction.
Example
• The architecture of the WWW is client/server.
• The two types of components that make up the
WWW’s architecture style are:
– Clients = browsers such as Firefox
– Servers = Web servers such as Apache
• Nature of interaction = the http protocol, a
request/response protocol. The protocol is
stateless. The connection is typically open only
for the duration of the request and response.
Other definitions of software architecture
• “Architecture is what remains when you cannot take
away any more things and still understand the system
and explain how it works." [Kruchten, 2000]
• "The software architecture of a program or computing
system is the structure or structures of the system,
which comprise software components, the externally
visible properties of those components, and the
relationships among them." [Bass]
• “Anything that would be very difficult or expensive to
change is architecture and other decisions are design
or implementation decisions”
• “A word we use when we want to talk about design but
want to puff it up to make it sound important." [Fowler
IEEE 2003]
Important Role of Architecture
• Software systems have non-functional as well as
functional requirements. Non-functional
requirements are quality attributes such as
security, performance and scalability.
• Architecture is important because it determines
the degree to which non-functional requirements
are present.
• If a software system is being audited for the
presence of non-functional requirements, the
auditors are going to study the architecture for
evidence that the desired non-functional
requirements have been met.
Architecture and design are not the same thing
• Architecture is a specific type of design.
• The principle difference is:
– Architecture are significant design decisions, those
that impact the system as a whole. Lower level
design decisions tend to have local rather than
broad impact.
– User needs tend to drive low and mid-level design
decisions. Architects must consider the needs of
all stakeholders (users, acquirers, developers,
testers, maintainers, support staff, etc.)
Example
• The Winchester Mystery House in San Jose
California has great design but poor
architecture.
Arial View of Winchester Mystery
House From Google Maps
The Winchester Mystery House
• Sarah Winchester, widow of gun magnate William Wirt Winchester,
inherited a large sum of money upon her husband's death.
• She became convinced that her family was cursed by the spirits of
all those who had been killed by the guns the family had made and
the only way to ward off these evil spirits was to was to
continuously build onto her house.
• That’s what she did for 38 years from 1884 until her death in 1922.
• Problem was she didn’t hire an architect to oversee the changes.
The changes she had done to the house were all local.
• The result: stairs that lead to nowhere, fire places without chimneys
and doors that open onto blank walls. Wonderfully crafted stairs,
chimneys and doors, mind you, but useless because of the lack of
an overall plan to integrate them in with the rest of the house.
The Process of Software Architecture
1. Identify stakeholders and their needs
2. Identify and prioritize scenarios
(architecturally significant use cases)
3. Look for opportunities to apply architecture
styles (routine solutions to reoccurring
architecture problems) (aka patterns)
4. Document the planned architecture
5. Validate the planned architecture
Documenting the Architecture
• It’s impractical to document most architectures
with just one document.
• Architecture addresses the concerns of many
stakeholders. In most cases, no one document
can adequately address the concerns of a diverse
group of stakeholders.
• Different stakeholders are interested in different
aspects of the architecture. What developers are
looking for is not necessary what managers are
looking for and vise versa.
The 4+1 View Model of Architecture
• Philippe Kruchten defined the 4+1 view model of software architecture.
• Each view addresses a specific set of concerns.
• The 4+1 views are:
– Logical – the logical view typically includes class diagrams and behavior
diagrams to make clear that the proposed architecture covers the required
functionality.
– Process – the process view describes concurrent threads and processes.
– Physical/Deployment – the physical view describes the mapping of software
onto hardware.
– Development – the development view takes into account the development
environment. Once you have identified all the needed software elements you
can begin to map them to deployable modules, development teams, etc.
Those aspects of the architecture that are driven by practical concerns of the
software development environment, are addressed by the development view.
– The Use Case view is the 5th or +1 view. It’s conceptually separate from the
other views because it shows how the other views work together to validate
the efficacy and completeness of the architecture.
Conway’s Law
• Conway’s law is an adage that comes from a 1968 article by
computer programmer Melvin Conway in which he
predicts:
“Any organization that designs a system . . . will
inevitably produce a design whose structure is a copy
of the organization's communication structure.”[How
Do Committees Invent?, Conway]
• This idea is sometimes humorously paraphrased as:
“If you have four groups working on a compiler, you
will get a four-pass compiler.”
• Key to effective software architecture is maintaining
flexibility in the structure or organization of the individuals
contributing to the architecture. According to Conway’s law,
if the structure of the organization is rigid, architecture
options will be limited.
Architecture Styles
• Design patterns are reusable solutions to
reoccurring design problems. Architecture styles
is the same idea applied at a higher level—at the
system level.
• Architecture styles = system level organization
• An architecture style provides principles and
guidelines for defining architecture elements,
their interfaces, patterns of communication and
constraints on the combination and interaction of
elements.
Patterns at different levels of design
Common Architecture Styles
•
•
•
•
•
Client/Server
Publisher/Subscriber
3-Tier or, more generally, N-Tier
Layered
Pipes and Filters
Client / Server
• C/S is a distributed computing architecture style.
• As the architecture style behind the WWW and
email, C/S may be the most popular architecture
style by number of instances used daily.
• Characterized by a client component, a server
component and a communication protocol.
• Examples: WWW (HTTP), email (SMTP), Database
access (proprietary protocol).
Client / Server [Cont]
• Servers provide some service via a well defined
interface (communication protocol).
• Clients request services; servers provide services.
Usually the server doesn't know the identity of
the clients in advance (scales better that way).
• The client/server distinction lasts for the duration
of a session. Clients can become servers and
servers can become clients at different times.
• Client and server components often reside on
separate machines.
• Can be stateful or stateless. WWW is of course
stateless.
Publisher / Subscriber
• For certain applications, client/server may be
inefficient. For example, what if a consumer needs
some data from a producer when it becomes available?
Polling the producer would be inefficient.
• Publisher/Subscriber is essentially the same as
Observable/Observer but applied at the level of the
whole system.
• Subscribers register their interest in events from
publishers. When the event occurs, publishers notify all
registered subscribers. Publishers may push items of
interest to subscribers or simply notify them data is
ready leaving them to query for the data.
3-Tiered
• The 3-tier architecture style is an evolution of
the 1-tier and 2-tier computing:
N-Tiered
• Business logic may be further subdivided into:
– Business Process
– Business Transactions
• The business process tier works by sequencing
more primitive business transactions
• Database tier may be subdivided into:
– Data Access Layer (Table Data Gateway, Row Data
Gateway, Active Record, etc.)
– Relational Database
Layered
• Rotate the n-tiered architecture style
90 and you get the layered
architecture style!
• Each layer provides services to layers
above using services from layers
below.
Examples
Android system is designed around
layered architecture style
Layer Styles
• Two main styles:
– Strict layering – each layer is allowed to
communicate only the layer directly
below it.
– Relaxed layering – a layer may
communicate with any layer below it.
• The preference is for each layer to use
only the layer below it. “Layerskipping” dilutes the value of
following this architecture style.
Define an interface for each layer
Layered vs. N-Tier
• What’s the difference between Layers and
Tiers?
• Layers are organized by the level of abstraction
they provide. Tiers are organized by the service
they provide.
• Tiers tend to represent a physical distribution.
• The two styles can be
combined. One tier in an
n-tiered architecture can
be structured according
to the layered
architecture style.
Pipes and Filters
• A structure for systems that process a stream
of data.
• There are filter components that perform
some transformation from inputs to outputs
and pipes which are the conduits for data
traveling between filters.
Examples
• Unix Operating system
user@machine> cat email-data.txt | grep "^From" | sort
• Compilers
Characteristics
• Filters must be independent. One filter should
not share state with another.
• Filters don’t know identity of up or down stream
filters. Loose coupling!
• Filters may act as a buffer but may also be as
simple as a procedure call.
• Data flows one-way through a pipe (i.e. pipes are
unidirectional).
• For maximum advantage, filters should be
allowed to communicate only through pipes
Batch Sequential
• One variation on the pipes filter architecture
style is batch sequential.
• With batch sequential each step must finish
before the next is allowed to start. With the
more general pipes and filter architecture
style filters begin processing as soon as data is
available and filter process data in parallel.
• Batch sequential is one of the oldest forms of
data processing.