Database Reference
In-Depth Information
CONCLUSIONS
In this chapter we have suggested a two-layer architecture which helps to represent
behavior features. This architecture has been used as a basis for defi ning a metamodel of
UML State Machines. This metamodel, which is an extension of the metamodel proposed
in OMG (2003), basically consists of two class diagrams (Base Diagram and Snapshot
Diagram) and two maps. The main contributions of our proposal, with respect to other ap-
proaches, are the distinction between Base and Snapshot Diagrams and the representation
of the run-to-completion step by means of a map.
From the vast literature on the subject it can be seen that the analysis of behavioral
aspects adds great complexity to modeling and metamodeling tasks. This level of complexity
is likely to be the reason why a widely accepted (neither formal nor metamodeling or other)
approach to behavior and behavioral languages has not yet been found. The perspective of
the present chapter aims to make a signifi cant contribution in this sense, although it has
its limitations. In particular, the high number of models (and metamodels) that have to be
created using this approach could lead to effi ciency issues. We think that future develop-
ment of automated tool support (CASE and MetaCASE tools) can be of great help to solve
such issues.
We have restricted our attention to an analysis of the dynamic semantics of a single
state machine. However, as pointed out in Jürjens (2002), in order to provide complete
executable UML specifi cations, message-passing between different diagrams must also be
formalized. For this reason, in future work, we will investigate how message-passing can be
captured within our approach. Furthermore, there is no general agreement on the meaning
of inheritance when considering the dynamic behavior of objects (Basten & Aalst, 2001),
so that aspects related with the refi nement of UML State Machines (subtyping, inheritance
and general refi nement) remain for future work. Finally, the improvement of the specifi ca-
tion language used for the transformations also remains an ongoing project. In this respect,
the Action Semantics proposed for UML (OMG, 2003) and QVT (OMG, 2002b) need to
be analyzed.
ACKNOWLEDGMENTS
We gratefully acknowledge the helpful discussions and comments of our colleague
Dr. Julio Rubio from Universidad de La Rioja, and the fruitful comments of reviewers on
a previous version of this work.
This work has been partially supported by DGES, projects TIC2000-1368-C03-01,
TIC2002-01626, and by Ibercaja-University of Zaragoza, project IB 2002-TEC-03.
ENDNOTES
1
We will use the term 'State Machines' whenever we want to refer to the UML version
of the statechart technique; in other cases we will use the term 'Statecharts'.
2
There are several reasons why we have chosen to use this presentation option. On the
one hand, since a notion of comparison between class diagrams does not exist in the
UML, there is no UML standard notation that can fully satisfy our requirements. On
the other hand, we can not use italics or bold fonts because they are used in UML with
