Introduction:
Besides structural and behaviour properties, rationale
plays a crucial role in defining the architecture of a
software system. However, unlike other architectural
features, rationale often remains unspecified and
inaccessible to tools. Existing approaches for recording
rationale are not widely adopted. This paper proposes
a simple model for capturing rationales as part of an
architecture specification and attaching them to
elements in the architecture.
If we include system architecture:
A design rationale is the explicit listing
of decisions made during a design process, and the
reasons why those decisions were made.Its primary
goal is to support designers by providing a means
to record and communicate the argumentation and
reasoning behind the design process.
The Bridge between Rationale and
Architecture:
Software design is currently seen as an iterative
process. Often used phases in this process include:
requirements discussions, requirements specification,
software architecting, implementation and testing.
The Rationale Unified Process (RUP) is an example of
an iterative design process split into several phases. In
such an iterative design process, the software
architecture has a vital role.