Page 206 -

DOMAIN-SPECIFIC & IMPLEMENTATION-INDEPENDENT SOFTWARE ARCHITECTURES 191
the potential for object-oriented approaches to achieve quality goals can be easily questioned
(Miller, Hsia, and Kung, 1999). Object-oriented researchers have produced a number of metrics
suites designed expressly for object-oriented analysis and design (Brito e Abreu and Melo, 1996;
Chidamber and Kemerer, 1991; Lorenz and Kidd, 1994; Moser et al., 1997), and complementary
research efforts have attempted to associate such measures with higher level quality concerns,
such as reusability, testability, and comprehensibility (Rosenburg and Hyatt, 1997). Since such
metrics were designed primarily to measure characteristics of object-oriented programs and class
models, their definitions were modified slightly to apply to the SEPA DRA. Nonetheless, such
modification is beneficial, since DRA derivation and evaluation is concerned with many of the
same structural issues as object-oriented design.

ASSESSING THE VALUE OF RARE AND THE DRA IN THE CONTEXT
OF A STANDARD SOFTWARE ENGINEERING PROCESS

The research that produced RARE and the DRA was motivated by the need for an artifact that
could serve as a high-level blueprint in large, complex domains where multiple deployment sites
were anticipated over many years. The functionality and data required at each site was expressible
by all or part of the domain requirements modeled in the DRA, while the specific technologies
used to implement that functionality differed considerably across sites and over time (Barber
and Graser, 2001; DARPA, 2000; Graser et al., 2002). The promise of such extensive domain
requirements reuse justified the upfront effort to gather content to populate the architecture and
emphasized the importance of RARE’s methodical derivation and evaluation process. Similarly,
the software engineering process adopted for these projects was explicitly tailored to incorporate
DRA derivation activities.
In general, the ultimate usefulness of the DRA representation and the RARE process for a
typical software development organization depends on the ability to integrate them into the
software architecting activities associated with whatever software engineering methodology the
organization has adopted. A traditional software development methodology defines phases such
as problem identification, feasibility analysis, requirements gathering and representation, system
design, implementation, and deployment (Schach, 2005). Software architecting in the develop-
ment cycle is described by the derivation decision process followed and the chosen representa-
tion. Given that software architectures can be represented at many different levels of abstraction,
software architecting decisions can occur in any development phase. In some organizations, one
person is assigned the role of software architect and makes decisions with input and recommenda-
tions from others. The designated architect may also be guided by an architecture review team,
where reviews focus on evaluating the architecture with respect to quality attributes expressed by
stakeholders by analyzing costs, benefits, and tradeoffs among options (as per tradeoff analysis
in ATAM [Kazman et al., 1998] or RARE). In terms of representation, software engineers may
leverage standard notations such as the Unified Modeling Language (UML) (Richter, 1999), create
semiformal box-and-line diagrams (e.g., with Visio templates), or simply describe the architecture
informally in text.
In assessing the strengths and limitations of RARE in comparison with other software archi-
tecture representation and derivation approaches, the fundamental considerations are whether the
RARE process and the DRA representation can fit into an organization’s existing development
culture and whether the output from RARE analysis will contribute to the overall decision process.
Selected aspects that characterize an organization’s development process and culture are discussed
below. These aspects can be used as evaluation points to help a project manager determine whether