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

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

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

Saved successfully!

Ooh no, something went wrong!