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.
8.3. Other applications of ARM<br />
to ascertain its feasibility and cost. Requirements that need architectural investigations<br />
are called architectural level requirements. Requirements that do not require architectural<br />
investigations because their risks are low, become the concern of detailed system design<br />
activities.<br />
OCR and ICR depict the levels of uncertainties of a design in meeting its objectives.<br />
So they can be used to help determine whether further architecture design is required <strong>for</strong><br />
the particular design area. Since the determination of OCR and ICR are semi-objective<br />
in nature, the acceptable level of risk becomes a semi-objective assessment and could<br />
be set to a defined acceptable level depending on projects. We choose to use 30% as a<br />
guide. Should either OCR or ICR be above this threshold, investigation or modelling at<br />
a more detailed level is required until the risk is reduced. There<strong>for</strong>e, the following are the<br />
necessary conditions <strong>for</strong> the completeness of an architecture model:<br />
• All known non-functional requirements have been identified through requirements<br />
refinement.<br />
• All known architecture level requirements, functional and non-functional requirements,<br />
have corresponding linkages to design components through AR, directly or<br />
indirectly.<br />
• All design components have corresponding linkages through AR.<br />
• For each AR, OCR and ICR are below a defined threshold.<br />
Example 2: This is an example from the EFT system to illustrate how to complete an<br />
architecture design using risk assessment. This example follows from the payment message<br />
design illustrated in Figure 7.5. When the Alarm Service C6 0 0 is designed as a result of<br />
AR15, there is a hidden assumption that it would work <strong>for</strong> the peak loading scenario. This<br />
assumption has a risk associated with it. If the assumption is wrong, the design might not<br />
work. We quantify the risk factors using OCR. Also, there is also a gap in terms of how<br />
this mechanism could be implemented. In order to record multiple alarms, each alarm has<br />
to be identified using a unique key so that it could be associated with an expired payment<br />
message. The uncertainty of the design is a risk highlighted by ICR. Figure 8.2 shows this<br />
example and its design decision process <strong>based</strong> on risk assessments.<br />
The UNIX system call signal(2) and UNIX function call alarm(3) support the setting<br />
of a single clock alarm only, but we need multiple alarms to be set simultaneously. Furthermore,<br />
we want to be able to identify a payment message when an alarm has sounded. These<br />
two design issues indicate implementation uncertainties that need to be investigated. We<br />
found that Top End middleware provides a timeout mechanism that would resolve these<br />
145