This document provides an overview of software architecture (SA), including its history, scope, characteristics, and activities. It explains the importance of SA in understanding system structures and addresses the need for early architectural decisions to mitigate risks and ensure stakeholder requirements are met. Key aspects covered include architectural processes, evaluation techniques, architectural patterns, and the relationship between SA and agile development.

1. SOFTWARE
ARCHITECTURE

2. OUTLINE – Software Architecture(SA)
Introduction
A brief history
Scope
Characteristics
Why SA?
SA Activities
SA Topics

3. OUTLINE
Introduction
A brief history
Scope
Characteristics
Why SA?
SA Activities
SA Topics

4. Introduction
 Software architecture refers to the high level structures of a
software system, the discipline of creating such structures, and
the documentation of these structures.
 basically an “intellectually graspable” abstraction of a complex
software system.
 It is about making fundamental structural choices.

5. OUTLINE
Introduction
A brief history
Scope
Characteristics
Why SA?
SA Activities
SA Topics

6. A brief history
 a relatively newer discipline.
 early attempts were imprecise and disorganized.
 Scientists like Dijkstra emphasized that the structure of a
software system matters, getting it right is critical.
 emerged in its full sense in the 90s, research institutes like
CMU and UC, Irvine played major role.

7.  research work concentrated around architectural styles,
architecture description languages, architecture
documentation and formal methods.
 IEEE 1471-2000 was the first formal standard in the
discipline, adopted by ISO in 2007.

8. OUTLINE
Introduction
A brief history
Scope
Characteristics
Why SA?
SA Activities
SA Topics

9. Scope
 Macroscopic system structure — high level abstraction.
 Covers subjects that are fundamental to understanding a
system in its environment.
 constitutes factors that are hard to undo once implemented.
 Architectural design decisions — Software Architecture
Knowledge Management.

10. OUTLINE
Introduction
A brief history
Scope
Characteristics
Why SA?
SA Activities
SA Topics

11. Characteristics
 Caters to the various stakeholders having different
concerns, often takes a multidisciplinary approach.
 Separation of concerns, to reduce complexity — achieved
by describing the architecture from separate points of view
of the stakeholders. Separate descriptions are known as
Architectural Views.
e.g., 4+1 Architectural View Model

12. 4+1 Architectural View Model*
 View Model designed by Philippe Kruchten of UBC for
describing the architecture, based on multiple,
concurrent views.
 views describe the system from the viewpoint of
stakeholders, such as end users, developers and project
managers.
 4 views are: Logical, development, process and physical.
Additionally, some use cases or scenarios make up the +1.
* Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1”
View Model of Software Architecture.
http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf

13. 1. Development – illustrates the system from a programmer’s
perspective and is concerned with software management.
2. Logical – concerned with the functionality that the system
provides to the end-users.
3. Physical – system engineer’s point of view. Concerned with the
topology and connections between software components.
4. Process – deals with the system processes and the runtime
behavior of the system.
5. Scenarios – or “use cases” describes sequences of interactions
between objects and processes to achieve certain goals.

14. Other characteristics (continued):
 Quality driven, closely related to the quality attributes, unlike
software design. Stakeholders concerns translated into quality
attributes. Functional vs. Non-functional requirements.
 Conceptual integrity, represents vision of what it should do
and how it should do it; should be separated from its
implementation; architect preserves conceptual integrity by
ensuring additions to system are in line with the architecture.

15. OUTLINE
Introduction
A brief history
Scope
Characteristics
Why SA?
SA Activities
SA Topics

16. Why S.A.?
 Analysis of system behavior before it has been built; ability
to verify that a system fulfills stakeholders’ needs before
actually building it represents cost-saving and risk
mitigation.
ATAM (Architecture Tradeoff Analysis Method)* is
one of the techniques to perform such analysis.
*Rick Kazman; Mark Klein; Paul Clements. "ATAM: Method for Architecture
Evaluation". Carnegie Mellon Software Engineering Institute. p. 39f.
http://www.sei.cmu.edu/reports/00tr004.pdf

