Page 210 -

DOMAIN-SPECIFIC & IMPLEMENTATION-INDEPENDENT SOFTWARE ARCHITECTURES 195
RARE benefits/limitations to consider. If an organization leverages a formal requirements
specification, there should be minimal resistance to the DRA. However, in practical terms, the
detail and time required for formal specification and analysis may limit its use on a given project
or system (e.g., performing safety and liveness analysis only for critical functionality).
The DRA, while considered formal in that it uses a designated meta-model, is specified at
a high-level, offering the opportunity to evaluate systemwide concerns at a high level. For ex-
ample, in addition to structural/topological evaluation of components and their relationships (e.g.,
coupling, cohesion, component size), service pre- and post-conditions can provide the basis for
safety and liveness analysis, and service duration and frequency properties can provide input for
simulation-based performance analysis. Nonetheless, as with any formal representation, such DRA
evaluation is of minimal value without a well-populated representation that accurately reflects
stakeholder intentions.
Every system can be described by a software architecture, so every system can benefit from
an architectural prescription prior to development. However, in determining whether the benefits
from adopting an explicit software architecture derivation and evaluation process such as RARE
outweigh the costs, the following questions should be considered, which summarize the concerns
above:

1. Does the explicit component-connector representation in the DRA offer analysis op-
portunities not afforded by other representations?
2. Does the project schedule allow time to represent requirements in an architecture and
step through the derivation process?
3. Are organizational standards and skill sets in the area of modeling notations and de-
velopment methodologies a barrier for exploring other representations and analysis
methods?
4. Will results from architectural evaluations be used to influence design and development
decisions in subsequent stages of the current project as well as future projects?
A fundamental objective of RARE research was to provide a means for understanding compo-
nent responsibility and component dependency early in analysis through a high-level representa-
tion and a methodical derivation process. However, RARE provides minimal decision value if
the architecting activity is not a sanctioned part of an organization’s development methodology.
As with the justification for formal methods, software engineers and project managers must be
convinced there is value in populating a computational specification for the purpose of conducting
evaluations and using evaluation results as rationale for development decisions.
As trends in software engineering continue toward greater reliance on off-the-shelf components
and global development teams, software managers are encouraged to find new ways to save time and
cost by illuminating issues early and specifying requirements using unambiguous representations
ensuring that a delivered product will meet stakeholder expectations. This is especially notable in
distributed development efforts, where developers must understand the scope/boundaries of the
components they have been assigned, the functionality allocated to those components, and their
dependency on other system components.

CONCLUSION AND FUTURE WORK

This chapter presented a formal process and an accompanying tool, Reference Architecture
Representation Environment, to derive a Domain Reference Architecture from a computational