A Rationale-based Model for Architecture Design Reasoning
A Rationale-based Model for Architecture Design Reasoning
A Rationale-based Model for Architecture Design Reasoning
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
9.4. AREL and eAREL traceability applications in a case study<br />
4. All the AE nodes with the specified viewpoint classification(s) will be retained in<br />
the result set.<br />
5. All the AE nodes that are not specified in the classification, but are located between<br />
AE 1 and its ancestor AE nodes that are in the classification are retained. Similar to<br />
<strong>for</strong>ward tracing, if these unspecified nodes are not traversed, then the causal chain<br />
will be broken and some of the required AE nodes downstream from it would be<br />
omitted.<br />
Using the example from the previous section, we demonstrate backward tracing of<br />
the root-causes of the alarm server. Consider the Alarm Server C6 0 0, if we want to<br />
understand why it is there, and what requirements have motivated the architects to create<br />
it, then we trace backwards from it. The resulting AREL graph is shown in Figure 9.4. It<br />
shows all the requirements, design elements and design decisions that lead to the creation<br />
of C6 0 0.<br />
The reason <strong>for</strong> the creation of C6 0 0 is due to the need of a timer mechanism (AR15 )<br />
to support asynchronous error detection C4 2 7. The timer would time-out and send a<br />
notification if a payment message has not been acknowledged within a specified time. The<br />
justification in AR15 specifies that this ought to be a separate server process because there<br />
is a technical constraint to implement time-out in the payment processing process itself.<br />
By tracing further backwards, we understand that the need <strong>for</strong> such implementation is<br />
due to the No Loss of Payment Transaction requirement. This requirement comes from<br />
R2 5 1 as well as the implementation of C4 2 4. C4 2 4 is in turn concerned with the<br />
per<strong>for</strong>mance issue of the payment system.<br />
If an architect wants to assess the possibilities of enhancing the timer server, the first<br />
task is to understand the causes of such a design. These causes are intricate because<br />
there are underlying constraints and assumptions in a chain of dependency. In this case,<br />
the multitude of constraints are per<strong>for</strong>mance (AR10 ), reliability(AR14 ) and technical<br />
implementation(AR15 ). A change in the design must address all these inter-connected<br />
causes and constraints at the same time.<br />
Similar to <strong>for</strong>ward traceability, backward traceability supports results scoping by viewpoints.<br />
The resulting trace is a subset of the AREL model. Backward traceability supports<br />
root-cause analysis by retrieving architecture rationale and architecture elements <strong>for</strong> which<br />
the design element in question directly or indirectly depends on.<br />
162