The references section presents external documents which provide background
information important to an understanding of the architecture of the system. If
there are a larger number of references, structure the section in subsections:
external documents
internal documents
government documents
non-government documents
etc.
Architectural Goals and Constraints
The architecture will be formed by considering:
functional requirements, captured in the Use-Case Model, and
non-functional requirements, captured in the Supplementary Specifications
However, these are not the only influences that will shape the architecture:
there will be constraints imposed by the environment in which the software must
operate; by the need to reuse existing assets; by the imposition of various
standards; by the need for compatibility with existing systems, and so on.
There may also be a preexisting set of architectural principles and policies
which will guide the development, and which need to be elaborated and reified
for the project. This section of the Software Architecture document is the
place to describe these goals and constraints, and any architectural
decisions flowing from them which do not find a ready home (as requirements)
elsewhere. The enforcement of these decisions is achieved by framing a set
of architecture evaluation criteria which will be used as part of the
iteration assessment.
Evaluation criteria are also derived from Change Cases which document
likely future changes to:
the system's capabilities and properties
the way the system is used
the system's operating and support environments
Change Cases clarify those properties of the system described by subjective
phrases such as, "easy to extend", "easy to port",
"easy to maintain", "robust in the face of change", and
"quick to develop". Change Cases focus on what is important and likely
rather than just what is possible.
Change Cases try to predict changes: such predictions rarely turn out to be
exactly true.
The properties of a system are determined by users, sponsors, suppliers,
developers, and other stakeholders. Changes can arise from many sources, for
example:
Business drivers: new and modified business processes and goals
Technology drivers: adaptation of the system to new platforms, integration
with new components
Changes in the profiles of the average user
Changes in the integration needs with other systems
Scope changes arising from the migration of functionality from external
systems
The Use-Case View
The Use-Case View presents a subset of the Artifact:
Use-Case Model, presenting the architecturally significant use-cases of the
system. It describes the set of scenarios and/or use cases that represent some
significant, central functionality. It also describes the set of scenarios
and/or use cases that have a substantial architectural coverage (that exercise
many architectural elements) or that stress or illustrate a specific, delicate
point of the architecture.
If the model is larger, it will typically be organized in packages; for ease
of understanding the use-case view should similarly organized by package, if
they are packaged. For each significant use case, include a subsection with the
following information:
The name of the use case.
A brief description of the use case.
Significant descriptions of the Flow of Events of the use
case. This can be the whole Flow of Events description, or
subsections of it that describe significant flows or scenarios of the use
case.
Significant descriptions of relationships involving the use case, such as
include- and extend-relationships, or communicates-associations.
An enumeration of the significant use-case diagrams related to the use
case.
Significant descriptions of Special Requirements of the
use case. This can be the whole Special Requirements
description, or subsections of it that describe significant requirements.
Significant Pictures of the User Interface, clarifying
the use case.
The realizations of these use cases should be found in the logical view.
The Logical View
The Logical View is a subset of the Artifact:
Design Model which presents architecturally significant design elements. It
describes the most important classes, their organization in packages and
subsystems, and the organization of these packages and subsystems into layers.
It also describes the most important use-case realizations, for example, the
dynamic aspects of the architecture.
A complex system may require a number of sections to describe the Logical
View:
Overview
This subsection describes the overall decomposition of the design model
in terms of its package hierarchy and layers. If the system has several
levels of packages, you should first describe those that are significant at
the top level. Include any diagrams showing significant top-level packages,
as well as their interdependencies and layering. Next present any
significant packages within these, and so on all the way down to the
significant packages at the bottom of the hierarchy.
Architecturally Significant Design Packages
For each significant package, include a subsection with the following
information
Its name.
A brief description.
A diagram with all significant classes and packages contained within
the package. For a better understanding this diagram may show some
classes from other packages if necessary.
For each significant class in the package, include its name, brief
description, and, optionally a description of some of its major
responsibilities, operations and attributes. Also describe its important
relationships if necessary to understand the included diagrams.
Use-Case Realizations
This section illustrates how the software works by giving a few selected
use-case (or scenario) realizations, and explains how the various design
model elements contribute to their functionality. The realizations given
here are chosen because they represent some significant, central
functionality of the final system; or for their architectural coverage -
they exercise many architectural elements - or stress or illustrate a
specific, delicate point of the architecture. The corresponding use cases
and scenarios of these realizations should be found in the use-case view.
For each significant use-case realization, include a subsection with the
following information
The name of the realized use case.
A brief description of the realized use case.
Significant descriptions of the Flow of Events - Design of
the use-case realization. This can be the whole Flow of Events -
Design description, or subsections of it that describe the
realization of significant flows or scenarios of the use case.
An enumeration of the significant interaction or class diagrams
related to the use-case realization.
Significant descriptions of Derived Requirements of
the use-case realization. This can be the whole Derived
Requirements description, or subsections of it that describe
significant requirements.
Architecturally Significant Design Elements
To assist in deciding what is architecturally significant, some examples of
qualifying elements and their characteristics are presented:
A model element that encapsulates a major abstraction of the problem
domain, such as:
A flight plan in an air-traffic control system.
An employee in a payroll system.
A subscriber in a telephone system.
Sub-types of these should not necessarily be included, e.g. Distinguishing
an ICAO Standard Flight Plan from a US Domestic
Flight Plan is not important; they are all flight plans and share a
substantial amount of attributes and operations.
Distinguishing a subscriber with a data line, or with a voice line, does
not matter as long as the call handling proceeds in roughly the same way.
A model element that is used by many other model elements.
A model element that encapsulates a major mechanism (service) of the
system
Communication mechanism (RPC, broadcast, broker service).
Error handling or recovery mechanism.
Display mechanism, and other common interfaces (windowing, data
capture, signal conditioning, and so on).
Parameterization mechanisms.
In general, any mechanism likely to be used in many different packages (as
opposed to completely internal to a package), and for which it is wise to have
one single common implementation throughout the system, or at least a single
interface that hides several alternative implementations.
A model element that participates in a major interface in the system with,
for example:
An operating system.
An off-the-shelf product (windowing system, RDBMS, geographic
information system).
A class that implements or supports an architectural pattern (such as
patterns for de-coupling model elements, including the
model-view-controller pattern, or the broker pattern).
A model element that is of localized visibility, but may have some huge
impact on the overall performance of the system, for example:
A polling mechanism to scan sensors at a very high rate.
A tracing mechanism for troubleshooting.
A check-pointing mechanism for high-availability system (check-point
and restart).
A start-up sequence.
An online update of code.
A class that encapsulates a novel and technically risky algorithm, or
some algorithm that is safety-critical or security-critical, for
example: computation of irradiation level; airplane collision-avoidance
criteria for congested airspace; Password encryption.
The criteria as to what is architecturally significant will evolve in the
early iterations of the project, as you discover technical difficulties and
begin to better understand the system. As a rule however, you should label at
most 10% of the model elements as "architecturally significant."
Otherwise you risk diluting the concept of architecture, and "everything is
architecture."
When you define and include the architecturally significant model elements in
the logical view, you should also take the following aspects into consideration
Identify potential for commonality and reuse. Which classes could be
subclasses of a common class, or instances of the same parameterized class?
Identify potential for parameterization. What part of the design can be
made more reusable or flexible by using static and run-time parameters (such
as table-driven behavior, or resource data loaded at start-up time)?
Identify potential for using off-the-shelf products.
The Implementation View
This section describes the decomposition of the software into layers and
subsystems in the implementation model. It describes an overview of the
implementation model and its organization in terms of the components in
implementation subsystems and layers, as well as the allocation of packages and
classes (from the Logical View) to the implementation subsystems and components
of the Implementation View. It contains two subsections:
Overview
This subsection names and defines the various layers and their contents,
the rules that govern the inclusion to a given layer, and the boundaries
between layers. Include a component diagram that shows the relations between
layers.
Layers
For each layer, include a subsection with the following information:
Its name.
An enumeration of the subsystems located in the layer. For each
subsystem, give its name, abbreviation or nickname, and a brief
description.
A component diagram shows the subsystems and their import
dependencies.
If appropriate, indicate its relationship to elements in the logical
or process view.
Size and Performance
This section describes architecturally-defining volumetric and responsiveness
characteristics of the system. The information presented may include:
The number of key elements the system will have to handle (such as the
number of concurrent flights for an air traffic control system, the number
of concurrent phone calls for a telecom switch, the number of concurrent
online users for an airline reservation system, etc.).
The key performance measures of the system, such as average response time
for key events; average, maximum and minimum throughput rates, etc.
The footprint (in terms of disk and memory) of the executables - essential
if the system is an embedded system which must live within extremely
confining constraints.
Most of these qualities are captured as requirements; they are presented here
because they shape the architecture in significant ways and warrant special
focus. For each requirement, discuss how the architecture supports this
requirement.
Quality
In this section, list the key quality dimensions of the system that shape the
architecture. The information presented may include:
Operating performance requirements, such as mean-time between
failure (MTBF).
Quality targets, such as "no unscheduled down-time"
Extensibility targets, such as "the software will be upgradeable
while the system is running".
Portability targets, such as hardware platforms, operating systems,
languages.
For each dimension, discuss how the architecture supports this requirement.
You can organize the section by the different views (logical, implementation,
and so on), or by quality. When particular characteristics are important in the
system, for example, safety, security or privacy, the architectural support for
these should be carefully delineated in this section.
Artifacts >
Analysis & Design Artifact Set >
Software Architecture Document >
Guidelines
