This is not particularly surprising since the
foundation for executable modeling ideas already existed before UML (e.g., Mellor
and Shlaer, 1991; Pastor and Ramos, 1995). In executable approaches, additional
textual languages are applied along with models, by using constraint languages like
OCL (OMG, 2006) and various action languages or even traditional programming
languages to describe state changes and other actions in the models. Perhaps most
typical here is to provide a class diagram to specify the structure while keeping the rest
in coding terms. This is not truly model-driven nor does it make creating models
attractive: Developers ?¬?rst need to learn UML, or rather a subset of it with some
modi?¬?cations to the standard version, then learn some constraint languages, and
?¬?nally learn some action languages if writing the functions and actions with the
preferred programming language is not possible in that tool.
While executable UML targets code generation, the level of abstraction in models
is low and the support for creating speci?¬?cations modest. Similarly to UML,
executable UML does not know anything about a particular problem domain.
Modelers can therefore create and connect model elements, but must write related
56 DSM DEFINED
OCL and action languages without having support for ?¬?nding a solution.
Pages:
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127