A textual representation element provides a representation of a model element in a specified language. A textual representation identifies the language of the representation and contains the corresponding text body. The language may be a natural language or a machine-readable language.

Textual representations can be used to associate model elements with language-specific content such as scripts, expressions, analysis artifacts, or other textual definitions.

Supported languages include:

  • JavaScript
  • Groovy
  • Beanshell
  • Python (via Jython)
  • MATLAB

Using MATLAB

To evaluate scripts defined in the MATLAB syntax:

When a textual representation is used for script execution, script inputs and outputs are typically primitive values (Boolean, Integer, Real, and String). Evaluated structured model elements, such as parts, can also be provided as inputs. You can access their feature values by using the get method described below. In Groovy scripts, nested feature values can also be accessed using dot notation.

Printing output from scripts

Evaluated scripts in all supported languages can print messages to the SysML v2 Model Evaluation console using the print method. Each call to print outputs a separate line in the console.

calc def ListCalc {
    /* Calc prints to console and returns null output  */
        in numericalList [*] : Real;
        return : Real;
        rep myScript language "Python" /* print(numericalList[1]) */


Accessing structured model elements in scripts

In addition to primitive values, a script can receive an evaluated structured model element (for example, a part) as input. To access feature values from the structured element, use the get method:

Example
vehicle.get("grossMass")

The method returns the evaluated value of the specified feature. For example, if vehicle is a part and grossMass evaluates to a real value, the expression in the above example returns the numerical value of grossMass.

Using Groovy

When using Groovy, nested feature values can be accessed via dot notation in addition to the get method, for example:

calc def Area {
        in myInput :> Vehicle::pad;
        return : Real;

        rep myScript language "Groovy"
        /* myInput.centerLength * myInput.width */


Textual representations in calculations

When specifying the return value of a calculation, you can use a textual representation to evaluate a script written in a supported scripting language.

The following example uses a Beanshell script to calculate an area from the supplied inputs:

Example

calc def Area15 {
        in length : Real;
        in width : Real;
        return result : Real;
        language "beanshell" /* result=length * width */

}

When the calculation is evaluated, the script receives the calculation inputs as variables and assigns the computed value to the return parameter.

Textual representations in actions

When defining an action, you can use a textual representation to implement the action's behavior using an external scripting language. Action parameters are exposed to the script and can be read or updated according to their direction (in, out, or inout).

Example

action def counter {
            inout count : Real := 0;
            language "groovy" /* count=count+1 */ }
        }
attribute startCount : Integer = counter().count //The result will be 1 because there is no input
attribute continueCount : Integer = counter(startCount).count //The result will be 2. Input overrides the initial value set in the parameter.

Invoking external tools via ToolExecution

Actions support "ToolExecution", which allows SysML v2 features to be mapped to variables used by MATLAB scripts. This is particularly useful when the variable names used in the model differ from those expected by the external script.

The following example executes a MATLAB script and maps model features to MATLAB variables using "ToolVariable" annotations:

Example

action computeStoppingDistance {
            private import AnalysisTooling::*;
            @ToolExecution {
                :>> toolName = "MATLAB";
                :>> uri = "run('C:/custom/path/to/StoppingAnalysisExec.m')";
            }
            in mass : Real = vehicle.grossMass {@ToolVariable { name = "m"; }};
            in speed : Real = vehicle.speed {@ToolVariable { name = "v0"; }};
            out Distance : Real = vehicle.stoppingDistance {@ToolVariable { name = "stoppingDistance"; }};
            out kineticEnergy : Real = vehicle.kineticEnergy {@ToolVariable { name = "e"; }};

Textual representations in constraints

You can use a textual representation to define constraint logic in both requirements and standalone constraints using a supported scripting language. When a simple constraint (assert constraint) is evaluated, all attributes of the constraint’s owner are available in the script as variables. You can use them directly without qualification. You can also access nested structures using the get method (and dot notation in Groovy).

Standalone constraints

In a standalone constraint, attributes defined within the constraint are directly available in the script.

Example

assert constraint {
        attribute maxValue : Integer = 5;
        attribute currentValue : Integer = 3;

        language "Groovy" /* currentValue < maxValue */
}

Constraints in parts

When a constraint is defined directly under a part, all attributes of the part are available in the script.

Example

part vehicle {
    attribute maxSpeed : Integer = 100;
    attribute currentSpeed : Integer = 100;

    satisfy speedReq by this;

    assert not constraint {
        language "groovy" /* currentSpeed == maxSpeed */
    }
}

Constraints in requirements

When a constraint is used inside a requirement, the requirement subject is made available to the script engine as the root context for evaluation. This means that the subject and its structure are directly accessible in the script engine.

Example

requirement speedReq {
    subject vehicle v :> vehicle;

    require constraint {
        language "groovy" /* v.currentSpeed < vehicle.maxSpeed */
    }
}