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.
6.4. <strong>Architecture</strong> rationale<br />
• Implementation Certainty Risk (ICR) - measures the risk of not achieving the implementation<br />
with a probability between 0 and 1.<br />
• Cost Benefit Ratio (CBR) - measures the ratio between expected benefits to the<br />
expected costs of the design decision<br />
These estimates are used to assess the options at each decision point. They are the<br />
quantifiable justifications <strong>for</strong> selecting a design option. We have provided a brief introduction<br />
to QNR here. A detailed descriptions of their <strong>for</strong>mulations and applications are<br />
described in Section 8.2.2.<br />
6.4.3 Alternative architecture rationale<br />
In terms of the argumentation-<strong>based</strong> design rationale approach, an alternative design is<br />
referred to as an option or a position. The association to support or refute an option<br />
is modelled explicitly. This leads to complicated decision models. The AREL model<br />
simplifies this by encapsulating the options and their arguments within the decision. In<br />
other words, zero or more alternative design options (i.e. AAR) are contained within an<br />
AR. AAR itself may contain entities such as arguments, design objects and behavioural<br />
diagrams (see Figure 6.5). This in<strong>for</strong>mation allows architects to understand and verify the<br />
discarded design options, their relative merits and demerits, which have been considered<br />
in the decision process.<br />
Both AR and AAR are implemented by the package entity in UML. An AR is a<br />
container of AAR. This multi-level structure hides the complexity of a decision and<br />
makes it easy <strong>for</strong> searching and retrieval. The multi-layered in<strong>for</strong>mation is exposed only<br />
when they are required.<br />
6.4.4 Avoiding cyclic decisions in AREL models<br />
During the design process, architects may inadvertently cause a reasoning cycle to <strong>for</strong>m as<br />
design decisions are incrementally made. For instance, this could happen when different<br />
teams of architects are designing simultaneously. Figures 6.6(a) and 6.6(b) show two cyclic<br />
examples which violate the AREL definition (Section 6.2). In Figure 6.6(a), we can see<br />
that if AR3 was to be created and added to the AREL model, with AE3 as an input<br />
and AE1 as an outcome, this would create a directed cycle in the graph. The dotted<br />
arrows denote the illegitimate ≪ARtrace≫ that would result in a cyclic graph, i.e. from<br />
AE3 through to AR3, AE1, AR1, AE2, AR2, and back to AE3. Similarly, Figure 6.6(b)<br />
93