User Tools

Site Tools


v070:userguide

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
v070:userguide [2018/10/05 17:05]
djnemeth [Compilation to C++]
v070:userguide [2018/10/08 22:31]
djnemeth [Generating diagrams]
Line 17: Line 17:
  
   * Download and unzip the {{v070:​demo.zip|sample models}}.   * Download and unzip the {{v070:​demo.zip|sample models}}.
-  * Import them into your Eclipse workspace (''​File''​ / ''​Import''​ / ''​General''​ / ''​Existing ​projects ​into workspace''​).+  * Import them into your Eclipse workspace (''​File''​ / ''​Import...''​ / ''​General''​ / ''​Existing ​Projects ​into Workspace''​).
   * Clean and build the projects (''​Project''​ / ''​Clean...''​).   * Clean and build the projects (''​Project''​ / ''​Clean...''​).
  
Line 47: Line 47:
   * ''​XtxtUML''​ for custom modelling syntax.   * ''​XtxtUML''​ for custom modelling syntax.
   * ''​JtxtUML''​ for Java 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.+Both XtxtUML and JtxtUML models can be connected with Java code, can be run and debugged, and used as a source for UML2 model generation.
  
 A txtUML model is a package with 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"​)''​((Fully qualified name: ''​hu.elte.txtuml.api.model.Model''​)) ​annotation,+  * either a ''​package-info.java''​ file (in case of JtxtUML), where the package has an annotation of the form ''​@Model("​ModelName"​)''​((Fully qualified name: ''​hu.elte.txtuml.api.model.Model''​)),​
   * 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";''​.   * 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. 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.
Line 60: Line 60:
  
 For JtxtUML syntax, select ''​File''​ / ''​New''​ / ''​Class''​ to create a new Java class. For JtxtUML syntax, select ''​File''​ / ''​New''​ / ''​Class''​ to create a new Java class.
- 
-See the [[v070:​language|Language Guide]] for the syntax of the different model elements in JtxtUML and XtxtUML. 
  
 ---- ----
Line 67: Line 65:
 ==== Modeling language ==== ==== Modeling language ====
  
