User Tools

Site Tools


v070:userguide

This is an old revision of the document!


User Guide for version 0.7.0

Release notes, reporting bugs

Installation

Sample models

For a quick start we recommend experimenting with the sample models.

  • Download and unzip the sample models.
  • Import them into your Eclipse workspace (File / Import / General / Existing projects into workspace).
  • Clean and build the projects (Project / Clean…).

Sample models are implemented using either XtxtUML syntax (see the source packages <name of example>.x.model) or JtxtUML syntax (see the source packages <name of example>.j.model), or both. You can try the provided examples by running the accompanying Demo.java files. In addition, most models come with diagrams you can visualize (folder diagrams), tests you can check the model against (folder tests), and configuration and main files you can use to export and run the model in C++ (folder cpp).

In this version of txtUML, sample models are packaged together with the txtUML standard library. Currently, it contains predefined models for timing, doing advanced math calculations and communicating with the outside world. If you want to use its features, you have to manually import the downloaded hu.elte.txtuml.api.stdlib project into the modeling workspace.

We suggest reading the Generating diagrams and the Running and debugging models sections as the next steps of experimenting with the sample models.


Creating own models

New txtUML project

txtUML models should be placed in txtUML projects. A new txtUML project can be created by selecting File / New project… / txtUML / txtUML Project and setting the project name.

By default, the project will be created in the current workspace. In order to override this, uncheck the Use default location checkbox and select a location for the new project. If you want to use the features of the txtUML standard library (currently: timing, doing advanced math calculations and communicating with the outside world), you can check the Add hu.elte.txtuml.api.stdlib to the classpath checkbox to automatically set the classpath of the new project accordingly. Please note that even in this case, you still have to make sure the standard library is present in the workspace afterwards.

New txtUML model

Select File / New / Other… / txtUML / txtUML Model.

Select a Source folder from an existing project for the new model. Select an existing Package from that folder or type a new Package name. Type a Name for the new model.

Select the syntax of the new model:

  • XtxtUML for custom modelling syntax.
  • JtxtUML for Java syntax.

Both XtxtUML and JtxtUML models can be connected with Java code, can be run and debugged, and used as a source for Papyrus UML model generation.

A txtUML model is a package with

  • either a package-info.java file (in case of JtxtUML), where the package has an annotation of the form @Model(“ModelName”)1) annotation,
  • or a package-info.xtxtuml file (in case of XtxtUML), which has a model declaration of the form model-package example.x.model as “ModelName”;.

All files in this package (and its subpackages) are part of the model. The wizard described above creates one of these files depending on the XtxtUML/JtxtUML selection.

New model elements

For XtxtUML syntax, select File / New / Other… / txtUML / XtxtUML File. Fill in the source folder and package to place the new source file in, then enter a file name. You can also choose between the two possible extensions: .xtxtuml or .txtuml.

For JtxtUML syntax, select File / New / Class to create a new Java class.

See the Language Guide for the syntax of the different model elements in JtxtUML and XtxtUML.


Modeling language

See the Language Guide to study the txtUML language both in Java syntax (JtxtUML) and in custom syntax (XtxtUML). In case of JtxtUML, the JavaDoc of the API can also be used.


Generating diagrams

It is possible to generate EMF-UML2 models together with either JavaScript2) or Papyrus diagrams from txtUML models.

Currently class and state machine diagrams can be generated. Content and layout of the class diagrams and flat state machine diagrams can be defined by textual diagram descriptions. (Support for hierarchical diagrams is coming in a later release.)

The following simple example assumes classes A, B, C and D in the model. We create a class diagram where classes A, B and C are in a row, and class D is below B. Diagram definitions can be written using a Java API. See the Diagram Language Guide for a detailed description.

Our example diagram can be defined as follows:

public class ExampleDiagram extends ClassDiagram {
  @Row({A.class, B.class, C.class})
  @Below(val = D.class, from = B.class)
  class ExampleLayout extends Layout {}
}

To generate diagrams, select either Generate JavaScript diagrams from txtUML or Generate Papyrus diagrams from txtUML from the menu bar.

Diagram descriptions are grouped by projects. You can select several descriptions – if the descriptions are related to different models, a separate diagram group will be generated for each individual model. In our example, there is only one selected.

