The name txtUML stands for textual, executable, translatable UML. It is an Eclipse-based tool built on top of JDT, Xtext/Xbase and Papyrus UML. The tool is designed for textual model editing. This makes storage, version control, compare and merge processes, editing and searching easier and more e cient. The tool supports two textual syntaxes for modeling: the standalone syntax, which is designed to be clean and short, and alternatively, the txtUML Java API, which can be used to de ne models as standard Java programs. The tool supports the generation of graphical UML diagrams from the textual descriptions: class and state machine diagrams. The layout of the diagrams can be controlled by a simple textual diagram layout language. Models can be seamlessly integrated into Java programs: they can be executed and debugged. Generated state machine diagrams can be animated during model execution to further enhance comprehension of model dynamics. Compatibility with other tools is ensured by generating standard UML models in EMF-UML2 format. This representation is the input for our model compiler, which generates C++ code.
This demonstration presents the framework txtUML, which stands for textual,
executable, translatable UML. It is a tool for software development according to
the executable UML paradigm [
The project was started in 2014, and the development is done by the
ModelDriven Development Research Group of Eotvos Lorand University, Budapest.
It is open source [
This subsection presents open source UML tools with model execution capabilities or textual syntaxes.
BridgePoint [
Papyrus UML [
Alf [
Moliz [
Umple [
Textual modeling has many advantages over editing models in graphics [
The standalone syntax is easier to use, especially for users not familiar with Java. On the other hand, the Java syntax can be used in any Java development environment so that a project using this syntax will not depend on a new editor and a new language. The two syntactic variants are closely related: In fact, XtxtUML models are on-the- y translated to JtxtUML models while they are edited in Eclipse. This is the basis for model execution. signal ButtonPress ;
class ButtonPress extends Signal {} class Machine { initial Init ; state Off ; state On ; } } } } transition Initialize { from Init ; to Off ; transition SwitchOn { from Off ; to On ; trigger ButtonPress ; transition SwitchOff { from On ; to Off ; trigger ButtonPress ; class Machine extends ModelClass { class Init extends Initial {} class Off extends State {} class On extends State {} }
Fig. 1. Two syntactic variants of the txtUML language (Left: Standalone syntax, Right: Embedded language in Java) syntax, while the Java version uses inheritance from Signal, ModelClass and Transition. These classes are provided by the txtUML Java API. Properties of the transitions are expressed by Java annotations (e.g. @From) in Java, while attribute-like syntax with keywords (e.g. from) is used in the standalone version.
The txtUML language covers a subset of UML. We summarize the supported elements below: { Component modeling : Interfaces containing signals; ports; connectors { Class modeling : Classes with attributes and operations; simple binary associations; compositions; (single) inheritance { State modeling : Simple and composite states; transitions triggered by signals; guards; choice states { Behavior modeling : Action code can be written in operations of classes, entry and exit actions of states and e ects of transitions. Supported base types are int, double, boolean and String with the usual arithmetic and logic expressions, variables and assignment. Control structures (loops, branches), attribute access and operation calls are supported. UML-speci c actions: creation and deletion of objects; linkage and unlinkage via associations and connectors; reading links; sending signals; accessing signal data in entries, exits and e ects. 4
While textual modeling is practical for editing models, graphical diagrams are
better for understanding them. For this reason txtUML can generate standard
UML diagrams from the models in the format of the Papyrus UML
framework [
txtUML allows users to in uence the layout of the generated diagrams by textual diagram descriptions. A simple DSL, realized by Java annotations, is de ned for this purpose. The most important layout statements are the following: { @Above, @Below, @Left and @Right de ne that two given diagram elements are placed next to each other vertically or horizontally. { @North, @East, @South and @West place the two given diagram elements in two di erent half-plains of the diagram, but gives no further constrains on the distance of the elements. { @TopMost, @BottomMost, @EastMost and @WestMost place the given elements on the corresponding side of the diagram. { @Row, @Column and @Diamond can layout multiple elements at once in the given shape. { @Show declares that the given elements have to appear on the diagram, but gives no further constraint on their placement. } } class MicrowaveOven ; class Lamp ; class Magnetron ; composition LampsOfOven { container MicrowaveOven oven ; 1..* Lamp lamp ; composition MagnetronOfOven { container MicrowaveOven oven ; 1 Magnetron magnetron ;
No matter which syntactic variant of txtUML is selected to implement a model, it can be seamlessly integrated into Java programs. The txtUML Java API can be used to create objects of classes in the model, link them via the associations (if needed) and send signals to them. Such a Java main function, executing the (completed) model of Figure 2, is shown in Figure 4. public static void main ( String [] args ) {
ModelExecutor . Settings . setExecutorLog ( true ); MicrowaveOven oven = Action . create ( MicrowaveOven . class ); Action . start ( oven ); Action . send ( new DoorOpened () , oven ); Action . send ( new DoorClosed () , oven ); Action . send ( new Start () , oven ); Action . send ( new DoorOpened () , oven );
ModelExecutor . shutdown () ;
The usual Java debugging functionalities of Eclipse (breakpoints, stepping, viewing values of variables etc.) are available for txtUML model code as well, also for the standalone syntax. While the model is executed or debugged, it is possible to animate the generated state machine diagrams, as shown in Figure 5.
If the target platform is not compatible with Java, then model compilers have to be used. As the rst step of the transformation, we turn txtUML models into EMF-UML2 models, which is the de facto standard format of UML in the Eclipse environment. This can be used as platform-independent input for code generators.
The txtUML project includes a work-in-progress code generator for C++. It can generate single and multithreaded C++ programs, and users can con gure which classes of the model should run in which thread.