Configuring a generator

As mentioned above, all generators can be set up and customized by a generator model. The following screenshot shows a sample configuration for the Java code generator.

SGen generator model with default values

SGen generator model with default values

The following sections describe core features, which are available for all code generators. Individual code generators usually support specific additional features; please see the respective code generator documentation for details.

Outlet feature

The Outlet feature specifies target project and target folder for the generated artifacts. It is a required feature and has the following parameters:

  • targetProject (String, required): The project to write the generated artifacts to.
  • targetFolder (String, required): The folder within the target folder to write the generated artifacts to. If a library target folder (see below) is specified, only the model-dependent artifacts are generated in the target folder. All artifacts in this folder will be overwritten during re-generation.
  • libraryTargetFolder (String, optional): The folder to write the model-independent artifacts to. If this parameter is not specified, these artifacts will be generated in the target folder (see above). All artifacts in this folder will be preserved during re-generation. Manual modifications of these artifacts will not be overwritten upon re-generation.
  • apiTargetFolder (String, optional): The folder to write API code to, e.g., interfaces or header files. If this parameter is not specified, these artifacts will be generated in the target folder (see above).
  • skipLibraryFiles (Boolean, optional): If you wish to exclude the static files from the code generation, i.e., those that are put into the libraryTargetFolder, you can set this value to true. If the value is false or not specified at all, the files are generated as usual. Currently supported for the Java, C and C++ generators.

Example:

feature Outlet {
    targetProject = "SampleProject"
    targetFolder = "src-gen"
    libraryTargetFolder = "src"
    apiTargetFolder = "api-gen"
}

LicenseHeader feature

The LicenseHeader feature specifies the license text to be added as a header to the generated artifacts. It is an optional feature and has the following parameter:

  • licenseText (String, required): License text to be added as a file header

Example:

feature LicenseHeader {
    licenseText = "Copyright (c) 2017 committers of YAKINDU and others."
}

FunctionInlining feature

The FunctionInlining feature enables the inlining of expressions instead of generating separate functions or methods. This might reduce the readability of the generated code, but increases performance, because less operation calls are necessary. This is an optional feature and has the following parameters:

  • inlineReactions (Boolean, optional): inlines the expression for reactions
  • inlineEntryActions (Boolean, optional): inlines the expression for entry actions
  • inlineExitActions (Boolean, optional): inlines the expression for exit actions
  • inlineEnterSequences (Boolean, optional): inlines the expression for state-entering sequences
  • inlineExitSequences (Boolean, optional): inlines the expression for state-exiting sequences
  • inlineChoices (Boolean, optional): inlines the expression for choices
  • inlineEnterRegion (Boolean, optional): inlines the expression for region-entering sequences
  • inlineExitRegion (Boolean, optional): inlines the expression for region-exiting sequences
  • inlineEntries (Boolean, optional): inlines the expression for entries

ALl parameters of the FunctionInlining feature are false by default.

Example:

feature FunctionInlining {
    inlineChoices = false
    inlineEnterRegion = true
    inlineEntries = true
}

Debug feature

The Debug feature dumps the execution model to the target folder as an XMI model. It is an optional feature and has the following parameter:

  • dumpSexec (Boolean, required): dumps the execution model as XMI model (default: false)

Example:

feature Debug {
    dumpSexec = true
}

Using properties and expressions in generator models

An SGen generator model may assign values to properties and later use these properties in expressions. The following sample generator model uses the var keyword to declare the properties projectName, version, isBeta, and generateTimerService with their respective types and default values. The model then uses these values in feature clauses by referring to the properties:

GeneratorModel for yakindu::java {

    var projectName : string = "light_switch"
    var version : string = "1.0"
    var isBeta : boolean = true
    var generateTimerService : boolean = true

    statechart myStateAutomaton {

        feature Outlet {
            targetProject = projectName
            targetFolder = "src-gen/" + version + (isBeta ? "beta" : "")
            libraryTargetFolder = "src"
        }

        feature GeneralFeatures {
            TimerService = generateTimerServce
        }

    }
}

The syntax rules for expressions in generator models are the same as for statechart language expressions, see section "Expressions". However, expressions are constrained to a subset that semantically makes sense in the context of a generator model. That means that, for example, while you can use the + operator to concatenate strings, you cannot use statechart-related constructs like the after keyword or the active() built-in function.

In the properties definition section near the top of a generator model, a value assigned to a property must be given as a literal. More complex expressions are not supported there.

Built-in variables

There are several built-in read-only variables which can be used in expressions in generator models:

  • SCTVERSION (String): the current version of YAKINDU Statechart Tools, for example, "3.4.0"
  • TIMESTAMP (String): the current date and time as a localized string, for example "11.12.2017 17:08:14"
  • USER (String): the name of the current user who started this instance of YAKINDU Statechart Tools (via System.getProperty("user.name"))
  • HOSTNAME (String): the host name of the machine on which YAKINDU Statechart Tools is running.
  • SHA256 (String): The hash of the referenced file (for example, the statechart file).
  • SCTFILE (String): Path to the statechart file relative to the workspace.

Please note: Neither USER nor HOSTNAME should be used for any security-related tasks. Especially the username can be spoofed easily, if anyone wanted to.

Overriding variables in a headless build

The values assigned to properties are default values only. That means, you can override them by different values when actually executing a generation model by way of running the headless code generator.

For example, the command to call the headless generator might look like this:

scc -m myGenmodel.sct -v version=2.0;isBeta=false

The name/value pairs specified by the -v option would override the corresponding default values of the properties in the generator model. In this case, the properties version and isBeta would be set to the values „2.0” and „false”, respectively. The variables projectName and generateTimerServce would maintain their default values as specified in the SGen file.