01-Software Architecture Introduction

8/14/2019 01-Software Architecture Introduction

1/37

Introduction to Software

Architecture

Ramesh Ramani


2/37

Contents

Why architecture?

What is architecture?

Architectural styles


3/37

Organisational goals influencerequirements

Requirements lead to an architecture

Architectures yield systems

Systems suggest future neworganizational capabilities andrequirements


4/37


5/37


6/37

Kinds of civil architecture

Communityhouses, flats and apartments, gardens, education,

hospitals, religion

Commerce

shops and stores, restaurants, hotels, office

buildings, banks, airports

Industry

industrial buildings, laboratories, farm buildings

Leisuresport, theaters and cinemas, museums


7/37

Where do Architectures come from?

Stake holders:

The customers

The end users

The developers

Marketing people

The developers organization

The maintenance organization,

Architectures are influenced by system stackholders

Architectures are influenced by technical and organizatinal factors


8/37

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 aparticular specialty


9/37

Architectures are influenced by technical and organizationalfactors

Architecture is the summary result of a set of business andtechnical decisions.

Architects design will vary depends on many factors

Deadlines, real-time system, hardware, support software, humanresource, tools, etc

Different stakeholders has different concerns and goals, some ofthem 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


10/37

Influences on Architecture

System

Architecture

Customer

And end user

Architects influence

Developing

organization

Technical Environment

Architects Experience

Architect(s)

Requirements (Qualities)


11/37

Customers and end users

Difference between customers and end usersCustomer:

pay for the development or purchase of a system andspecifies the requirements

More concerned with cost

End user: uses the systemCategories: 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, networkusage, security, modifiability, and interoperability


12/37

Developing organization

Developing organization and the customers may or may not besame

Three influences come from the role of the developingorganization:

Immediate business

Long term business

Organizational structure

Decision of functionality in the architecture for a large system may

affect the structure of the organization


13/37

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 fromreading a book or taking a course


14/37


Architects background and experience

Industrial standard practices

Software engineering techniques


15/37

Consequences of the influences on an Architect

Identify and actively engage thestakeholders to solicit their needs andexpectations

Understand the nature, source, and priorityof the constraints

Achieve the early engagement of thesystems stakeholders: Architecture review

Iterative prototyping

Require diplomacy, negotiation, andcommunication skills


16/37

System

Architecture

Customer

And end user

Architects influence

Developing

organization


Architects Experience

Architect(s)

Requirements (Qualities)

Architecture business Cycle


17/37

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


18/37

Software process and the ABC

Software process contains

Organization, ritualization, and managament of software developmentactivities

ABC process

Specifications, design, implementation, etc results in additional

activities

Software architects must have

Considerable organizational talent

Negotiating skills

Technical knowledge

Domain knowledge


19/37


20/37


21/37

Understanding the requirements

Object oriented analysis

Safty-critical systems

Creation of proto types


22/37

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


23/37

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


24/37

Analysis or evaluating the architecture

ADL provides analytical capabilities for runtime properties of thesystem

Its performance

Its behavior

Its communication patterns, etc

Non runtime quality attributes as:

Maintainability. ( portability, reusability, adaptability)


25/37

Implementing based on architecture and ensuringconformance

Concerned with keeping the developers faithful to the structuresand interaction protocols

Requirements:

Well communicated architecture

Environment or infrastructure to assists the developers

Tools for architecture development

Constant vigilance for maintenance


26/37

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


27/37

Under water acoustic system

Control process

Prop loss

model Reverb modelNoise

model


28/37

What is Software Architecture?

Bass, Clements, and Kazman. Software Architecture in

Practice, Addison-Wesley 1997:

The software architecture of a program or computingsystem is the structure or structures of the system, which

comprise software components, the externally visible

properties of those components, and the relationships

among them.


29/37

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 oneor a bad one


30/37

Architectural styles, reference models, and

reference architecture

Ref. model

Archi. style

Ref.

architecture

Software architecture

System architecture


31/37

The Whole Story

Tactics Selection

QualityRequirements

BusinessRequirements

Tactics Implementation:Design Patterns &

Architectural Patterns


32/37

32

Quality attributes

Quality of the system

Business quality

Quality of architecture itself


33/37


34/37

Tactics

A tactic is a design decisionthatinfluences a quality attribute.

We are not inventing

Tactics can refine other tactics

Patterns package tactics

Tactics to controlResponse

Stimulus Response


35/37

Availability tactics

Tactics to controlAvailability

Fault Fault Masked orRepair mode

Availability

Fault Detection Recovery/Preparation

And Repair

Recovery

/Re-introductionPrevention

Ping/Echo

Heart Beat

Exception

Voting

Active redundancy

Passive redundancy

Spare

Shadow

State

re-synchronization

Rollback

Removal from

Service

Transaction

Process monitor


36/37

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


37/37

Importance of Architecture

Transferable, reusable model

product lines share a common architecture

systems can be buit by using large, externallydeveloped components

restriction of vocabulary of design alternatives

can be the basis for training

Documents

01-Software Architecture Introduction