Software Architecture

Document Outline
1. Introduction
1.1. Purpose
This document provides a comprehensive architectural overview of the system, using a number
of different architectural views to depict different aspects of the system. It is intended to capture
and convey the significant architectural decisions that have been made on the system. This
document is intended to guide the construction phase of the project.

1.2. Scope
This section describes the boundaries of what the system will do/not do, from an architectural
perspective. Do not repeat the requirements here, but do briefly summarize them and discuss
major components (e.g. database, user interface), and interfaces to other systems.

1.3. Definitions, Acronyms, and Abbreviations

1.4. References
Indicate what other documents are referenced by this document.

1.5. Overview
This document serves as the primary documentation of the software architecture. Describe how
this is different from other documents.

2. Architectural Representation
This section describes how the architecture will be represented. In particular, it will specify the
architectural views that will be used (4+1 model).

3. Architectural Goals and Constraints

This section describes the software requirements and objectives that have some significant
impact on the architecture; for example, safety, security, privacy, use of an off-the-shelf product,
portability, distribution, and reuse. It also captures the special constraints that may apply:
architectural style, design and implementation strategy, development tools, team structure,
schedule, legacy code, and so on.

4. Use-Case View
This section documents the use-case view and a few typical use-case realizations. The
requirements will not be repeated here, but the use-case diagram will summarize the use-cases.

4.1. Use-Case Diagrams

Insert and describe all use-case diagrams here. Refer to functional requirements in the SRS.

4.2. Use-Case Realizations

Insert and describe use-case realizations here. These may include sequence or activity diagrams
for non-trivial use-cases.

5. Logical View
This 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. The architectural style should be documented here.

5.1. Overview
This subsection describes the overall decomposition of the design model in terms of its package
hierarchy and layers.

5.2. Architecturally Significant Design Packages

Insert a package diagram with dependencies here. Packages may include important classes and
interfaces.

5.3. Architecturally Significant Design Classes

Insert high-level class diagrams here.

6. Implementation View
This section describes how classes and packages will be organized into components to be
deployed. Component interfaces should be specified.

7. Deployment View

This section describes how components will be deployed to hardware nodes in the production
environment. Include a deployment diagram here. The discussion should include particular
technologies, third-party and commercial-off-the-shelf (COTS) software, and tools that will be
used.

8. User Interface Description

This section describes the user interface. Screen mockups will be included here.

9. Size and Performance

This section describes characteristics of the architecture that allow it to scale and meet target
performance constraints.

10. Quality
A description of how the software architecture contributes to all capabilities (other than
functionality) of the system: extensibility, reliability, portability, and so on. If these
characteristics have special significance, such as safety, security or privacy implications, they
must be clearly delineated.

Appendix A: ...