As mentioned above, all generators can be set up and customized by a generator model. The following screenshot shows a sample configuration for the C code generator.
Sample generator model for the C code generator
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.
The Outlet feature specifies target project and target folder for the generated artifacts. It is a required feature and has the following parameters:
Example:
feature Outlet {
targetProject = "SampleProject"
targetFolder = "src-gen"
libraryTargetFolder = "src"
skipLibraryFiles = "false"
}
The OutEventAPI feature enables different generator features, which are used for out events:
At least one of both options needs to be enabled.
Example:
feature OutEventAPI {
observables = true
getters = true
}
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:
Example:
feature LicenseHeader {
licenseText = "Copyright (c) 2017 committers of YAKINDU and others."
}
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:
All parameters of the FunctionInlining feature are false by default.
Example:
feature FunctionInlining {
inlineChoices = false
inlineEnterRegion = true
inlineEntries = true
}
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:
Example:
feature Debug {
dumpSexec = true
}
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 = generateTimerService
}
}
}
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.
There are several built-in read-only variables which can be used in expressions in generator models:
System.getProperty("user.name")).
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.
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
generateTimerService would maintain their default values as specified in the SGen file.