17. ATAM
 Risk-mitigation process, used early in the SDLC;
developed by software engineering institute at CMU.
 used to choose suitable architecture for a system by
discovering tradeoffs, sensitivity points and risks.
 beneficial only when used early in the SDLC, when the
cost of changing is minimal.

18. ATAM benefits
1. Provides documented basis for architecture decisions.
2. Enables early risks detection.
3. Encourages communication between stakeholders.
4. Resolves conflicting goals through prioritizing.
5. Promotes cross-project reuse.

19. Why S.A.? (continued..)
 Allows reuse of strategies and decisions, when
stakeholders require similar quality attributes; saves
time, reduces cost and associated risks.
 Supports early design decisions that impacts a system’s
development, deployment and maintenance; important
to prevent schedule and budget overruns.

20.  facilitates communication with stakeholders,
contributing to a system that better fulfills their needs.
 helps in risk management.
 enables cost reduction, manages costs and risks in
complex IT projects.

21. OUTLINE
Introduction
A brief history
Scope
Characteristics
Why SA?
SA Activities
SA Topics

22. Architecture Activities
 Understanding the environment in which system will
operate and determining the requirements of the
system.
 It takes inputs from stakeholders as functional and non-
functional requirements, outputs architecturally
significant requirements.
Architectural Analysis

23. Architectural Synthesis
 Creation of an architecture, known as “design”.
 Given the architecturally significant requirements, the
current state of the design and the results of any evaluation
activities, the design is created and improved.

24. Architecture Evaluation
 It is determining how well the current design satisfies
the requirement derived during analysis.
 Can be carried out anytime, before, in between or after
the design or the system has been constructed.
 Some well known architecture evaluation techniques are
ATAM and TARA.

25. Architecture Evolution
 It is the process of maintaining and adapting a software
architecture to meet changing requirements and
environment.
 It is concerned with adding new functionalities as well as
maintaining existing functionalities and system
behaviors.

26. Architecture supporting activities
These are used to gather knowledge, evaluate decisions
and document them.
 Knowledge Management and Communication – It is
about exploring, communicating and retaining knowledge
essential to designing an architecture.
 Design Reasoning and Decision Making – the activity of
evaluating design decisions.
 Documentation – recording design generated during the
software architecture processes.

27. OUTLINE
Introduction
A brief history
Scope
Characteristics
Why SA?
SA Activities
SA Topics

28. Software Architecture Topics
 Software architecture description involves the principles and
practices of modelling and representing architectures, using
mechanisms such as: architecture description languages,
architecture viewpoints, and architecture frameworks.
Software architecture description

29.  An architecture description language (ADL) is any means of
expression used to describe a software architecture.
Examples are AADL, Wright (CMU), xADL (UCI), Darwin
(Imperial College London), SBC-ADL (National Sun Yat-Sen
University), ByADL (University of L'Aquila, Italy), etc.
Architecture description languages

30. Architecture viewpoints
 Software architecture descriptions
are commonly organized
into views, analogous to the
different types of blueprints made
in building architecture.
 Each view addresses a set of system concerns, following the
conventions of its viewpoint, where a viewpoint is a specification that
describes the notations, modelling and analysis techniques.

31. Architecture patterns and styles
 An architectural pattern is a general, reusable solution to a
commonly occurring problem in software architecture.
 A software architectural style is a specific method of
construction, characterized by the features and constraints
that make it notable.

32. Software architecture and agile development
 A number of methods have been developed to balance the
trade-offs of up-front design and agility.
 “up-front design” is a software development approach in
which the program's design is to be completed and
perfected before that program's implementation is
started.

33. Software architecture erosion
 Refers to the gap observed between the planned and actual
architecture of a software system.
 Reflexion model (RM) techniques compare a high-level
model provided by the system's architects with the source
code implementation.
 Domain-specific languages focus on specifying and
checking architectural constraints.

34. Software architecture recovery
 Methods and processes to uncover a software system's
architecture from available information.
 Reverse Engineering: re-producing anything based on
the extracted knowledge or design information.