Page 194 -

DOMAIN-SPECIFIC & IMPLEMENTATION-INDEPENDENT SOFTWARE ARCHITECTURES 179
2. Perform “Dynamic” Strategy Evaluation (performed jointly by RARE and the architect):
Some problems cannot be detected during “static” detection and resolution during Plan-
Generation. In particular, if the same sequence of strategies continues to be executed
over a series of iterations, the derivation process may cease to make progress. RARE
compares the set of pending strategies with a “strategy log” to determine whether such
“looping” is taking place and suggests strategy pruning when appropriate. As with static
conflict detection and resolution, the architect is given the opportunity to review the set
of suggested strategies and finalize the strategies to be executed.
3. Apply Strategies and Log Changes (performed jointly by RARE and the architect): RARE
executes the set of strategies approved by the architect. Each strategy generates a series of
low-level architecture transformation actions (e.g., “Add Class X”). The architect reviews
the actions to be applied and changes parameters as desired (e.g., “Add Class Y” instead
of “Add Class X”). All strategies and actions are logged as part of rationale capture.
4. Calculate Metrics and Goal Satisfaction Indices (performed by RARE): RARE calculates
the metrics associated with all selected goals and computes corresponding goal satisfac-
tion indices.
5. Assess Resulting DRA (performed by the architect): The architect reviews the new DRA
version (DRA n + 1 ) along with associated metric values and goal satisfaction indices. The
architect has the option of ending derivation with the current DRA version or continuing
the derivation process.
6. Select DRA for the Next Iteration (performed by the architect): If the architect opts to
continue the derivation process, a prior DRA version must be selected for further refine-
ment in the next iteration (i.e., the next DRA ). The DRA selected may be the version
n
produced from the current iteration or one generated in a prior iteration. The process then
continues with step 1 above, Identify Applicable Strategies for the Current Iteration.

The phases of the derivation process are guided by content in the RARE KB and the generated
Derivation Plan. The following section defines the KB and describes how the architect expresses
desired qualities using the Derivation Plan.

Guiding Derivation through the Knowledge Base and the Derivation Plan

Since different qualities can result in different architectures, the structure of the DRA derived
reflects the qualities emphasized. The KB captures the expertise for deriving an architecture in
light of a particular quality, while the Derivation Plan allows the architect to express the qualities
desired for a given architecture. The discussion begins by describing the fundamental elements
of the KB and the Derivation Plan: goals, heuristics, strategies, and metrics.
Since attributes such as maintainability, reusability, integrability, performance, comprehensi-
bility, and reliability describe overall architectural qualities, their presence is not easily verified
by direct observation. On the other hand, low-level architecture characteristics (e.g., class size,
depth of inheritance tree, class coupling) that are easily measured do not always have a direct
relationship to the high-level architectural qualities. In fact, there is often a many-to-many relation-
ship between the high-level qualities and the low-level characteristics, such that no single metric
provides conclusive evidence that a quality attribute has been satisfied.
RARE attempts to bridge this gap by correlating high-level architectural quality attributes, or
goals, with low-level characteristics, or metrics, through heuristics and strategies (Figure 10.6).
Each of these elements can be described as follows: