| Active Reviews for
Intermediate Designs (ARID) |
A method for performing a
scenario-based stakeholder-centric review of a portion of an architecture that
is typically a coherent software-invocable service. The review is focused on
whether the design is sufficient for the developers of that software that will
use it.
|
| Architecture description
language (ADL) |
A language (graphical, textual,
or both) for describing a software system in terms of its architectural
elements and the relationships among them.
|
| Architectural
drivers |
The combination of functional,
quality attribute, and business requirements that "shape" the architecture or
the particular element under consideration.
|
| Architectural
pattern |
A description of element
and relation types together with a set of constraints on how they are
used. The term architectural style has also been widely used to describe
it.
|
| Architectural
style |
A specialization of
element and relation types, together with a set of
constraints on how they can be used. See architectural
pattern.
|
| Architecture Tradeoff
Analysis Method (ATAM) |
A method to assess the
consequences of architectural decisions in light of quality attribute
requirements and business goals. The ATAM helps stakeholders ask the right
questions to discover potentially problematic architectural
decisions.
|
| Attribute-Driven Design (ADD)
Method |
An approach to defining a
software architecture by basing the design process on the quality attribute
requirements of the system. The ADD method enables designers to understand
quality attribute tradeoffs early in the design process.
|
| Component |
The principal computational
element and data store that execute in a system. See also
module.
|
| Connector |
A runtime pathway of interaction
between two or more components.
|
| Constraint |
A requirement for which the
design decisions are prespecified.
|
| Cost Benefit Analysis Method
(CBAM) |
A method for doing
architecture-based economic analyses of software intensive systems. The aim of
the CBAM is to explicitly associate costs, benefits, and uncertainty with
architectural decisions, as a means of optimizing the choice of such
decisions.
|
| Detailed
design |
A term people sometimes use to
mean detailed architectural design -- that is, architectural design of
fine-grained elements, or fine-grained architectural design decisions such as
the precise interface of an element -- and sometimes used to mean
non-architectural design.
|
| Element |
The architectural building block
(component, connector, or module) that is native to a
style.
|
| Enterprise
architecture |
A means for describing business
structures and processes that connect business structures.
|
| Interface |
See software
interface.
|
| Interface
specification |
A statement of what an architect
chooses to make known about an element in order for other entities to interact
or communicate with it.
|
| Layer |
A collection of code that forms
a virtual machine and that interacts with other layers only according to
predefined roles under the relation "allowed to use".
|
| Module |
An implementation unit of
software that provides a coherent unit of functionality.
|
| Non-architectural
design |
Design decisions carried out
subsequent to the architecture. The design of a software system comprises many
design decisions. Architectural design decisions are those made by the software
architect to insure that the system meets its functional, behavioral, and
quality attribute goals. However, the architect leaves many design decisions to
downstream designers and implementors because those decisions are either
constrained sufficiently by the architecture, or because they are not critical
to achieving the system's requirements. For more information, read What’s the Difference Between
Architecture and Design?.
|
| Quality
attribute |
A property of a work product or
goods by which its quality will be judged by some stakeholder or stakeholders.
Quality attribute requirements such as those for performance, security,
modifiability, reliability, and usability have a significant influence on the
software architecture of a system.
|
| Quality attribute
scenario |
See
scenario.
|
| Quality Attribute Workshop
(QAW) |
A method that engages system
stakeholders early in the life cycle to discover the driving quality attribute
requirements of a software-intensive system. The QAW is aimed at eliciting,
collecting, and organizing software quality attribute requirements in the form
of scenarios. The QAW is used before the software architecture has been
created.
|
| Reference
architecture |
A reference model that is
mapped onto software elements that implements the functionality defined in the
reference model.
|
| Reference
model |
A division of functionality into
elements together with the data flow between those
elements.
|
| Relation |
A definition of how
elements cooperate to accomplish the work of a system.
|
| Scenarios |
"Short stories" that describe a
system interaction with respect to some quality attribute. Typically, the focus
would be on three kinds of scenarios: use case - anticipated uses of the
system, growth - anticipated changes to the system, and exploratory -
unanticipated stresses to the system (uses and/or changes).
|
| Sensitivity
point |
A property of one or more
components (and/or component relationships) that is critical for achieving a
particular quality attribute response. Sensitivity points are places in a
specific architecture to which a specific response measure is particularly
"sensitive" (that is, a little change is likely to have a large impact). Unlike
tactics, sensitivity points are properties of a specific
system.
|
| Software
architecture |
The structure or structures of a
system, which comprise the software elements, the externally visible properties
of those elements, and the relationships among them.
|
| Software
interface |
A boundary across which two
independent entities meet, and interact or communicate with each
other.
|
| Software Product
Line |
A set of software-intensive
systems sharing a common, managed set of features that satisfy the specific
needs of a particular market segment or mission and that are developed from a
common set of reusable core assets in a prescribed way.
|
| Stakeholder |
Someone who has a vested
interest in an architecture.
|
| Style |
See architectural
style.
|
| System
architecture |
A means for describing the
elements and interactions of a complete system including its hardware
elements and its software elements.
|
| Tactic |
A design decision that is
influential in the control of a quality attribute response. Tactics tell you
what to do in order to affect a quality attribute response measure. Unlike
sensitivity points, tactics are independent of any specific system.
|
| Tradeoff |
A property that affects more
than one attribute and is a sensitivity point for more than one
attribute.
|
| Utility tree |
A top-down vehicle for
characterizing the "driving" attribute-specific requirements where nodes
represent important quality goals and leaves represent scenarios.
|
| View |
A representation of a set of
system elements and the relationships among them. A view shows a particular
perspective of the system (e.g., code units, runtime elements) and may show
just part or the entire system. A set of views–not a single
one–convey the architecture.
|
| Views-and-beyond
|
An approach for documentation
that holds that documenting a software architecture is a matter of documenting
the relevant views, and then adding information that applies to more than one
view.
|
| Viewtype |
A category of views. In the
SEI's Views-and-Beyond approach to architecture documentation, three viewtypes
are identified: the module viewtype includes views whose elements are
modules; the C&C viewtype includes views whose elements are
components and connectors; and the allocation viewtype includes
views that show allocation of software to structures in the software system's
environment.
|
