SYED FEROZ ZAINVI

Software Architecture

Writing from:

http://www.computer-science-notes.blogspot.com

Agenda

Software Architecture – Warm UpSoftware Architecture

Definition Elaboration

Architectural Styles/Patterns – OverviewArchitecture & Technologies

Before We Start …

The last decade has seen a tremendous rise in this prominence of a software engineering sub-discipline called Software Architecture

HOWEVER,“Architecture” is one of the most overused

and least understood terms in professional software development circles.

Regularly misused in project reviews and discussions, academic paper presentations at conferences and product pitches.

Software Architecture - Definitions

Easy to understand but no widely accepted definitionTrying to define a term such as software architecture

is always a potentially dangerous activity Difficult to draw a sharp line between design and

architecture Architecture is one aspect of design that concentrates on some

specific features Software architecture is a level of design concerned with issues

To understand the diversity in views, have a browse through the list maintained by the Software Engineering Institute at:

http://www.sei.cmu.edu/architecture/definitions.html

Software Architecture – IEEE Definition

“Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”

[ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software-Intensive Systems]

Software Architecture – Kazman Definition

“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.”

[L.Bass, P.Clements, R.Kazman, Software Architecture in Practice (2nd edition), Addison-Wesley 2003]

Software Architecture – RUP Version

Architecture of a software system (at a given point) is the organization or structure of the system's significant components interacting through interfaces, with components composed of successively smaller components and interfaces

Software Architecture – Shaw & Garlan Definition

“[Software architecture goes] beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives.”

[D. Garlan, M. Shaw, An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering, Volume I, World Scientific, 1993]

Architecture Defines Structure

Issue is how to sensibly partition an application into a set of inter-related components

An architecture must be designed to meet the specific requirements and constraints of the application it is intended for

A key structural concern for nearly all applications is minimizing dependencies between components, creating a loosely coupled architecture from a set of highly cohesive components.

Responsibility Driven Design is a technique

Architecture Specifies Component Communication

Issue: How divided components communicate data and control information

Some examples: Within same address space: Method Calls If in different threads or processes: Synchronization

Mechanisms Multiple components to be simultaneously informed

about an event occurrence in application environment MANY POSSIBILITIES

Rescue: Architectural Patterns/Styles

Architecture Specifies Component Communication

Issue: How divided components communicate data and control information

Some examples: Within same address space: Method Calls If in different threads or processes: Synchronization

Mechanisms Multiple components to be simultaneously informed

about an event occurrence in application environment MANY POSSIBILITIES

Rescue: Architectural Patterns/Styles

Overview of Patterns

Essentially reusable architectural blueprints that describe the structure and interaction between collections of participating components.

Has well-known characteristics that make it appropriate to use to satisfy particular types of requirements.

Patterns are quite useful, and convey design information. Proven to work. If used appropriately in an architecture, you leverage existing design knowledge by using patterns.

Large systems tend to use multiple patterns, combined in ways that satisfy the architecture requirements.

Architecture Addresses Non-Functional Requirements

Three distinct areas of non-functional requirements:

Technical constraints: Design constraints by specifying certain technologies Usually non-negotiable.

Business constraints: Design constraints due to business, not technical reasons.

Quality attributes: Requirements in terms of scalability, availability, ease of

change, portability, usability, performance, Address issues of concern to application users &

stakeholders

Architecture Is An Abstraction

Marketecture: 1 pg informal depiction of system structure & interactions

In easy to understand way for team members & stakeholders

Unnecessary details are suppressed or ignoredFocus is on salient architectural issuesComponents as black boxes; specifying only

externally visible propertiesHierarchal decomposition is one such mechanismArchitecture partitions team responsibilities &

dependencies

Describing An Architecture Hierarchicallly

Architecture Views

Software Architecture is a complex design artifact

There are number of ways of looking at and understanding an architecture

Philip Krutchen’s 4+1 View Model (IEEE, 1995) Logical View: Architecturally significant elements Process View: Concurreny & Communication elements Physical View: Mapping of processes/components on to

application’s hardware Development View: Internal organization of software

components

Krutchen's 4+1 … Contd…

Views are tied together by the architecturally significant use cases (UC often called scenarios)

UC basically capture the requirements for the architecture, and hence are related to more

than one particular viewBy working through the steps in a particular

use case, the architecture can be “tested”, by explaining how the design elements in the architecture respond to the behavior required in the use case.

SEI's Views & Beyond

Recommends capturing architecture model using 3 different views:

Module: Structural View – code modules, decomposition, inheritance, association, aggregation

Components & Connectors: Behavioral Aspects- Components: Objects, Threads, Processe

- Connectors: Shared Memory, Sockets, MiddlewareAllocation: Process mapping to hardware,

communication using network/database, source code view in configuration management, dev. responsibility

Uses terminology of Architecture Description Language (ADL)

Architectures & Technologies

Architectural decisions to be made in early project life-cycle

Difficult to validate & test until system is builtJudicious prototyping of key components can helpStill sometimes hard to ascertain success of

particular design choice in given application context

Risks can be reduced by using tried & tested approaches for solving certain classes of problems Architectural Patterns

Patterns - Revisited

Patterns are an abstract representation of an architecture, in the sense that they can be realized in multiple concrete forms.

Abstract architectures must be reified by software engineers as concrete software implementations.

Software products vendors have come to the rescue. Widely utilized architectural patterns are supported in a variety of commercial offthe-shelf (COTS) technologies

Architectural Patterns & Concrete Technologies

Software technologies provide reusable, application-independent software infrastructures that implement proven architectural approaches

Competing commercial and open source products exist (BLESSING) Superficially similar Differs in features,

implementations, constraints, cost Selecting a product that has

quality attributes that satisfy the application requirements is difficult (CURSE)

No one-size-fits-all product available

Identifying strengths & weaknesses of a particular choice is difficult in early stages Poor Choices Failed Projects

References

Ian Gorton, Essential Software Architecture, Springer

Shaw & Garlan, Software Architecture – Perspectives On An Emerging Discipline, PHI

R. Pressman, Software Engineering – A Practitioner’s Approach, McGraw Hill

Pankaj Jalote, Integrated Software Engineering, Narosa Publishing

Special Issue on Software Architecture, CSI Communication, 2008

Notes from RMCS (UK)Rational Suite – Online Help

More computer science notes available at:

http://www.computer-science-notes.blogspot.com

Also linked through:http://

www.crossroadsbyzainvi.blogspot.com