Generating JavaScript Diagrams

After choosing Finish, a folder named js is generated with the needed contents and the class diagram is automatically opened in your default browser.

The JavaScript user interface

The diagram will look something like this in your browser:

The Graphical User Interface consists of the diagram itself and three panels. Each panel can be collapsed and expanded by clicking on its label.

The panels contain the following controls:

Diagnostics:

  • a switch for toggling diagnostics mode
  • input for the port where diagnostics information is provided
  • see Animation in JavaScript for details

Diagram list:

  • a list of all class and state machine diagrams available
  • switch the displayed diagram by clicking on one in this list

Controls:

  • controls for the displayed diagram
  • + and - zooms in and out, respectively
  • Reset view resets the diagram into its original position and magnification
    • modifications to the diagram remain
  • Edit/Pan toggles whether dragging with the mouse moves the whole diagram, or only individual elements of it
  • Wheel zoom:
    • if switched on, the mouse wheel zooms in and out, centered on the cursor
    • if switched off, the mouse wheel scrolls the page

As mentioned above, you can also use the mouse to pan the diagram around when the Edit/Pan switch is set to Pan, or edit elements of the diagram when it is set to Edit. Zooming is also possible with the mouse wheel while the Wheel zoom button is toggled on.

Generating Papyrus Diagrams

After choosing Finish, a Papyrus model is generated with the following class diagram:

Generating Diagrams from a context menu

Diagrams can be generated from a context menu as well, either in the Project Explorer or in the Package Explorer. Simply right click on a diagram description .java file (you can select several descriptions too) and choose the corresponding entry.

As a result, a wizard opens with the chosen diagrams preselected.


Running and debugging models

The following hold both for XtxtUML and JtxtUML.

Executing models

txtUML models can be run as Java applications with the help of a model executor. This guide covers the basic usage of the default model executor which is part of the txtUML modeling API. While it is possible to write custom model executors, the default one will be sufficient in most cases.

Model executors can be managed through the ModelExecutor interface in the hu.elte.txtuml.api.model.execution package. This interface has two static create methods to instantiate the default executor. The first is without parameters while the second one takes a single String argument as an optional name for the new executor instance. This name will appear in the automatic logs.

In the simplest case, a main Java class that solely executes a model would look like this:

public class Tester {
  public static void main(String[] args) {
    ModelExecutor.create().run( () -> {
      MyClass instance = Action.create(MyClass.class);
      Action.start(instance);
      Action.send(new MySignal(), instance);
      // ...
    });
  }
}

The run method takes a Runnable instance, the initialization of the model execution which should create, link, start and send signals to the model objects which are required at the beginning of the model execution. This initialization code will run as part of the model, so any action that is allowed in the model is also allowed here.

The model executor writes log messages to the console and to a log file. Runtime errors and warnings are always logged but there is an optional trace logging which reports all important events during the model execution, for example, when a state machine of a model object leaves or enters a state. This trace logging is switched off by default but can be switched on with the setTraceLogging method. It is important to call this method before starting the model execution with the run method as it will fail with an exception otherwise.

ModelExecutor.create().setTraceLogging(true).run( () -> {
  // ...
});

This knowledge about model executors is more than enough to test your first models but if you wish to use them in a complex Java application (for example, if you would like to create a UI through which users may communicate with your model), you have to keep in mind some fundamentals of txtUML model execution.

The most important thing to know is that models always run on their own thread(s) – created and managed by the model executor – and not on the thread on which you create the model executor instance. However, most required synchronization can be easily done with methods of the ModelExecutor interface.

The fastest and most basic way to start model execution is with the start(Runnable) method, which creates a new model executor thread, starts the execution on it by calling the initialization code, and returns instantly. This is useful, for example, if you wish to start the execution of the model and later the model connects itself to a UI through external classes (classes that are part of the model but can contain plain Java code in their methods). Keep in mind, however, that any method of an external class called by model objects will be run on a model executor thread and if you wish to access other threads from that code, you will need to manually synchronize with the tools of Java.

If you want to make sure that the model has been initialized (that is, the initialization code has been executed), you can call the awaitInitialization() method of the executor. It is useful, for example, when you need references to model objects to send signals to them from a UI, and you need to be sure that some fields are filled with value.

