Page 187 -

172 BARBER AND GRASER
Figure 10.2 Domain Reference Architecture Class (DRAC) Representation

DECLARATIVE MODEL (D-M) BEHAVIORAL MODEL (B-M)

Attributes State Chart
Name: Name of attribute States: High-level states
Type: Data type of attribute Transitions: High-level transitions
Cardinality: Attribute data cardinality Events: Transition-enabling events
Value constraints: Expression Guards: Transition-enabling guards
Services INTEGRATION MODEL (I-M)
Name: Name of service Subsystem Dependencies
Preconditions: Expression DRACs: Elements of subsystem
Postconditions: Expression
Input Events Service Dependencies
Received from DRAC service DRAC Services: Required events
Input Data and data generated by other
Received from DRAC service DRACs
Output Events
Sent to DRAC service(s) Attribute Dependencies
Output Data DRAC Attributes: Required
Sent to DRAC service(s) attributes from other DRACs

context of this research, a “formal” process can be considered to be one that is “explicitly defined
and repeatable” (Merriam-Webster, 2005). This is in contrast to existing approaches for software
architecture derivation from requirements, which are essentially ad hoc.

The Domain Reference Architecture

The DRA is composed of Domain Reference Architecture Classes (DRACs), each of which
specifies some portion of domain data and functionality (Barber et al., 2000; Graser, 2001). These
classes and their relationships become a reusable blueprint that guides subsequent development
efforts in terms of:

1. Functional, data, and timing requirements—the domain functions, data, and ordering of
functions to be satisfied, and
2. Prescribed architectural structure—the relationships between DRACs that dictate the
relationships between participating applications implementing those DRACs.

Since it is likely that DRACs will be instantiated by different implementation solutions each
time the blueprint is reused for a new system development effort (e.g., computer programs,
hardware devices, personnel), the DRA representation is designed to be highly implementation
independent.
The functionality and data allocated to a DRAC and the relationships between a DRAC and
other DRACs are represented in the three submodels shown in Figure 10.2: the Declarative Model
(DRAC D-M) defines the attributes (i.e., data and events) and services (i.e., functionality) that