Sad template xml

Architecture Background

Problem Background

System Overview

Context

Driving Requirements

Solution Background

Architectural Approaches

Analysis Results

Mapping Requirements to Architecture

Documentation Roadmap and Overview

Sub-parts of this section provide information that will help readers or users of the Software Architecture Document (SAD) quickly find information that will enable them to do their jobs. Readers of the SAD seeking an overview should begin here, as should readers interested in finding particular information to answer a specific question.

• How the SAD is organized explains the information that is found in each section of the SAD.
• How a view is documented explains how architectural views are documented in this SAD.

Purpose and Scope of the SAD

This SAD specifies the software architecture for insert scope of SAD. All information regarding the software architecture may be found in this document, although much information is incorporated by reference to other documents.
The software architecture for a system is the structure or structures of that system, which comprise software elements, the externally-visible properties of those elements, and the relationships among them [ Bass 2012]. "Externally visible" properties refers to those assumptions other elements can make of an element, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. This definition provides the basic litmus test for what information is included in this SAD, and what information is relegated to downstream documentation.

The software architecture first and foremost embodies information about how the elements relate to each other. This means that architecture specifically omits certain information about elements that does not pertain to their interaction. Thus, a software architecture is an abstraction of a system that suppresses details of elements that do not affect how they use, are used by, relate to, or interact with other elements. Elements interact with each other by means of interfaces that partition details about an element into public and private parts. Software architecture is concerned with the public side of this division, and that will be documented in this SAD accordingly. On the other hand, private details of elements—details having to do solely with internal implementation—are not architectural and will not be documented in a SAD.

The definition of software architecture makes it clear that systems can and do comprise more than one structure and that no one structure holds the irrefutable claim to being the architecture. The neurologist, the orthopedist, the hematologist, and the dermatologist all take a different perspective on the structure of a human body. Ophthalmologists, cardiologists, and podiatrists concentrate on subsystems. And the kinesiologist and psychiatrist are concerned with different aspects of the entire arrangement's behavior. Although these perspectives are pictured differently and have very different properties, all are inherently related; together they describe the architecture of the human body. So it is with software. Modern systems are more than complex enough to make it difficult to grasp them all at once. Instead, we restrict our attention at any one moment to one (or a small number) of the software system's structures. To communicate meaningfully about an architecture, we must make clear which structure or structures we are discussing at the moment—which view we are taking of the architecture. Thus, this SAD follows the principle that documenting a software architecture is a matter of documenting the relevant views and then documenting information that applies to more than one view.

For example, all non-trivial software systems are partitioned into implementation units; these units are given specific responsibilities, and are the basis of work assignments for programming teams. This kind of element will comprise programs and data that software in other implementation units can call or access, and programs and data that are private. In large projects, the elements will almost certainly be subdivided for assignment to sub-teams. This is one kind of structure often used to describe a system. It is a very static structure, in that it focuses on the way the system's functionality is divided up and assigned to implementation teams.

Other structures are much more focused on the way the elements interact with each other at runtime to carry out the system's function. Suppose the system is to be built as a set of parallel processes. The set of processes that will exist at runtime, the programs in the various implementation units described previously that are strung together sequentially to form each process, and the synchronization relations among the processes form another kind of structure often used to describe a system.

None of these structures alone is the architecture, although they all convey architectural information. The architecture consists of these structures as well as many others. This example shows that since architecture can comprise more than one kind of structure, there is more than one kind of element (e.g., implementation unit and processes), more than one kind of interaction among elements (e.g., subdivision and synchronization), and even more than one context (e.g., development time versus runtime). By intention, the definition does not specify what the architectural elements and relationships are. Is a software element an object? A process? A library? A database? A commercial product? It can be any of these things and more.

Although software architecture tends to focus on structural information, behavior of each element is part of the software architecture insofar as that behavior can be observed or discerned from the point of view of another element. This behavior is what allows elements to interact with each other, which is clearly part of the software architecture and will be documented in the SAD as such. Behavior is documented in the element catalog of each view.

How the SAD Is Organized

This SAD is organized into the following seven sections:

• Documentation Roadmap and Overview provides information about this document and its intended audience. It provides the roadmap and document overview. Every reader who wishes to find information relevant to the software architecture described in this document should begin by reading this section, which describes how the document is organized, and where information may be found.
• Architecture Background provides information about the software architecture. It describes the background and rationale for the software architecture. It explains the constraints and influences that led to the current architecture, and it describes the major architectural approaches that have been utilized in the architecture.
• Views and Mapping Between Views specify the software architecture.
• Referenced Materials and Glossary and Acronyms provide reference information. Referenced Materials provides look-up information for documents that are cited elsewhere in this SAD. Glossary and Acronyms is an index of architectural elements and relations giving their definition, and where each is used in this SAD.

How a View Is Documented

1. Primary Presentation
   • Is usually graphical
   • Should include a key that explains the notation
   • Shows elements and relations among them
   • Shows the information you want to convey about the view first
   • Should identify elements that are external to scope of the view
     • If external entities are not clearly marked in the diagram, consider adding a context diagram
2. Element Catalog
   • Explains elements depicted in primary presentation and their properties
   • Is usually a table with element name and textual description
   • May contain interface documentation
   • May contain behavior documentation
3. Variability Guide
   • Points where system can be parameterized or reconfigured. Examples:
     • Number of instances in a pool
     • Support for plug-ins or add-ons
     • Support for different versions of OS, database server or runtime environment
   • Maybe the view is a reference architecture
     • Provide guidelines to instantiate it
4. Other Information
   • Description and rationale for important design decisions (including relevant rejected alternatives)
   • Results of analysis, prototypes and experiments
   • Context diagram
5. Parent View
   • If the current view is the refinement of another view, indicate which one

Glossary and Acronyms

Software Architecture Documentation

• Software Architecture Documentation Template

• The Java Pet Store SAD

Mapping Between Views

Each of the views specified in Views provides a different perspective and design handle on a system, and each is valid and useful in its own right. Although the views give different system perspectives, they are not independent. Elements of one view will be related to elements of other views, and we need to reason about these relations. For example, a module in a decomposition view may be manifested as one, part of one, or several components in one of the component-and-connector views, reflecting its runtime alter-ego. In general, mappings between views are many to many. This section describes the relations that exist among the view. As required by ANSI/IEEE 1471-2000, it also describes any known inconsistencies among the views.

Mapping Between View1 and View2

...

Mapping Between View1 and View3

...

Referenced Materials

Views

My first View

Primary Presentation

• Is usually graphical
• Should include a key that explains the notation
• Shows elements and relations among them
• Shows the information you want to convey about the view first
• Should identify elements that are external to scope of the view
  • If external entities are not clearly marked in the diagram, consider adding a context diagram

Element Catalog

• Explains elements depicted in primary presentation and their properties
• Is usually a table with element name and textual description
• May contain interface documentation
• May contain behavior documentation

Variability Guide

• Points where system can be parameterized or reconfigured. Examples:
  • Number of instances in a pool
  • Support for plug-ins or add-ons
  • Support for different versions of OS, database server or runtime environment
• Maybe the view is a reference architecture
  • Provide guidelines to instantiate it

Other Information

• Description and rationale for important design decisions (including relevant rejected alternatives)
• Results of analysis, prototypes and experiments
• Context diagram

Parent View

• If the current view is the refinement of another view, indicate which one

My second View

Primary Presentation

Element Catalog

Variability Guide

Other Information

Parent View