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.

6.8. Summary<br />

issues with AREL. In Table 6.1, we recapitulate these usability features and describe how<br />

AREL has been implemented to fulfil them.<br />

Table 6.1: An Analysis of the Usability Features in AREL<br />

AREL Implementation Notes<br />

Effective capture of Yes <strong>Design</strong> rationale can be captured in ARs during the design process,<br />

design rational<br />

and AEs are captured as part of the architecture design.<br />

Effective communication of Yes AREL uses a UML graphical representation to communicate<br />

design rational<br />

the causal relationships between design rationale and design objects.<br />

<strong>Design</strong> Artefact Focus Yes AE can represent requirements, assumptions, constraints,<br />

and design objects. They are classified by different architecture viewpoints.<br />

Traceability and Yes AREL provides tool support to carry out tracing and<br />

Impact Analysis<br />

impact analysis.<br />

Comprehensive <strong>Design</strong> <strong>Rationale</strong> Yes AR contains qualitative and quantitative design<br />

rationale as well as alternative design options.<br />

Common Tool Support Yes A commercially available UML tool can be used to support AREL.<br />

The way AREL is structured is simpler than the argumentation-<strong>based</strong> methods because<br />

design deliberations are not captured. Instead, design rationale are encapsulated in an AR<br />

node and the various kinds of design reasoning are captured with templates. There<strong>for</strong>e,<br />

it is simpler <strong>for</strong> architects to record and use them. The usefulness of the design rationale<br />

captured by AREL is further explored in an empirical study in Chapter 7. Other usability<br />

features are discussed as follows: traceability in Chapter 9, impact analysis in Chapter 10<br />

and tool implementation in Chapter 11.<br />

6.8 Summary<br />

In this chapter, we have introduced the AREL model to represent the architecture design<br />

rationale, architecture design elements and their causal relationships. We use a conceptual<br />

model to describe the high-level requirements of AREL. We distinguish between motivational<br />

reasons and design rationale. The AREL model is characterised as follows:<br />

• <strong>Architecture</strong> element - an architecture element is an input and/or an output of an<br />

architecture decision. It can be a motivational reason to a decision, and it can also<br />

be an outcome of the architecture decision. <strong>Architecture</strong> elements are classified by<br />

viewpoints.<br />

• <strong>Architecture</strong> rationale - an architecture rationale represents the reasons behind an<br />

architecture decision. It contains the qualitative rationale, the quantitative rationale<br />

and alternative designs.<br />

• Directional link between architecture elements and rationale - architecture elements<br />

that are used as inputs into the decision and the architecture elements which are<br />

created as the outcome are linked to the architecture rationale<br />

103

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

Saved successfully!

Ooh no, something went wrong!