Artifact: Software Architecture Document

	The Software Architecture Document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system.
Role:	Software Architect
Optionality/Occurrence:	Primarily developed during the Elaboration phase.
Templates and Reports:	Template: Software Architecture Document Template: Software Architecture Document (Informal)
Examples:	CREG Software Architecture Document - Elaboration Phase CSPS Software Architecture Document - Elaboration Phase
UML Representation:	A set of relevant architectural views: Use-Case, Logical, Process, Deployment, Implementation, Data.
More Information:	Concept: Deployment View Concept: Implementation View Concept: Logical View Concept: Process View Concept: Software Architecture Checklist: Software Architecture Document Guideline: Software Architecture Document
Purpose Timing Responsibility Tailoring

Input to Activities:  Architectural Analysis Construct Architectural Proof-of-Concept Define Test Approach Define Test Environment Configurations Describe Distribution Describe the Run-time Architecture Develop Iteration Plan Identify Design Elements Identify Design Mechanisms Identify Targets of Test Identify Testability Mechanisms Identify Test Ideas Identify Test Motivators Implement Design Elements Incorporate Existing Design Elements Obtain Testability Commitment Prioritize Use Cases Review the Architecture Use-Case Analysis

Output from Activities:  Architectural Analysis Describe Distribution Describe the Run-time Architecture Identify Design Mechanisms Incorporate Existing Design Elements Prioritize Use Cases Structure the Implementation Model

Purpose

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.

Timing

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.

Responsibility

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.

Tailoring

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 of control.
  • 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 design principles.
• 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:

Use-Case View

This view is mandatory.

Logical View

This view is mandatory.

Process View

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.

Deployment View

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.

Implementation View

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.

Data View

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 mechanism.

Rational Unified Process