public class Tester {
 
  private static MyClass instance;
 
  public static void main(String[] args) {
    ModelExecutor.create().start( () -> {
      instance = Action.create(MyClass.class);
      Action.start(instance);
      // ...
    }).awaitInitialization();
    API.send(new MySignal(), instance);
    // this call is safe, instance is guaranteed to be non-null here
  }
}

Note that outside the initialization code, we used the API.send method instead of Action.send. This is important, as only the methods provided by the API class are thread-safe and therefore only these should be used from outside model code. Calling methods and accessing fields of model objects outside model code is also unsafe.

A convenience method is provided for the common start(Runnable).awaitInitialization() call, this is launch(Runnable).

Another important fundamental of model execution is that it keeps waiting for signals even when it is out of work. This is needed, for example, as one may wish to send signals from a UI long after all previously sent signals have been processed. When it is intended to finish model execution, the method shutdown() should be called. Then the model executor will continue running while it still has any work to do (any signals to process) but when it is out of signals, it will terminate. Calling shutdown() is therefore almost always followed by calling awaitTermination().

public class Tester {
  public static void main(String[] args) {
    ModelExecutor.create().start( () -> {
      MyClass instance = Action.create(MyClass.class);
      Action.start(instance);
      // ...
    }).shutdown().awaitTermination();
    System.out.println("Model execution terminated.");
  }
}

The start(Runnable).shutdown().awaitTermination() call chain also has a convenience method, that is the previously introduced run(Runnable) method.

For all available execution options, see the JavaDoc of the ModelExecutor interface.

Debugging

Switch to Java or Debug perspective and create a new run/debug configuration. Use Java Application type if you want to run or debug the model only in text. Use txtUML Application type if state machine animation is required as well.

Breakpoints can be created and managed the same way as for Java programs. The standard debug controls (stop, pause, resume, step, step-into) work as usual.

The variable view can show the current signal, current state, associations and the attribute values of the actual object.


State machine animation

txtUML can animate state machine diagrams generated by the txtUML visualization process. During the animation, the current state and currently executed transition gets highlighted. Make sure that the run/debug configuration is of txtUML Application type.

For each state machine diagram, the state changes of the first activated object of the corresponding type will be highlighted. An expected later improvement will make it possible to select the object to be animated during the debug session.

Animation in JavaScript

Open the generated diagram in your preferred browser. You can find the debugging control in the top-left corner.

Start the model either in run or in debug mode. A message will appear on the console with the ports through which the diagnostics information will be provided.

Copy the HTTP port number into the Diagnostics port input in your browser.

If there is no debugging information available, a warning will be displayed. Once the connection is (re-)estabilished, the animation will begin/resume.

Animation in Papyrus

Open the generated Papyrus diagram and start the model either in run or in debug mode. The current state and currently executed transition gets highlighted.


Testing with sequence diagrams

See the Sequence diagram language guide to study how to define sequence diagrams.

txtUML models can be tested with sequence diagrams. You can run the model in parallel with a sequence diagram and check if the signals in the model are being sent in the same order you specified on the diagram. You can also assert states of the model objects.

Sequence diagrams can be run with a sequence diagram executor. During the execution, each time a signal is processed, the executor checks whether the next signal in the sequence diagram is equal to the processed signal. If the signals differ, an error is logged. Signals in fromActor expectations are actually sent by the sequence diagram executor, while signals between objects are only checked.

The following example assumes classes A, B, C, one instance of each class as a, b, c and a Signal class called Sig. The first signal in the diagram is from the actor to a. The second is from a to b and the third is from b to c. At the end of the execution, we expect object c to be in state Finished (a state of class C).

public class ExampleSequenceDiagram extends SequenceDiagram {
  @Position(1)
  A a;
 
  @Position(2)
  B b;
 
  @Position(3)
  C c;
 
  @Override
  public void initialize() {
    a = Action.create(A.class);
    b = Action.create(B.class);
    c = Action.create(C.class);
 
    Action.link(AToB.a.class, a, AToB.b.class, b);
    Action.link(BToC.b.class, b, BToC.c.class, c);
 
    Action.start(a);
    Action.start(b);
    Action.start(c);
  }
 
