Database Reference
In-Depth Information
concept and association is ascribed to the aspect (classes, relationships, processes, states,
etc.) of the real world to which it refers. For this purpose, an interpretation procedure has to
be applied to the GCM. The interpretation procedure can be used to assign an interpretation,
that is, a well-defi ned meaning or semantics, to all the elements recorded in the GCM. The
interpretation procedure is based on a requirements representation formalism proposed by
Davis, Jordan and Nakajima (1997). This formalism, termed “Canonical Model”, provides
a set of building blocks (called “elements” and “links”) that can be used to represent the
information contained in a wide range of conceptual models. This means that it can be used
as a lingua franca, which averts having to deal with each conceptual model separately.
From the Canonical Model, which was profoundly restructured to meet the objectives
of our research,
we have been able to defi ne a set of tables of interpretation that operate on
the information gathered in the concept map (Dieste, 2003). An example of these tables is
shown in Table 4, which states all the possible combinations among elements and links.
There are other additional tables that are used to consider propositions (Dieste, 2003), but
are not included here for reasons of space.
The interpretation tables are used according to a set of interpretation rules, which are
completely formalized in an algorithm and are highly independent of the analyst who is
doing the interpreting. However, it is not always possible to achieve full independence, and
the analyst should decide, depending on his/her knowledge of the GCM, which particular
interpretation is the best suited. This happens when two or more elements of the Canonical
Model can be assigned to any given GCM element, where the ambiguity cannot be eliminated
algorithmically. After interpretation, the GCM is called the Requirements Canonical Model
(RCM), as the GCM can now be read unambiguously, as a description of what should be
future software system operation. An example is given in Table 5.
Having removed the ambiguity of the concept map, this has a well-defi ned meaning;
that is, each concept and association can be read as a constructor (classes, relationships,
processes, states, etc.) of one or more conceptual models. As each concept and association
can be understood as constructor of one or more conceptual models, the concept map and the
conceptual models can be directly compared, which means that the correspondence between
the PM and CM sets is established. This many-to-many correspondence, viewed from the
CM set side, indicates which problem domain aspects refl ected in the concept map each
conceptual model is capable of representing. The number of these aspects can be considered
as a measure of the suitability of the conceptual models to problems insofar as it refers to
the expressiveness, for a given problem P, of a set CM of conceptual models.
This number, which has been called fi tness, is defi ned as the ratio between the proposi-
tions that a given conceptual model can represent and the total number of RCM propositions.
A series of identifi cation tables are used to identify how many RCM propositions a given
conceptual model can represent. The identifi cation tables are complementary to Table 4, as
they identify which conceptual models can express each element-link-element combina-
tion in Table 4. By way of an example, Table 6 shows the identifi cation table for the class
diagram, although there are additional tables, approximately three for each conceptual
model (Dieste, 2003).
The identifi cation tables can relate each CRM proposition to the conceptual models
that can express this proposition. Once all the propositions have been considered, fi tness is
calculated as the weighted sum of the propositions each conceptual model can express. For
example, Table 7 shows the fi tness calculation for the
most popular conceptual models, such
