Концепция: Architectural Mechanism

Architectural Mechanisms are used to satisfy architecturally significant requirements. When fully described, Architectural Mechanisms show patterns of structure and behavior in the software. They form the basis of common software that will be consistently applied across the product being developed. They also form the basis for standardizing the way that the software works; therefore, they are an important element of the overall software architecture. The definition of architecture mechanisms also enable decisions on whether existing software components can be leveraged to provide the required behaviour; or whether new software should be bought or built.

The key point to take on board when discussing architecture mechanisms is that the defining them is all about making choices about *what* technology will be used to satisfy architecturally significant requirements. It is not about producing detailed design or software. This is a common misunderstanding. The creation of detailed design and software that shows *how* specific mechanisms are satisfied is a development task.

The value in defining architecture mechanisms is that it

explicitly calls out aspects of the solution mechanics that are common across the system. This aids planning.
puts down markers for the developers to build those aspects of the system once and then re-use them. This reduces the workload.
promotes the development of a consistent set of services. This makes the system easier to maintain.

An Architectural Mechanism can have three states: Analysis, Design and Implementation. These categories reflect the state of the architectural mechanism over time. The state changes as successive levels of detail are uncovered during the refinement of architecturally significant requirements into working software. The categories are summarized in the table that follows.

States of an Architectural Mechanism

State

Description

Analysis

A conceptual solution to a common technical problem. For example, persistence is an abstract solution to the common requirement to store data. The purpose of this category is simply to identify the need for an Architectural Mechanism to be designed and implemented; and capture basic attributes for that mechanism.

Design

A refinement of an Analysis Mechanism into a concrete technology (for example, RDBMS). The purpose of this category is to enable initial design specifications to be produced and to guide precise product or technology selection.

Implementation

A further refinement of a Design Mechanism into a specific technology or product that implements the required Architectural Mechanism. For example, MySQL, as a database product, implements the Analysis Mechanism Persistence and Design Mechanism RDBMS.

This essentially represents the point at which the decision is made to re-use, buy or build specific software to provide the services defined by the mechanism.

Be aware that these states are frequently referred to themselves as Analysis, Design and Implementation mechanisms. These are synonyms and merely represent the architecture mechanisms in different states of development. The transition from one state to another can often be obvious or intuitive. Therefore, it can be achieved in a matter of seconds. It can also require more considered analysis and design, thus take longer. The following diagram illustrates the transition of Architectural Mechanisms from one state to another.

State Machine for Architectural Mechanisms

Architectural Mechanism States