-See the [[v070:language|Language ​Guide]] to study the txtUML language both in Java syntax (JtxtUML) and in custom syntax (XtxtUML). In case of JtxtUML, the [[http://​txtuml.inf.elte.hu/​releases/​txtuml-v070/​api/​java/​|JavaDoc]] of the API can also be used.+See the [[v070:modeling|Modeling ​Language ​Description]] to study the txtUML language both in Java syntax (JtxtUML) and in custom syntax (XtxtUML). In case of JtxtUML, the [[http://​txtuml.inf.elte.hu/​releases/​txtuml-v070/​api/​java/​|JavaDoc]] of the API can also be used.
  
 ---- ----
Line 77: Line 75:
 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 [[https://​github.com/​ELTE-Soft/​txtUML/​issues/​214|hierarchical diagrams]] is coming in a later release.) 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 [[https://​github.com/​ELTE-Soft/​txtUML/​issues/​214|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 [[v070:layout|Diagram Language ​Guide]] for a detailed description.+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 [[v070:diagrams|Diagram Language ​Description]] for a comprehensive guide.
  
 Our example diagram can be defined as follows: Our example diagram can be defined as follows:
  
-<​code>​+<​code ​java>
 public class ExampleDiagram extends ClassDiagram { public class ExampleDiagram extends ClassDiagram {
   @Row({A.class,​ B.class, C.class})   @Row({A.class,​ B.class, C.class})
Line 111: Line 109:
   * a switch for toggling diagnostics mode   * a switch for toggling diagnostics mode
   * input for the port where diagnostics information is provided   * input for the port where diagnostics information is provided
-  * see [[v070:​userguide#​Animation in JavaScript]] for details+  * see section ​[[v070:​userguide#​Animation in JavaScript]] for details
 **Diagram list**: **Diagram list**:
   * a list of all class and state machine diagrams available   * a list of all class and state machine diagrams available
Line 149: Line 147:
 === Executing models === === 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 APIWhile it is possible to write custom ​model executors, the default one will be sufficient in most cases.+txtUML models can be run as Java applications. The simplest way to run txtUML model is to implement the [[http://​txtuml.inf.elte.hu/​releases/​txtuml-v070/​api/​java/​hu/​elte/​txtuml/​api/model/execution/Execution.html|Execution]] interface, whose sole abstract method can be used as the ''​initialization()'' ​of the model executionThat is, it should contain the model code which createslinks and starts ​the model class instances that should exist at the beginning of the execution.
  
-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.+After the ''​initialization()'' ​method is implemented,​ there are three possible ways to run the execution:​ 
 +  * instantiate ​the implementor class and call its ''​run()'' ​method, or 
 +  * call the static ''​run(Class)'' ​method with the implementor class as its parameter, or 
 +  * let the ''​Execution'' ​interface be the main type of a Java program and provide the fully qualified ​name of the implementor class as a command line argument to it.
  
-In the simplest case, a main Java class that solely executes a model would look like this:+In the simplest case, a Java class that solely executes a model would look like this:
  
 <code java> <code java>
-public class Tester {+public class Tester ​implements Execution ​{ 
 +  @Override 
 +  public void initialization() { 
 +    MyClass instance = Action.create(MyClass.class);​ 
 +    Action.start(instance);​ 
 +    Action.send(new MySignal(), instance);​ 
 +    // ... 
 +  } 
   public static void main(String[] args) {   public static void main(String[] args) {
-    ​ModelExecutor.create().run( ​() -> { +    ​new Tester().run();
-      MyClass instance = Action.create(MyClass.class);​ +
-      Action.start(instance);​ +
-      Action.send(new MySignal(), instance);​ +
-      // ... +
-    });+
   }   }
 } }
 </​code>​ </​code>​
  
-The ''​run'' ​method takes a ''​Runnable'' ​instancethe //​initialization//​ of the model execution ​which should createlink, 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.+For a bit more complicated cases, other methods of the ''​Execution''​ interface might be overridden as well. The ''​before()''​''​during()'' ​and ''​after()''​ are executed beforein parallel with, and after the model execution, ​respectively. The ''​name()''​ method can be used to give a name to the execution ​which will then appear in logs. The ''​configure(Settings)''​ method makes it possible to alter the basic settings ​of the execution. ​See the documentation ​of the [[http://​txtuml.inf.elte.hu/​releases/​txtuml-v070/​api/​java/​hu/​elte/​txtuml/​api/​model/​execution/​Execution.Settings.html|Execution.Settings]] class for details about these settings.
  
-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 stateThis 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 [[http://​txtuml.inf.elte.hu/​releases/​txtuml-v070/​api/​java/​hu/​elte/​txtuml/​api/​model/​execution/​LockedModelExecutorException.html|exception]] otherwise.+It is important to know 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 execution/executor instanceFrom the previously mentioned methods of the ''​Execution'' ​interface, only ''​initialization()''​ runs on the same thread as the model
 + 
 +A more complex example using several features of the ''​Execution''​ interface:
  
 <code java> <code java>
-ModelExecutor.create().setTraceLogging(true).run( () -> +public class Tester implements Execution ​
-  ​// ... +  ​MyClass instance;
-}); +
-</​code>​+
  
-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.+  @Override 
 +  public String name() { 
 +    // this name will appear ​in logs 
 +    return "​SampleExecution";​ 
 +  } 
 +   
 +  @Override 
 +  public void configure(Settings s) { 
 +    // set the log level 
 +    s.logLevel = LogLevel.TRACE;​ 
 +  } 
 +   
 +  @Override 
 +  public void before() { 
 +    // on the main thread 
 +    // acquire resources... 
 +  } 
 +   
 +  @Override 
 +  public void initialization() { 
 +    // on the executor thread 
 +    instance = Action.create(MyClass.class);​ 
 +    Action.start(instance);​ 
 +    Action.send(new MySignal(), instance);​ 
 +    // create, link, start, send... 
 +  }
  
-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 instanceHowever, most required synchronization can be easily done with methods of the ''​ModelExecutor''​ interface.+  @Override 
 +  public void during() 
 +    // on the main thread 
 +    // communicate with the model from outside..
 +    while (/* ... */) { 
 +      API.send(new MySignal(), instance);​ 
 +    } 
 +  }
  
-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. +  @Override 
- +  public void after() 
-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 executorIt 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. +    // on the main thread 
- +    // release resources... 
-<code java> +  ​}
-public class Tester { +
-  +
-  ​private static MyClass instance;+
  
   public static void main(String[] args) {   public static void main(String[] args) {
-    ​ModelExecutor.create().start() -> { +    ​new Tester().run();
-      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+
   }   }
 } }
Line 205: Line 232:
 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. 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)''​+For even more sophisticated cases, ​the ''​start()'' ​method can be called instead of ''​run()'' ​which lets the execution ​run indefinitely but returns ​special ''​Execution.Handle''​ object which provides access ​to the (base) model executor ​that runs the execution ​(for external libraries ​to useand also a method which initiates and awaits the termination ​of the execution.
- +
-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 UI long after all previously sent signals have been processedWhen 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 processbut when it is out of signals, it will terminate. Calling ''​shutdown()''​ is therefore almost always followed by calling ''​awaitTermination()''​. +
- +
-<code java> +
-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."); +
-  } +
-+
-</​code>​+
  
-The ''​start(Runnable).shutdown().awaitTermination()'' ​call chain also has a convenience method, that is the previously introduced ​''​run(Runnable)'' ​method.+Note that the ''​run()'' ​and ''​start()'' ​methods of this interface are not intended to be overridden.
  
-For all available execution optionssee the [[http://​txtuml.inf.elte.hu/​releases/​txtuml-v070/​api/​java/​hu/​elte/​txtuml/​api/​model/​execution/​ModelExecutor.html|JavaDoc]] of the ''​ModelExecutor''​ interface.+If the features provided by this interface are not satisfactoryplease use the more detailed and advanced ​[[http://​txtuml.inf.elte.hu/​releases/​txtuml-v070/​api/​java/​hu/​elte/​txtuml/​api/​model/​execution/​ModelExecutor.html|ModelExecutor]] interface (which is used by the ''​run()'' ​and ''​start()''​ methods of this interface ​as well)
  
 === Debugging === === Debugging ===
Line 256: Line 268:
 {{v070:​DiagramAnimationPorts.png}} {{v070:​DiagramAnimationPorts.png}}
  
-Copy the //HTTP port// number into the //​Diagnostics port// input in your browser.+Copy the //HTTP port// number into the //​Diagnostics port// input in your browser ​and switch on diagnostics.
  
 {{v070:​DiagramAnimation.png}} {{v070:​DiagramAnimation.png}}
Line 274: Line 286:
 ==== Testing with sequence diagrams ==== ==== Testing with sequence diagrams ====
  
-See the [[v070:layout#​sequence_diagrams|Sequence ​diagram language guide]] to study how to define sequence diagrams.+See the [[v070:diagrams#​sequence_diagrams|Sequence ​Diagram Language Description]] 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. 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.
Line 357: Line 369:
  
 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. 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 deployment configuration is a special class which is derived from the [[http://​txtuml.inf.elte.hu/​releases/​txtuml-v070/​api/​java/​hu/​elte/​txtuml/​api/​deployment/​Configuration.html|Configuration]] ​base class. ​
 The model classes can be grouped together and these groups can be configured as described below. ​ 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. The events that arrive for classes which belong to the same group will be served by a configured thread pool.
Line 367: Line 379:
   * ''​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''​.   * ''​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. ​+If there are classes ​without a group assigned ​to them, a default implicit group will be created which contains ​all of these classes. It will be configured with the default values shown above. Please note, however, that – due to technical limitations – a configuration should contain at least one group definition with at least one class in it. 
 + 
 +Additionally,​ you can specify whether you want the exported model to be executed by a single threaded runtime instead of the default multithreaded one. This can be achieved by placing the ''​@Runtime(RuntimeType.SINGLE)''​ annotation on the configuration class. In this case, grouping is effectively ignored.
  
 === Configuration examples === === Configuration examples ===
  
 <code java> <code java>
-class DefaultConfiguration ​extends Configuration {}+@Runtime(RuntimeType.SINGLE) 
 +@Group(contains = {A.class}) 
 +class ExampleConfiguration ​extends Configuration {}
 </​code>​ </​code>​
  
-This means that all of the classes ​will be grouped ​in the default group.+This means that the single threaded runtime ​will be used. Here, grouping has no effect, but we defined one group with a class in it nevertheless,​ as this is currently required due to technical limitations.
  
 <code java> <code java>
Line 383: Line 399:
 </​code>​ </​code>​
  
-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).+In this example, the default multithreaded runtime is used. 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 {{v070:​demo.zip|demo projects}}. We suggest reviewing the deployment configurations in the {{v070:​demo.zip|demo projects}}.
Line 414: Line 430:
 Compiling the exported C++ files can be achieved in multiple ways. 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.+  * If you selected ​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.   * 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.   * If all else fails, you can also build from the generated files with any C++ compiler manually.
Line 421: Line 437:
 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: 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:
  
-<​code>​+<​code ​bash>
 cmake -G <​environment>​ -D CMAKE_BUILD_TYPE=<​type>​ <​path>​ cmake -G <​environment>​ -D CMAKE_BUILD_TYPE=<​type>​ <​path>​
 </​code>​ </​code>​
Line 432: Line 448:
 A concrete example: A concrete example:
  
-<​code>​+<​code ​bash>
 cmake -G "MinGW Makefiles"​ -D CMAKE_BUILD_TYPE=Release .. cmake -G "MinGW Makefiles"​ -D CMAKE_BUILD_TYPE=Release ..
 </​code>​ </​code>​
Line 446: Line 462:
 In the following we present concrete usage examples, but you can also consult the [[http://​txtuml.inf.elte.hu/​releases/​txtuml-v070/​api/​cpp/​|C++ Runtime API documentation]] and the //​main.cpp//​ files provided with the {{v070:​demo.zip|demo models}}. In the following we present concrete usage examples, but you can also consult the [[http://​txtuml.inf.elte.hu/​releases/​txtuml-v070/​api/​cpp/​|C++ Runtime API documentation]] and the //​main.cpp//​ files provided with the {{v070:​demo.zip|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.+**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 externally created ​objects can be deallocated inside the model. Please note that the //​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 == == 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:+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 ​ways:
  
   * **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.   * **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.+  * **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.   * **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.   * **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.
Line 459: Line 475:
 == Action language == == Action language ==
  
-The action language provided in C++ is analogous to the original Java version (see [[v070:language#Action code]] for more detailed semantics). To use action ​language elements, you have to include //​runtime/​Action.hpp//​.+The action language provided in C++ is analogous to the original Java version (see [[v070:modeling#Action code]] for more detailed semantics). To use the ''​Action::''​-prefixed ​language elements ​below, you have to include //​runtime/​Action.hpp//​.
  
 <code cpp> <code cpp>
Line 474: Line 490:
  
 <code cpp> <code cpp>
-Action::​link(AB.a, ​objA, AB.b, objB);+Action::​link(AB.a, ​instanceOfA, AB.b, instanceOfB);
 </​code>​ </​code>​
  
 <code cpp> <code cpp>
-// delegate connect +MultipliedElement<​B,​ 0, -1> bs = instanceOfA.assoc(AB.b);​ 
-delegateConnect(objA->PortAP, Conn.bp, objB->PortBP);+  ​// 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 
 +</code>
  
-// assembly connect +<code cpp> 
-assemblyConnect(Conn.apobjA->PortAP, Conn.bpobjB->PortBP);+delegateConnect(instanceOfA.PortAP,​ Conn.bpe, instanceOfB.PortBP);​ 
 +assemblyConnect(Conn.apeinstanceOfA.PortAP, Conn.bpeinstanceOfB.PortBP); 
 +  // include '​runtime/​PortUtils.hpp'​ for direct use
 </​code>​ </​code>​
v070/userguide.txt · Last modified: 2018/10/08 22:31 by djnemeth