A Rationale-based Model for Architecture Design Reasoning

7.1. The EFT system
In this example, we can see that the reliability requirements are realised by a number
of related design decisions. The design rationale for these decisions are intertwined in that
they influence each another in the implementation of design elements. For instance, the
MsgFlowLog table (I2 0 1 ) is a result of two decisions (i.e. AR18 and AR21 ), and those
decisions are based on common requirements R2 5 1 and R2 5 2.
7.1.5 Specialised message control process
In the architecture design of the EFT system, a consideration was given to the processing
scope of MCP. Should a MCP process be a generic single-instance server to process
payments for all the banks, or should there be multiple instances of MCP in which each
instance is responsible for a single bank only? In the former case, a generic MCP process
would take payment messages from any bank for processing. In the latter case, a MCP
process is dedicated to a single bank connection.
Figure 7.8 shows the design reasoning of the decision. The inputs into the decision
require that each message exchanged between the member bank and the system must be
uniquely identifiable. The assumption is that the bank must have logged on successfully
before payment messages can be exchanged. This assumption puts a constraint on the
design such that payment messages cannot be exchanged if the bank has logged off, either
voluntarily or by the EFT system.
Figure 7.8: MCP Connection Design
117