Software Architecture Document
The software architecture document provides a comprehensive overview of the
architecture of the software system. It serves as a communication medium between
the software architect and other project team members regarding architecturally
significant decisions which have been made on the project.
The representation and objectives of the software architecture is usually
something that must be defined before the very first iterations, and then be
maintained throughout the project. These architectural representation guidelines
are documented in initial versions of the Software Architecture Document.
The Software Architecture Document is primarily developed
during the elaboration phase, because one of the purposes of this phase is to
establish a sound architectural foundation.
The use-case view within the document is likely to be considered before the
other views, because the use cases drive the development and are an essential
input to iteration planning. For systems with a large degree of concurrency and
distribution, the process and deployment views are also likely to be considered
early, because they then might have substantial impact on the entire system.
A software architect is responsible for producing the Software
Architecture Document, which captures the most
important design decisions in multiple architectural views.
The software architect establishes the overall structure for
each architectural view: the decomposition of the view, the grouping of
elements, and the interfaces between these major groupings. Therefore, in
contrast with the other roles, the software architect's
view is one of breadth, as opposed to depth.
The software architect is also responsible for maintaining
the architectural integrity of the system through the development process by:
- Approving all changes to architecturally significant elements, such as
major interfaces, described in the Software Architecture Document.
- Being part of the "change-control board" decisions to resolve
problems that impact the software architecture.
You should adjust the outline of the Software Architecture Document
to suit the nature of your software:
- Some of the architectural views may be irrelevant:
- The Deployment View is not needed for single-CPU systems.
- The Process View is not needed if the system uses only a single thread
- The Data View is not needed unless object persistence is a significant
aspect of the system and the persistence mechanism requires a
mapping between persistent and non-persistent objects.
- Some specific aspects of the software may require their own section; for
example, aspects related to data management or usability issues.
- You may need additional appendices to explain certain aspects, such as the
rationale of certain critical choices together with the solutions that have
been eliminated, or to define acronyms or abbreviations, or present general
- The order of the various sections may vary, depending on the system's
stakeholders and their focus or interest.
The advantages and disadvantages of each architectural view follow:
This view is mandatory.
This view is mandatory.
This view is optional. Use this view only if the system
has more than one thread of control, and the separate threads interact or are
dependent upon one another.
This view is optional. Use this view only if the system is
distributed across more than one node. Even in these cases, only use the
deployment view where the distribution has architectural implications. For
example, in cases where there is a single server and many clients, a
deployment view only needed to delineate the responsibilities of the server
and the clients as a class of nodes; there is no need to show every client
node if they all have the same capabilities.
This view is optional. Use this view only in cases where
the implementation is not strictly driven from the design, i.e. where there is
a different distribution of responsibilities between corresponding packages in
the Design and Implementation models. If the packaging of the design and
implementation models are identical, this view can be omitted.
This view is optional. Use this view only if persistence
is a significant aspect of the system. and the translation from the Design
Model to the Data Model is not done automatically by the persistence
© 1987 - 2001 Rational Software Corporation