Page 190 -

DOMAIN-SPECIFIC & IMPLEMENTATION-INDEPENDENT SOFTWARE ARCHITECTURES 175
DRACs and allocating data and functionality to those DRACs. Since these allocation decisions
are driven by quality goals prioritized by the architect (reusability, integrability, maintainability,
reliability, performance, and comprehensibility), the resulting DRA also suggests a structure (to-
pology) that reflects given qualities. An important premise of this work is that designs satisfying
DRA content requirements (i.e., domain functionality and data) and adhering to the DRA topology
will likewise exhibit the qualities possessed by the DRA. In summary, the DRA specifies two
forms of requirements to be satisfied by new or existing applications:
1. Content Requirements: the collections of data and functionality in DRACs to be provided
by an application, and
2. Topology Requirements: the integration requirements specified in the DRAC I-M that
describe dependencies between DRACs, and therefore dependencies between respective
applications implementing those DRACs.

The complexity of the allocation process is rooted in a number of issues. These issues are
described below.

How should derivation proceed to create an architecture exhibiting selected qualities?

Given that different architectures are appropriate for different systems and domains, not all ar-
chitects emphasize the same quality attributes, and the architecture may take on different forms
depending upon which quality attributes are emphasized. One architect may hold the opinion
that reusability should be the primary driver for class definition, while another may place greater
emphasis on the comprehensibility of the overall class model.

How should conflicts between qualities be managed?

While it would be ideal to create an architecture capable of maximizing all qualities of interest,
inherent conflicts exist between qualities, making this infeasible. For example, while both reus-
ability and performance may be important to the architect, the optimal set of reusable classes
may look completely different from the optimal set of classes resulting from an emphasis on
performance, and resolutions/tradeoffs made by respective architects can/will differ (Bosch and
Molin, 1999). The architect must manage these conflicts, making tradeoffs as necessary. Certainly,
emphasizing one quality over another is one consideration when resolving such conflicts. In at-
tempting to resolve these conflicts, the architect may benefit from exploring multiple possible
architectural structures.

How can the architecture be evaluated with respect to the qualities selected, and how
does the architect know when quality goals have been achieved?
Certainly, if the architect intends to emphasize particular qualities, there must be some means
for evaluating the architecture with respect to these qualities. While intuition may often drive
architecture derivation, an intuitive approach is unable to provide evidence that qualities are be-
ing met and that systems generated from the architecture will exhibit those qualities. To improve
upon an intuitive approach, quantitative evaluation is necessary to justify the architect’s decisions.
As with any software engineering process, architecture derivation cannot be improved without a
measurement mechanism to provide feedback to the architect (Basili, Briand, and Melo, 1996).