  @Override
  public void run() {
    Sequence.fromActor(new Sig(), a);
    Sequence.send(a, new Sig(), b);
    Sequence.send(b, new Sig(), c);
    Sequence.assertState(c, C.Finished.class);
  }
}

Generating sequence diagrams

To generate sequence diagrams, select txtUML and Generate sequence diagrams from txtUML in the menu bar.

After clicking Finish, a PlantUML diagram is generated.

Running and generating sequence diagrams from the context menu

You can run a sequence diagram by right clicking on its .java file in the project explorer or the package explorer and selecting Run sequence diagram. The result will be printed out in a console in Eclipse.

A PlantUML diagram can be generated by selecting Visualize sequence diagram….

As a result, a wizard opens with the chosen diagrams preselected.

Running sequence diagrams from code

There is also a possibility to run a sequence diagram from code, as the following example shows.

public class Tester {
  public static void main(String[] args) {
    SequenceDiagramExecutor executor = SequenceDiagramExecutor.create();
    executor.setDiagram(new ExampleSequenceDiagram());
    executor.run();
    executor.getErrors().forEach(error -> System.out.println(error.getMessage()));
  }
}

Compilation to C++

To generate C++ code from a txtUML model, you have to define a deployment configuration. A deployment configuration is a description of how model objects will be distributed across different threads. The deployment configuration is a special class which is derived from the Configuration base class. The model classes can be grouped together and these groups can be configured as described below. The events that arrive for classes which belong to the same group will be served by a configured thread pool.

You can group by the help of annotation Group which contains the following configuration options:

  • contains: You can enumerate the classes which belong to this group.
  • constant: It determines how many threads will be created regardless of the number of object instances. It must be a natural number. Its default value is 1.
  • gradient: It determines how many threads will be created (in addition to the number of constant threads) depending on the number of objects. It represents a linear coefficient, that is, the number of additionally created threads is gradient ⋅ n, where n is the number of created objects. It can be a real number between 0.0 and 1.0. Its default value is 0.
  • max: It determines how many threads will be created at most. It must be a natural number. Its default value is determined by the value of constant.

If there are classes with no groups aligned to them, a default implicit group will be created which contains these classes. It will be configured with the default values shown above.

Configuration examples

class DefaultConfiguration extends Configuration {}

This means that all of the classes will be grouped in the default group.

@Group(contains = {A.class, B.class}, max = 10, constant = 2, gradient = 0.5)
@Group(contains = {C.class})
class ExampleConfiguration extends Configuration {}

This means that instances of classes A and B are served by the same thread pool, which contains two constant threads plus one for every 2 A or B instances created, but no more than 10. Instances of class C are served by another thread pool and it contains only one thread (according to the default values).

We suggest reviewing the deployment configurations in the demo projects.

Generating C++ from txtUML

The C++ model compiler can be reached by selecting the txtUML / Generate C++ code from txtUML menu.

The txtUML deployment configuration must be specified. For convenience, you can also select whether you want the default C++ model execution runtime to be copied next to the generated files.

When you specified the deployment configuration, the Next button is going to be clickable. When you click the Next button, you will be led to a new page where you can set additional compilation options.

Firstly, you can select a new main.cpp file to be placed in the model-specific output folder right away. If a main file already exists in this folder, it will be overwritten.

On the second line, you can select build environments you want the generated files to be prepared for. Please note that in this case, CMake and the selected build environments should be installed in your system. See section Building the generated code for additional details.

In case of a successful export, the generated C++ code is saved in a folder named after the fully qualified identifier of the exported model, placed inside the cpp-gen folder of its enclosing project. Moreover, if you have specified build environments as well, additional files related to the environments are created in separate, build_ prefixed subfolders. Note that you might have to refresh the project in Eclipse, so that the newly generated files become visible in the workspace.

Building the generated code

Compiling the exported C++ files can be achieved in multiple ways.

  • If you select specific build environments during the code generation phase, you can conveniently use these environments on the automatically prepared files placed in the build_ prefixed output folders.
  • Using the generated CMakeLists file, you can create these environment-specific “make files” manually, which then you can feed to the chosen build environments.
  • If all else fails, you can also build from the generated files with any C++ compiler manually.

