21.01.2014 Views

A Rationale-based Model for Architecture Design Reasoning

A Rationale-based Model for Architecture Design Reasoning

A Rationale-based Model for Architecture Design Reasoning

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!