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)

Architect(s)

Developing organization

Architecture

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)

Architect(s)

Developing organization

Architecture

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

32

Quality Attribute Scenarios Availability

33

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

Tactics to control Response

Response

Availability tactics
Fault Detection Recovery/Preparation And Repair

Availability

Recovery /Re-introduction Removal from Service

Prevention

Ping/Echo

Voting

Shadow

Heart Beat

Active redundancy

State re-synchronization

Transaction

Exception

Passive redundancy

Rollback

Process monitor

Spare

Fault

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