Page 184 -

DOMAIN-SPECIFIC & IMPLEMENTATION-INDEPENDENT SOFTWARE ARCHITECTURES 169
specification to be reused for multiple application instantiations over time as new and innovative
technologies become available.
While there has been a definite trend toward utilizing all forms of software architecture
(including reference architectures) as analysis frameworks during the development cycle, re-
search has only recently emphasized formalizing the derivation and concurrent evaluation of
these architectures (Bosch and Molin, 1999; Egyed, Gruenbacker, and Medvidovic, 2000). The
objective of a formal derivation and evaluation process is to generate an architecture capable of
fulfilling a variety of concerns expressed by stakeholders. These concerns may include exhibiting
a particular behavior at runtime, performing acceptably on a particular piece of hardware, and
being easy to customize. The architect translates these concerns into a series of system qualities,
such as reusability, flexibility, performance, comprehensibility, maintainability, and reliability
(Bass, Clements, and Kazman, 1998), and uses the software architecture as a framework for
analyzing a potential system in the context of these qualities. Since an architecture is intended
to prescribe a software system, the resulting system’s ability to respond to these qualities is
strongly impacted by decisions made during the architecture derivation process. However,
given that inherent conflicts exist between system qualities (e.g., performance often opposes
reliability), it is rare for a single architecture to be capable of satisfying all qualities effectively
without some tradeoff (Bosch and Molin, 1999). Combining this observation with the realization
that each architect tends to approach the derivation problem differently further underscores the
need for capturing architect rationale as an essential part of the derivation process. Moreover,
rationale must be supported by formal evaluation approaches to provide evidence that a given
architecture adheres to qualities of interest (Perry and Wolf, 1992). The combined rationale and
evaluation results become valuable artifacts complementary to the architecture itself, facilitating
knowledge transfer and helping to ensure that the architecture evolves in the spirit intended by
the original architect.
In response to the motivations above, the research described in this chapter focuses on devis-
ing a formal process and developing a supporting tool, Reference Architecture Representation
Environment (RARE), to guide the system architect in deriving a high-level software architec-
ture, the Domain Reference Architecture (DRA), designed to capture domain functional and data
requirements intended to be domain-specific/technology-independent, and thus reusable across
implementations within a domain. 1
Software Architectures and Their Derivation and Evaluation

Every software system has an architecture, since every system can be shown to be composed of
components and relations among those components (Bass, Clements, and Kazman, 1998; Jacob-
sen, Kristensen, and Nowack, 1999). In fact, a system may be described by multiple architectures,
each providing a different perspective at a different level of abstraction. Depending on the content
being conveyed by the architecture description, the semantics of a component and corresponding
relations will be different. Figure 10.1 depicts two similarly appearing architectures using the “box
and line” notation often seen in architecture diagrams (Barber, Graser, and Holt, 2001; Bass, Cle-
ments, and Kazman, 1998; Gujral, Ahn, and Barber, 2005; Shaw and Garlan, 1996). The “Domain
Architecture” on the left captures domain modeling knowledge, where a component represents
a class of task performers in the health care domain, each of which is responsible for selected
domain tasks (Barber, Graser, and Holt, 2001). Component relations in this example describe data
dependencies between performer classes. In the “Implementation Architecture,” a component
symbolizes a single machine with relations representing network connections among machines