Page 209 -

194 BARBER AND GRASER
Representation-Related Concerns

Is the organization’s development centered around Unified Modeling Language, data
flow diagrams (DFDs), Integrated DEFinition models (e.g., IDEF0), or other software
engineering notations?

As discussed previously, software engineering practitioners and researchers have offered many
different definitions for software architecture. Common among all definitions is the notion that a
software architecture is a model that either describes an existing system or prescribes a system to
be built. Beyond that common ground, definitions vary considerably with regard to the specific
elements that constitute a software architecture. While the RARE DRA is composed of compo-
nents and connectors, where components represent collections of domain functionality and data
and connectors result from the input/output dependencies between those components, others have
suggested that the collection of UML models (class, state chart, use case, etc.) used to describe a
system under development can be construed as an architecture (Kruchten, 2000).
RARE benefits/limitations to consider. For organizations that rely solely on UML models, the
RARE DRA representation is a departure from the notations/representations they use in early
analysis. In particular, these organizations may not typically consider allocation to components at
an early stage. However, both representations capture domain functionality and data. Therefore,
the RARE DRA can coexist with UML models. Furthermore, the DRA complements those models
by enabling RARE-style structural evaluation.

Is the organization’s development methodology centered around data modeling
(e.g., entity-relationship diagrams)?

Some organizations focus their analysis effort on developing a project-level or enterprise-level
data model with minimal emphasis on functional specifications. In fact, an extensive effort to
specify functionality may not be cost effective if an organization develops and maintains systems
that focus on information storage, retrieval, and display with minimal data transformation or
workflow management.
RARE benefits/limitations to consider. Considerations for an organization that emphasizes data
modeling are similar to those for a UML-centric organization. The DRA can coexist with a data
model and complements the data model by allocating data requirements to responsible components.
Each representation provides a different view on the data: data concepts and their relationships
are expressed in a data model, while component allocation is conveyed by the DRA.

Does the organization emphasize the use of formal requirements specifications?
Formal specification languages and their associated analyzers (e.g., Alloy and its accompany-
ing tool ALCOA) provide a means for specifying requirements in precise terms and conducting
computer-based analysis to ensure correctness based on well-defined properties (Jackson, 2006).
However, using a formal specification language requires a level of discipline and rigor when gath-
ering and representing stakeholder requirements in order to map requirements to the constructs
of the chosen language and interpret evaluation results in terms of which requirements will and
will not be satisfied.