Note: This template is largely based on the template provided by the Unified Process for Education (www.yoopeedoo.

com) with modifications based on the software architecture description for the AquaLush system provided in Introduction to Software Engineering Design: Processes, Principles, and Patterns with UML2 by Christopher Fox.

<Company Name> <Project Name> Software Architecture Document

Version <1.0>

[Note: The following template is provided for use with the Unified Process for EDUcation. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).] [To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]

<Project Name> Software Architecture Document <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

Revision History
Date <dd/mmm/yy> Version <x.x> <details> Description <name> Author

Confidential

<Company Name>, 2012

Page 2 of 5

<Project Name> Software Architecture Document <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

Table of Contents
1. Introduction 1.1 Purpose 1.2 Document Conventions 1.3 References 1.4 Document Overview 2. Project Overview 2.1 Project Introduction 2.2 Project Vision and Scope 2.3 Stakeholders 3. Logical View of System Architecture 4. Mid-level Models 4.1 Module <Name of Module 1> 4.1.1 Static view 4.1.2 Dynamic view 4.2 Module <Name of Module 2> 5. Mid-level Design Rationale 6. Glossary 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5

Confidential

<Company Name>, 2012

Page 3 of 5

<Project Name> Software Architecture Document <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

Software Architecture Document

1. Introduction
[The introduction of the Software Architecture Document provides an overview of the entire Software Architecture Document. It should begin with a brief discussion of the system that is under development (i.e., a product overview). Following this description, the introduction includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the Software Architecture Document.] 1.1 Purpose [This section defines the role or purpose of the Software Architecture Document, in the overall project documentation, and briefly describes the structure of the document. The specific audiences for the document are identified, with an indication of how they are expected to use the document.] 1.2 Document Conventions [Describe standards or formatting conventions that have particular meaning. For example, bold and italicized words are technical terms whose definition can be found in an included glossary.] 1.3 References [This subsection provides a complete list of all documents referenced elsewhere in the Software Architecture Document. Identify each document by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. Use standard citation formatting guidelines.] 1.4 Document Overview [This subsection describes what the rest of the Software Architecture Document contains and explains how the Software Architecture Document is organized.]

2.

Project Overview
2.1 2.2 2.3 Project Introduction Project Vision and Scope Stakeholders

3.

Logical View of System Architecture

[The logical view section describes the architecturally significant parts of the design model, such as its decomposition into subsystems and packages, and, for each significant package, its decomposition into classes and class utilities. You should introduce architecturally significant classes and describe their responsibilities, as well as a few very important relationships, operations, and attributes.]

4.

Mid-level Models
[This section is the major technical section of this document. It presents a detailed design. For each major part (i.e., module) identified in the logical view of the architecture, you will model the static and dynamic view.]

Confidential

<Company Name>, 2012

Page 4 of 5

<Project Name> Software Architecture Document <document identifier> 4.1 4.1.1 Module <Name of Module 1> Static view

Version: <1.0> Date: <dd/mmm/yy>

4.1.1.1 UML <Package or Class> Diagram [Include UML package and/or class diagrams showing further decomposition of module and relationships and responsibilities of class. In each class in the UML class diagram, you must show important attributes, their type, and their visibility AND important operation/method names, their parameters, and return values, and their visibility. In addition, give a brief textual description/justification of decomposition of module into classes shown in UML class diagram.] 4.1.1.2 Module Interface Descriptions [Give specifications of the module interface as it relates to important actions/functions/use cases (see detailed design example in appendix B in textbook).] 4.1.2 Dynamic view

4.1.2.1 UML sequence diagrams [Include UML sequence diagrams that relate to the major functions of the module and its classes.] 4.2 [And so on.] Module <Name of Module 2>

5.

Mid-level Design Rationale

[Describe other design options that you considered and justify the main design decisions that you made to arrive at this architecture. Discuss only those that are crucial for fulfilling important requirements, those that will be hard to change later, or those for which the motivation behind them is not immediately apparent. For those decisions that are discussed, you should explain the factors influencing the decision, the alternatives considered, the evaluation of the alternatives, and the reasoning behind the final selection]

6.

Glossary

Confidential

<Company Name>, 2012

Page 5 of 5