In the remaining part of this section we elaborate the CMake-based, semi-automatic compilation method. CMake is available from https://cmake.org/. It is recommended to create a new folder next to the generated files, where the build environment should be created. The compilation can be performed by the following command:

cmake -G <environment> -D CMAKE_BUILD_TYPE=<type> <path>

Where the parameters mean the following:

  • <environment>: The chosen build environment. You can use the cmake --help command to list the possible build environments.
  • <type>: The type of the build. Can be Debug or Release.
  • <path>: The relative path to the generated CMakeLists file.

A concrete example:

cmake -G "MinGW Makefiles" -D CMAKE_BUILD_TYPE=Release ..

C++ model execution runtime

The C++ model execution runtime is the C++ counterpart of the Java-based JtxtUML model executor. The runtime library consists of pre-written .cpp files so they can be used for other generated models too.

Using the C++ runtime, a concrete model execution is represented by a function. In this function, at first you have to initialize the execution environment with the Env::initEnvironment() call, for which you have to include Env.hpp. After this you can get a handle for the used runtime instance by calling UsedRuntimeType::getRuntimeInstance() from deployment.hpp, where the type of the returned pointer is UsedRuntimePtr. Depending on the runtime type specified in the source deployment configuration, the flow of execution is the following:

  • Single threaded runtime (RuntimeType.SINGLE): The execution is carried out sequentially once startRT() is called on the runtime instance. The execution stops when there are no more signals in the processing queue. Function startRT() is blocking, it returns when the execution terminates. As a result, initialization should happen before starting the runtime.
  • Multithreaded runtime (RuntimeType.THREADED): The execution runs in parallel with the initialization once startRT() is called on the runtime instance. In this case, this call is not blocking. You have to manually specify if you want to terminate the execution by calling stopUponCompletion() on the runtime instance.

In the following we present concrete usage examples, but you can also consult the C++ Runtime API documentation and the main.cpp files provided with the demo models.

Warning! When the generated model is used by an external component, the model objects should be allocated on the heap. The reason for this is that objects can be deallocated inside the model. Please note that main.cpp files provided with the demo models only allocate objects in the stack to keep the examples as simple as possible – the place of allocation should be considered carefully in real-life projects.

Referring to exported entities

The fully qualified names of source model entities are flattened into namespace Model in the exported files. For example, a source model class named A should be referred to as Model::A, regardless of its original fully qualified name. Depending on the kind of the source element, referencing can be done in the following way:

  • Classes: A source class named A can be referred to as Model::A in the execution initialization function. In this case, A.hpp has to be included.
  • Ports: A source port named A.P on class instance a can be referred to as a→P in the execution initialization function. In this case, A.hpp has to be included.
  • Signals: An instance of a signal named S can be referred to / constructed as Model::SPtr(new Model::S_EC(<ctor args>)) in the execution initialization function. In this case, EventStructures.hpp has to be included.
  • Association, composition and connector ends: A source association/composition/connector end named A.e can be referred to as Model::A.e in the execution initialization function. In this case, AssociationInstances.hpp has to be included.
Action language

The action language provided in C++ is analogous to the original Java version (see Action code for more detailed semantics). To use action the Action::-prefixed language elements below, you have to include runtime/Action.hpp.

Action::send(sig, obj);
Action::start(obj);
Action::deleteObject(obj);
Action::link(AB.a, objA, AB.b, objB);
MultipliedElement<B, 0, -1> objBs = a.assoc(AB.b);
  // MultipliedElement<T, L, U> means:
  //   a collection of Ts with multiplicity L..U
  //   where infinity is represented by (-1).
  // Include 'runtime/ESRoot/Elements.hpp' for direct use.
// delegate connect
delegateConnect(objA.PortAP, Conn.bp, objB.PortBP);
 
// assembly connect
assemblyConnect(Conn.ap, objA.PortAP, Conn.bp, objB.PortBP);
1) Fully qualified name: hu.elte.txtuml.api.model.Model
2) Based on JointJS.
v070/userguide.1538760566.txt.gz · Last modified: 2018/10/05 19:29 by djnemeth