This paper advocates the application of language embedding for executable UML modeling. In particular, txtUML is presented, a Java API and library to build UML models using Java syntax, then run and debug them by reusing the Java runtime environment and existing debuggers. Models can be visualized using the Papyrus editor of the Eclipse Modeling Framework and compiled to implementation languages. The paper motivates this solution, gives an overview of the language API, visualization and model compilation. Finally, implementation details involving Java threads, reflection and AspectJ are presented.
Executable modeling aims at models that are completely independent of the execution platform and implementation language, and can be executed on modellevel. This way models can be tested and debugged in early stages of the development process, long before every piece is in place for building and executing the software on the real target platform.
Executable and platform-independent UML modeling changes the landscape
of software development tools even more than mainstream modeling: graphical
model editors instead of text editors, model compare and merge instead of line
based compare and merge, debuggers with graphical animations instead of
debuggers for textual programs, etc. Figure 1 depicts the many different use cases
such a toolset is responsible for. Models are usually persisted in a format that
is hard or impossible to edit directly, therefore any kind of access to the model
is dependent on different features of the modeling toolset. Are the available
tools ready to meet the requirements? Experience shows that they still need to
evolve a lot. Another aspect is that, while graphical notations help
understanding software more than textual representations, editing graphics is usually less
productive than editing text [
Textual modeling languages solve many of these concerns. The many highquality text editors with sophisticated editing and search-related features, as well as the numerous compare and merge tools serve as a solid basis. However, merely defining a textual notation for modeling does not solve all the issues. Text editors need plugins to do syntax highlighting and autocompletion correctly for the new language. Executable modeling makes even heavier-weight demands: interpreter and debugger are also required.
Language embedding is a technique to implement a language in terms of an existing one. The implementation language is called the host language, while the implemented one is referred to as the embedded language. One way to embed a language is to create an API in the host language that offers the constructs of the embedded language for the developers. A program of the embedded language is therefore a host language program that heavily uses this API. The API can, on one hand, implement the execution semantics of the embedded language (making it executable in the runtime environment of the host language) and, on the other hand, can build an internal representation of the embedded program (to be used further for compilation, visualization, analysis etc.). The big advantage is that an embedded language can piggyback on the development and runtime environment of the host language.
This paper proposes using language embedding for executable UML modeling. As stated above, such an embedded language can be realized by an API that provides the constructs of executable UML. It is natural to use an objectoriented programming language as host language, because many of the UML modeling concepts, such as classes, inheritance, attributes, operations, visibility, instance creation etc. are already present in these languages. Other constructs, like components, associations, state machines, events etc. are usually not explicitly present, therefore these abstractions have to be provided by the API. The implementation of this API has to capture the runtime semantics of these constructs. A UML model can then be implemented by a program in the host language naturally reusing the modeling constructs that are part of the host language and using the API to build the rest of the model. Model execution, in this setup, is not more than running the resulting program in the execution environment of the host language. Figure 2 highlights how many elements of the ”modeling environment” are provided for free by this approach. Editing, searching, basic refactoring can be performed in the usual development environment (smart text editor or IDE) of the host language. The debugger of the host language can be reused to observe model execution in detail. Visualization of the model can be achieved via existing UML editors or viewers.
Authors of this paper have created a prototype implementation of a modeling
language along these lines [
The paper is organized as follows. The next section reviews related work and compares them to our approach. Section 3 presents the language API, while sections 4, 5 and 6 talks about execution, visualization and model compilation. More details on the implementation of these aspects are given in Section 7. The last section summarizes the paper and highlights its most important contributions. 2
The UML standard does not define precise execution semantics, but the
Foundational Subset for Executable UML (fUML) [
BridgePoint [
Turning to textual UML modeling, Action Language for Foundational UML
(Alf ) [
Section 1 discussed the importance and difficulties of model management. The
Epsilon [
Regarding the visualization aspect of our project, MetaUML [
Our implementation currently supports classes, state machines and action code. To make clear distinction between plain Java classes and those that are part of the UML model description, all model classes have to inherit (directly or indirectly) from ModelClass, which is provided by our API1. Associations are also represented by class definitions, inheriting from Association. Multiplicities are described as Java annotations like @One, @Many etc. For example, a class diagram talking about users using machines can be described this way: class Machine extends ModelClass { /* ... */ } class User extends ModelClass { /* ... */ } class Usage extends Association { @One Machine usedMachine; @Many User userOfMachine; } Signals are defined by classes that inherit from Signal. Let us define a signal that users can send to machines by pressing the power button: class ButtonPress extends Signal {} class Off extends State { /* ... */ } class On extends State { public void entry() { /* ... */ } public void exit() { /* ... */ } } @From(Off.class) @To(On.class) @Trigger(ButtonPress.class) class SwitchOn extends Transition {
public void effect() { /* ... */ } } } Operations of model classes, entry and exit actions of states and effects of transitions contain action code. The doWork operation of the User model class, for example, log a message to the console, selects the machine that it is associated with, then presses its power button: void doWork() {
Action.log("User: starting to work..."); Machine myMachine = Action.selectOne(this, Usage.class, "usedMachine"); Action.send(myMachine, new ButtonPress()); Action language constructs include instance related operations (eg. creation, deletion, access to operations and attributes), association related ones (link, unlink, different traversals), signal sending, logging and basic operations of elementary types like integers and strings.
It is important to note that only a restricted subset of Java is allowed in model definitions. For example, adding a Vector<User> attribute into the Machine 1 Inheritance between two model classes encodes UML generalization. Java does not support multiple inheritance, which is currently a limitation of txtUML. class instead of the explicit definition of the association is invalid: Selecting the concrete collection type is an optimization issue and should not be part of the abstract model. The techniques to be discussed in Section 7.2 can rule out the violations of these rules, including constraints specified in the UML standard.
Using an embedded language in Java makes model descriptions a bit more verbose than tailor-made custom syntax. This is a moderate price for familiar syntax and the possibility of model execution and debugging with existing tools. 4
A model, defined using the API introduced above, can be compiled, run and
debugged as any Java application. Figure 3 shows a debugging session executing
the example used in Section 3. A breakpoint, set on the signal sending
instruction of the doWork method, is being hit. It is possible to inspect the threads
that belong to the active object instances, the attributes of these instances, in
particular the current state of the machine instance. When stepping over the
send instruction in the debugger, the developer can verify that the state changes
from off to on.
Discussing the execution semantics behind our implementation is far beyond
the scope of this paper. We summarize our approach as follows: We start from
the constructs in the xtUML modeling language [
Even if our proposal is a textual modeling language, we consider visualization
an extremely important aspect. Graphical representation of system architecture
and behavior makes it easier to understand large systems. The advantage of
our approach is that we have the possibility to reuse any UML editor or viewer
tool for model visualization by generating the persistency format of the selected
tool. We use the Ecore based implementation of UML2 as our internal model
representation that gives us Papyrus-compatible [
Note, however, that automatically laid out diagrams are far from perfect, because the position of model elements and their relative distance in a hand-drawn diagram also carries information. For example, the class representing the most important concept is usually placed in the middle of a class diagram. Closely related classes are drawn close to each other, while marginal or technical associations can be long broken lines. Our plan is to extend the embedded language with constructs to define the relative placement of model elements. For example, one could specify that the User class has to be displayed next to the class Machine, on its right hand side. This is definitely an important future work in our project.
Figure 4 shows the Papyrus editor showing our example model. The treeview of the model in the Model Explorer on the left hand side is automatically loaded when opening the model persisted by our API. The class diagram on the right-hand side can be created by manually dragging the classes from the Model Explorer onto the diagram.
The toolchain of executable modeling is completed by the model compiler that turns a model into a program in a given implementation language (C++, Java, etc.) optimized towards a selected platform and runtime libraries. Our implementation includes a prototype model compiler generating C++. For example, let us show a fragment of the generated code for the example used throughout the paper: struct Machine { std::vector<User*> userOfMachine; enum state { state_Init, state_Off, state_On }; state current_state; /* ... */ };
The association between the machine and its users results in the member called userOfMachine in the machine class. Since the multiplicity of this end of the association is @Many, a vector of pointers to user objects is generated. Note, that the compiler is free to choose a different collection type for optimization reasons. In particular, this member can be omitted if the association is never used to navigate from machines to users. The states of the machine are represented by the enumeration type state and the current_state member is responsible for storing the actual state in runtime.
Section 5 revealed that we use the Ecore-based UML2 implementation as the internal representation of the models. The model compiler’s task is to query the model via the UML2 API and turn its elements C++ to code.
Execution semantics of the model are captured by the implementation of our API, introduced in Section 3. The interesting bit of this implementation is the asynchronous communication between object instances. Any modeled class has to inherit from ModelClass. Its constructor creates a Java thread for all the instances2. Each thread has a mailbox of type LinkedBlockingQueue<Signal> that other instances can put signals in asynchronously. The threads run the following loop: while (true) {
Signal signal = mailbox.take(); parent.processSignal(signal); } 2 This is the reason to use inheritance to mark classes belonging to the model.
That is, they are polling their mailboxes for incoming signals and propagate those to their object instances (parent) for processing. The processSignal method implements the runtime semantics of state machines. Note that the take method blocks the thread if the mailbox is empty, therefore no busy-waiting is involved. When the object instance is deleted, its thread is interrupted, leading to an InterruptedException that stops the loop above. 7.2
Both visualization and model compilation requires a representation of models that can be queried and transformed to graphics or text. In our case this representation is the Ecore-based implementation of UML2.
Using Java reflection, it is possible to get information about the static structure of Java code. For example, in case of the Machine class, we iterate through its attributes and member functions to find out the attributes and operations to be added to the model representation via the UML2 API. Then, the enclosed classes are examined, if they inherit from State or Transition in order to add the state machine of this class to the model.
Java reflection is unable to look into method bodies, but it is possible to call methods via the reflection API. However, simply calling the methods found eg. in states or transitions would not help in building model representation, since the instructions inside these methods implement the runtime semantics of the model. For this reason, we use AspectJ, an aspect-oriented extension to Java. For example, the following AspectJ code fragment replaces all method calls on instances of ModelClass with code that adds the corresponding call operation element to the model: Object around(ModelClass target): call(* *(..)) && target(target) { return Importer.call(target, thisJoinPoint.getSignature().getName(), thisJoinPoint.getArgs()); } 8
In this paper we presented txtUML, which is an executable UML language embedded in Java. Our main contributions are the following: – A novel textual UML modeling method that makes model-level execution and debugging possible by reusing the Java runtime environment and Java debuggers. – Application of Java reflection and AspectJ for creating model representation that can be used for visualization and model compilation.
– Prototype implementation of the framework.
Using a mainstream programming language provides easy integration to existing toolchains, while reusing its execution environment and debuggers reduces the implementation effort needed to create a framework for executable UML.