Databases Reference
In-Depth Information
must be noticed that, in order to help the reader to easily detect the differences between both
class diagrams, we have used discontinuous lines for depicting the classes and relationships
of the Snapshot Diagram that remain unchanged with regard to the Base Diagram
2
.
As an initial remark regarding the Snapshot Diagram and the notion of submachine
state, let us note that in OMG (2003, pp. 2-158), it is said that “a submachine state is a
convenience that does not introduce any additional dynamic semantics” and that “it is
semantically equivalent to a composite state.” For this reason, from now on, we are going
to suppose that the base state machine does not contain any submachine state (if this is not
the case, an equivalent state machine should be constructed previously). As a consequence
of this, we have not included in the Snapshot Diagram either the
SubmachineStat
e
or the
StubState
Classes.
Thus, the Snapshot Diagram belongs to the Snapshot Layer and captures, together
with the status-independent concepts, those concepts necessary to determine the status of a
state machine at a given moment. In particular, each one of the 'snapshots' of the sequence
described in the previous quotation would correspond to a model of the Snapshot Diagram
we propose. In other words, a 'snapshot' could be described by means of an UML Object
Diagram, which is an instance of the Snapshot Diagram. The way in which a snapshot is
obtained from its predecessor (i.e., the representation of a step) will be analyzed in the fol-
lowing subsection.
It can be observed in the Snapshot Diagram that the
ActiveStateConfi guration
class
is added, which represents the states which are active at a given moment. Furthermore, it
is necessary to capture the information relative to the history of the behavior of the state
machine. This has been done by incorporating information about the last active substate and
the basic confi guration relative to a state. Finally, the
SynchState
class has a new attribute
associated to it which represents, for each object of the class, the difference between the
number of times its incoming and outgoing transitions are fi red.
T
0
and T maps
Once the Base and Snapshot Diagrams have been determined, the metamodel has to
be completed, following the proposed architecture, with two maps. On the one hand, the
procedure which must be followed in order to calculate the initial status has to be deter-
mined. This procedure (represented in the metamodel by means of a map
T
0
T
0
T
) calculates a
snapshot state machine (which has to be a model of the Snapshot Diagram) from a base state
machine (which has to be a model of the Base Diagram). On the other hand, it is necessary
to defi ne the procedure which has to be followed in order to calculate, from a snapshot state
machine representing the current status, that which represents the next status. This second
procedure (represented in the metamodel by means of a map
T
) captures the meaning of a
T
run-to-completion step, and it allows the construction of a sequence of models of the Snap-
shot Diagram, representing an execution trace. Figure 7 can help to clarify the relationships
between the several kinds of models and mappings included in the metamodel. This fi gure
has been inspired by the philosophy of MDA (Miller & Mukerji, 2003), and in particular by
the MDA Metamodel Description, in which mappings (as well as models) are represented
by means of classes.
We propose to make use of a notion of map between class diagrams in order to formal-
ize the procedures represented by
T
0
T
0
T
and
T.
Since a precise and exhaustive defi nition of the
notion of map goes beyond the scope of this chapter, we will consider a very general defi ni-
