Software Architecture Notes

Software Architecture
Software architecture refers to the fundamental structures of a software system and the

discipline of creating such structures and systems. Each structure comprises software
elements, relations among them, and properties of both elements and
relations. The architecture of a software system is a metaphor, analogous to
the architecture of a building. It functions as a blueprint for the system and the developing
project, laying out the tasks necessary to be executed by the design teams.
Software architecture is about making fundamental structural choices that are costly to
change once implemented. Software architecture choices include specific structural
options from possibilities in the design of the software. For example, the systems that
controlled the Space Shuttle launch vehicle had the requirement of being very fast and
very reliable. Therefore, an appropriate real-time computing language would need to be
chosen. Additionally, to satisfy the need for reliability the choice could be made to have
multiple redundant and independently produced copies of the program, and to run these
copies on independent hardware while cross-checking results.
Documenting software architecture facilitates communication between stakeholders,
captures early decisions about the high-level design, and allows reuse of design
components between projects.
 Macroscopic system structure: this refers to architecture as a higher-
level abstraction of a software system that consists of a collection of
computational components together with connectors that describe the interaction
between these components.
 The important stuff—whatever that is: this refers to the fact that software architects
should concern themselves with those decisions that have high impact on the system
and its stakeholders.
 That which is fundamental to understanding a system in its environment
 Things that people perceive as hard to change: since designing the architecture
takes place at the beginning of a software system's lifecycle, the architect should
focus on decisions that "have to" be right the first time. Following this line of thought,
architectural design issues may become non-architectural once their irreversibility can
be overcome.
 A set of architectural design decisions: software architecture should not be
considered merely a set of models or structures, but should include the decisions that
lead to these particular structures, and the rationale behind them.[9] This insight has
led to substantial research into software architecture knowledge management.
Characteristics
Software architecture exhibits the following:
Multitude of stakeholders: software systems have to cater to a variety of stakeholders
such as business managers, owners, users, and operators. These stakeholders all have
their own concerns with respect to the system. Balancing these concerns and
demonstrating that they are addressed is part of designing the system. This implies that
architecture involves dealing with a broad variety of concerns and stakeholders, and has
a multidisciplinary nature.
Separation of concerns: the established way for architects to reduce complexity is to
separate the concerns that drive the design. Architecture documentation shows that all
stakeholder concerns are addressed by modeling and describing the architecture from
separate points of view associated with the various stakeholder concerns.These separate
descriptions are called architectural views.
Quality-driven: classic software design approaches (e.g. Jackson Structured
Programming) were driven by required functionality and the flow of data through the
system, but the current insight is that the architecture of a software system is more
closely related to its quality attributes such as fault-tolerance, backward
compatibility, extensibility, reliability, maintainability, availability, security, usability, and
other such –ilities. Stakeholder concerns often translate into requirements on these
quality attributes, which are variously called non-functional requirements, extra-functional
requirements, behavioral requirements, or quality attribute requirements.
Recurring styles: like building architecture, the software architecture discipline has
developed standard ways to address recurring concerns. These "standard ways" are
called by various names at various levels of abstraction. Common terms for recurring
solutions are architectural style, tactic, reference architecture and architectural pattern.
Conceptual integrity: a term introduced by Fred Brooks in his 1975 book The Mythical
Man-Month to denote the idea that the architecture of a software system represents an
overall vision of what it should do and how it should do it. This vision should be separated
from its implementation. The architect assumes the role of "keeper of the vision", making
sure that additions to the system are in line with the architecture, hence
preserving conceptual integrity.
Cognitive constraints: an observation first made in a 1967 paper by computer
programmer Melvin Conway that organizations which design systems are constrained to
produce designs which are copies of the communication structures of these
organizations. As with conceptual integrity, it was Fred Brooks who introduced it to a
wider audience when he cited the paper and the idea in his elegant classic The Mythical
Man-Month, calling it "Conway's Law."
Motivation
Software architecture is an "intellectually graspable" abstraction of a complex
system. This abstraction provides a number of benefits:
 It gives a basis for analysis of software systems' behavior before the system has
been built.The ability to verify that a future software system fulfills its stakeholders'
needs without actually having to build it represents substantial cost-saving and risk-
mitigation.A number of techniques have been developed to perform such analyses,
such as ATAM or by creating a visual representation of the software system.
 It provides a basis for re-use of elements and decisions.A complete software
architecture or parts of it, like individual architectural strategies and decisions, can be
re-used across multiple systems whose stakeholders require similar quality attributes
or functionality, saving design costs and mitigating the risk of design mistakes.
 It supports early design decisions that impact a system's development, deployment,
and maintenance life.Getting the early, high-impact decisions right is important to
prevent schedule and budget overruns.
 It facilitates communication with stakeholders, contributing to a system that better
fulfills their needs. Communicating about complex systems from the point of view of
stakeholders helps them understand the consequences of their stated requirements
and the design decisions based on them. Architecture gives the ability to
communicate about design decisions before the system is implemented, when they
are still relatively easy to adapt.
 It helps in risk management. Software architecture helps to reduce risks and chance
of failure.
 It enables cost reduction. Software architecture is a means to manage risk and costs
in complex IT projects.
architectural view model.

Software Architecture Notes

Uploaded by

Copyright:

Available Formats

Software Architecture Notes

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Architecture Notes

Uploaded by

Copyright:

Available Formats

Software Architecture

Software architecture refers to the fundamental structures of a software system and the

You might also like