You are on page 1of 37

Introduction to Software Architecture

Ramesh Ramani

Contents Why architecture? What is architecture? Architectural styles

Organisational goals influence requirements Requirements lead to an architecture Architectures yield systems Systems suggest future new organizational capabilities and requirements

Kinds of civil architecture

Community houses, flats and apartments, gardens, education, hospitals, religion Commerce shops and stores, restaurants, hotels, office buildings, banks, airports Industry industrial buildings, laboratories, farm buildings Leisure sport, theaters and cinemas, museums

Where do Architectures come from?

Architectures are influenced by system stackholders Architectures are influenced by technical and organizatinal factors

Stake holders:
The customers The end users The developers Marketing people

The developers organization

The maintenance organization,

The stakeholders concerns:

Providing a certain behavior at runtime Performing well on a particular piece of hardware Being easy to customize Achieving a short time to market Low cost of development Gainfully employing programmers who have a particular specialty

Architectures are influenced by technical and organizational factors

Architecture is the summary result of a set of business and technical decisions. Architects design will vary depends on many factors
Deadlines, real-time system, hardware, support software, human resource, tools, etc

Different stakeholders has different concerns and goals, some of them may be contradictory Structures and nature of the organization

In general, the influences are:

customers and end users Developing organization Background and experience of the architect Technical environment

Influences on Architecture

Architects influence

Customer And end user Requirements (Qualities)


Developing organization


System Technical Environment Architects Experience

Customers and end users

Difference between customers and end users Customer: pay for the development or purchase of a system and specifies the requirements More concerned with cost End user: uses the system Categories: Those who provide input to the system system administrators those who receive output from the system Acceptable system involves: Behavior, performance, reliability, availability, platform compatibility, memory utilization, network usage, security, modifiability, and interoperability

Developing organization

Developing organization and the customers may or may not be same Three influences come from the role of the developing organization:
Immediate business Long term business Organizational structure

Decision of functionality in the architecture for a large system may affect the structure of the organization

Background and experience of the architects

Trying the previous approach again Architects education and training Exposure to successful architectural styles Exposure to systems Experimenting architectural style or techniques learned from reading a book or taking a course

Technical Environment
Architects background and experience Industrial standard practices Software engineering techniques

Consequences of the influences on an Architect

Identify and actively engage the stakeholders to solicit their needs and expectations Understand the nature, source, and priority of the constraints Achieve the early engagement of the systems stakeholders:
Architecture review Iterative prototyping

Require diplomacy, negotiation, and communication skills

Architecture business Cycle

Architects influence

Customer And end user Requirements (Qualities)


Developing organization


System Technical Environment Architects Experience

The architecture affects the factors that influenced it

Feedback loops

Feedback comes from the architecture

Feedback comes from the system Architecture affects the structure of the developing organisation Architecture prescribes units of software

Units corresponds to work assignment

Work assignment form the basis for the development projects structure Architecture affects the enterprise goals of the developing organisation Architecture affects the customer requirements Architects experience upgraded Few systems will influence and actually change The software engineering cluture Technical environment

Software process and the ABC

Software process contains

Organization, ritualization, and managament of software development activities
Specifications, design, implementation, etc results in additional activities

ABC process

Software architects must have

Considerable organizational talent Negotiating skills Technical knowledge Domain knowledge

Architecture based process steps

Activities are:
Creating the business case for the system Understanding the requirements Creating or selecting the architecture Representing and communicating the architecture Analyzing or evaluating the architecture Implementing the system based on the architecture Ensuring that the implementation conforms to the architecture

Creating the business case for the system

It is the important step in creating and constraining any future requirements
How much should the product cost? What is its targeted market? What is its targeted time to market? Will it need to interface with other systems? Are there system limitations that it must work within?

Understanding the requirements

Object oriented analysis Safty-critical systems Creation of proto types

Creating or selecting the architecture

Any design process, there will be multiple candidate design Some will be rejected immediately Some will contend for primary Choosing the right one is the architects greatest challenges

Representing and communicating the architecture

Communicate clearly, unambiguously to all stakeholders Developers must understand the work assignments Testers must understand the task structure Management must understand the scheduling implications

Representation medium should be: informative unambiguous readable by many people with varied background Architecture must meet: behavioral, performance, quality requirement Representation medium can serve as input to: formal analysis techniques such as model building, simulation, verification, rapid prototyping ADL - Architecture Description language

Analysis or evaluating the architecture

ADL provides analytical capabilities for runtime properties of the system

Its performance Its behavior Its communication patterns, etc

Non runtime quality attributes as:

Maintainability. ( portability, reusability, adaptability)

Implementing based on architecture and ensuring conformance

Concerned with keeping the developers faithful to the structures and interaction protocols Requirements:
Well communicated architecture Environment or infrastructure to assists the developers Tools for architecture development Constant vigilance for maintenance

GOOD architecture

There is no such thing as an inherently good or bad architecture Architectures are either more or less fit for some stated purpose Categories of recommendations:
Process recommendations Product recommendations

Under water acoustic system

Control process

Prop loss model

Reverb model Noise model

What is Software Architecture?

Bass, Clements, and Kazman. Software Architecture in Practice, Addison-Wesley 1997:
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.

What is Software Architecture?

Implications of this definition:
architecture defines components systems can comprise more than one structure every software system has an architecture the behavior of each component is part of the architecture - The architecture for a system to be a good one or a bad one

Architectural styles, reference models, and reference architecture

Ref. model Software architecture Ref. architecture

Archi. style

System architecture

The Whole Story

Business Requirements

Quality Requirements

Tactics Selection

Tactics Implementation: Design Patterns & Architectural Patterns

Quality attributes
Quality of the system Business quality Quality of architecture itself


Quality Attribute Scenarios Availability


A tactic is a design decision that influences a quality attribute. We are not inventing Tactics can refine other tactics Patterns package tactics

Tactics to control Response


Availability tactics
Fault Detection Recovery/Preparation And Repair


Recovery /Re-introduction Removal from Service





Heart Beat

Active redundancy

State re-synchronization



Passive redundancy


Process monitor



Tactics to control Availability

Fault Masked or Repair mode

Importance of Architecture
Early design decisions
defines constraints on an implementation dictates organizational structure

inhibits or enables a systems quality attributes

predicting system qualities by studying its architecture easier to reason about and manage change

Importance of Architecture
Transferable, reusable model
product lines share a common architecture systems can be buit by using large, externally developed components restriction of vocabulary of design alternatives can be the basis for training