A Rationale-based Model for Architecture Design Reasoning
A Rationale-based Model for Architecture Design Reasoning
A Rationale-based Model for Architecture Design Reasoning
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
10.3. <strong>Reasoning</strong> about change impact with AREL<br />
system, architects can investigate the possible causes (i.e. both architecture elements and<br />
decisions) which contribute to the being of the design object. As such, considerations of<br />
these causes could be made to ensure the design consistency.<br />
10.3.5 Combining diagnostic and predictive reasoning<br />
When an architecture is subject to impact analysis in a real-life project, it is often necessary<br />
to understand the relationships between the design object which is undergoing modification<br />
and other design objects which might be affected by such modification. The side-effects of<br />
a modification may come from a few areas: (a) design objects which are directly affected<br />
by the modification; (b) requirements, constraints or assumptions which are in conflict<br />
with the modification; (c) other design objects that may be indirectly affected when the<br />
requirements, constraints or assumptions are compromised.<br />
Using BBN’s diagnostic and predictive reasoning, architects may use posterior probabilities<br />
to guide the traversal of the AREL network to quantify likely changes within the<br />
network. Based on the message processing example shown in Figure 10.6, we investigate<br />
the changes that are likely to happen to the design of the system if we are to modify<br />
C4 2 9.<br />
C4 2 9 is responsible <strong>for</strong> sending acknowledgement messages to a bank that originates<br />
a payment message. It is also responsible <strong>for</strong> receiving acknowledgement from a bank after<br />
sending it payment messages. In either case, only when an acknowledgement is received<br />
or sent would a payment message be considered legally binding. With the current design<br />
of the system, the system has to reconcile what acknowledgements have not been sent<br />
or received using a signalling mechanism. The design seems complicated and resource<br />
intensive. We are to investigate what-if this mechanism is to change and which parts of<br />
the system would be impacted.<br />
Using the BBN network, we set the evidence and quantitatively analyse the likelihood<br />
of change. Table 10.1 illustrates a sequence of reasoning steps to find out how setting<br />
the evidences <strong>for</strong> C4 2 9 and other architecture elements could affect the validity of architecture<br />
rationales and the volatility of architecture elements. This combined reasoning<br />
process involves using both the BBN diagnostic reasoning and predictive reasoning. The<br />
leftmost column in Table 10.1 shows the name of the BBN node (grouped by the AE nodes<br />
in the upper set, and the AR nodes in the lower set). Each of the remaining columns shows<br />
the change that is being investigated at each step, corresponding to the evidence being<br />
entered into the BBN, by setting the appropriate AE volatility to 100%.<br />
The following is a description of the reasoning steps that are illustrated in 10.1:<br />
186