Page 200 -

DOMAIN-SPECIFIC & IMPLEMENTATION-INDEPENDENT SOFTWARE ARCHITECTURES 185
Figure 10.8 “Static” Conflict Resolution During Plan Generation

Meta-strategy1 Meta-strategy1
Strategy001 Strategy001
Strategy002 Strategy002
Selected
Goals Initial plan built from Strategy008 Strategy008
1. Goal1 heuristics and Strategies are
2. Goal2 strategies under Strategy009 pruned based on Strategy009
3. Goal3 selected goals conflicts defined in
based on goal Meta-strategy2 each strategy, and Meta-strategy2
priorities and the revised plan is
heuristic weights Strategy005 presented to the Strategy005
RARE (yielding strategy architect for review.
KB priorities). Strategy006 Strategy006
Meta-strategy3 Meta-strategy3
Strategy003 Strategy003
Strategy004 Strategy004

of goal priority and heuristic weight). At the termination of Plan-Generation, the Derivation Plan
is presented to the architect for review prior to Plan-Execution.
Figure 10.8 shows an example of this process. The architect selects three goals from the KB,
prioritized as Goal1, Goal2, and Goal3. RARE builds an initial derivation plan from the heuris-
tics and strategies under the selected goals, taking into account the goal priorities and associated
heuristic weights to calculate strategy priorities. The resulting plan in Figure 10.8 is composed
of three meta-strategies with respective prioritized strategies. If the strategy definitions in the KB
indicate that Strategy005 conflicts with Strategy006, RARE suggests that Strategy006 be pruned,
since Strategy005 has a higher priority in the derivation plan. The revised plan is presented to the
architect for final review.
The following section discusses the RARE approach for DRA evaluation with respect to se-
lected quality goals.
Formally Evaluating the DRA with Respect to Quality Goals

In RARE, metrics defined under heuristics have two functions: (1) to evaluate the current state
of the architecture with respect to achieving respective goals and heuristics (i.e., “how good is
the DRA?” and “is DRA derivation complete?”) and (2) to provide direction as to how deriva-
tion should proceed to more fully satisfy quality goals (i.e., “what transformations are suggested
to improve the DRA?”). To support these decisions, the RARE tool must be able to determine
whether a metric value is acceptable, and if not acceptable, in which direction it deviates and how
severe the deviation is. Since it is highly unlikely that a single, desired value can be achieved for
every metric under consideration, defining an “acceptable range” and a set of “deviation ranges”
is more practical (e.g., “highly deviated,” “slightly deviated,” and “acceptable” ranges). Further-
more, while a metric can apply to more than one heuristic, what may be considered an acceptable
value under one heuristic may not be acceptable under another. Thus, when evaluating the current
state of the architecture with respect to quality goals, it is the degree of deviation, rather than the
metric value itself, that contributes to overall goal evaluation. In addition, some metrics are better