Software Architecture The Role of Architecture

Presentation on theme: "Software Architecture The Role of Architecture"— Presentation transcript:

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.

ExampleThe 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

Identify stakeholders and their needs

Identify and prioritize scenarios (architecturally significant use cases)

Look for opportunities to apply architecture styles (routine solutions to reoccurring architecture problems

) (aka patterns

)

Document the planned architecture

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. Concerned with functionality provided to end users. Think analysis model (abstraction from problem domain).

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. Architecture from the programmer’s perspective. Think design model (abstraction of actual or anticipated implementation).

The Use Case view is the 5

th

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 StylesClient/Server

Peer-To-Peer

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.

Peer-To-Peer

Distributed application architecture

similar

to client/server, but components are equals

.

Peers are both suppliers and consumers of resources, in contrast to the traditional client-server model in which the consumption and supply of resources is divided

.

Client/Server Peer-To-Peer

Peer-to-Peer [cont]

No single point of failure (or accountability/liability).

Scalable. Clients both provide and use resources. Content serving capacity of peer-to-peer networks can actually increase as more users begin to access the content

With peer-to-peer, adding clients increases the capacity of the system as a whole. With Client/Server, adding clients reduces resources available

to each one

.

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. “Layer-skipping” 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.

ExamplesUnix 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 SequentialOne 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.