Converting Models

Dezyne provides the possibility to convert models built with the ASD:Suite to Dezyne models.

Precondition for converting ASD models

Model conversion works only for ASD models built with 9.x.y version ASD:Suite ModelBuilder.

How to convert models

First create a new Modelling project or select a Modelling project that you want to use.

Click with the right mouse button (secondary or 3rd button) on the project folder and select Import.

(Alternatively you can select import from the dropdown menu that appears when selecting file in the main menu bar.)

Next select Dezyne and select Import from ASD:Suite models as the import source, see in the figure below.


Finally, select the folder and the model(s) to import, see figure below.


When a design model file is selected, the interface models the ASD design model is dependent on are also converted. All models will be stored in separate files with the same name as the generated Dezyne model names.

An ASD design model is converted to a Dezyne component model with the same name plus extension Comp. The Dezyne component model is contained in a file with the same name as the component (e.g.the ASD design model foo stored in will be converted to a Dezyne component model fooComp in file fooComp.dzn).

An ASD interface model will be converted into a Dezyne interface model with an additional I in front. The Dezyne interface model is contained in a file with the same name as the interface (e.g. the ASD interface model foo stored in will be converted to a Dezyne interface model Ifoo in file Ifoo.dzn). The rationale for this is that ASD allows a foo design and interface model while Dezyne does not allow component foo and interface foo.

When an interface model is selected, a stub component model (a component without implementation) that provides the interface is also generated. The latter model file has the same name as the original interface name (e.g. foo.dzn is generated from (In line with the ASD conventions that interface model and component model have the same name)

It is also possible to create a system component from an ASD design model, to do this check the tick box "Generate system components" in the import dialog box (see figure above). The system component gets the name of the original ASD design model. (e.g. system component foo will be generated from design model foo). The generated system component will assume that all components it uses are present, it might be necessary to explicitly import a required interface model to generate the stub component providing this interface. Beware that in case the orginal interface and design models have the same name (following the usual ASD conventions), it might happen that during the conversion of an interface model, the additionally generated stub component model will overwrite an existing system component model file and vice versa !

A recommended pattern to use is to select all ASD model files needed for your project, the converter will take care of creating the correct model files. Or convert first the inteface model files and as a next step the design model files.

Conversion of data parameters

In ASD data parameters are typed as ‘dollar expressions’ (e.g. $std::string$). In Dezyne an explicit type definition is required (e.g. extern string $std::string$;) Since these types are shared between interfaces and components, and have global scope, the conversion generates the extern definitions as comment only, and supposes the availability of a GlobalTypes.dzn file, where the real definitions should be available.

The GlobalTypes.dzn can be easily filled after all interface models have been converted by copying all extern comment lines, removing the ‘//’ comment characters, and taking out duplicates.

A Linux command doing this might look like:

grep -h '^// extern' *.dzn | sed 's,// ,,' | sort -u > GlobalTypes.dzn

Model transformation

On model conversion the following transformations occur:

  • Each interface model is transformed to an interface definition: interface I'name' {…​}. In addition a component 'name' {…​} without implementation providing the interface is generated.

  • Each design model is transformed in a component definition: component 'name'Comp {…​}

  • From a design model also a system component can be generated, select this option in the tickbox on the dialog where you can select the models to import.

  • The valued reply events (like OK or NOK, or CORRECT or WRONG) are transformed in an enum named 'service_name'_Values {…​}

  • The call events are transformed in in events

  • The notification events are transformed in out events

  • The modelling events are replaced by two pre-defined in events: optional and inevitable

  • The SBS table is transformed in a behaviour definition: behaviour {…​}

  • The states of a model are transformed in an enum named States and a variable called state_: enum States {'states_list'}; States state_ = States.'initial state';, with the exception of the synchronous return states which are transformed in functions

  • The rule cases for a state appear in '[state_.'state name']' {…​} constructs

  • The triggers (known as Event in the SBS table) are transformed in on statements: on 'event' {…​}

  • Behaviour triggered by an optional modelling event appears as an on optional statement

  • Behaviour triggered by an inevitable modelling event appears as an on inevitable statement

  • The guards appear after conversion as logical expressions between square brackets (i.e. []) in the related on statement: for example [true]

  • The actions appear as specification of out events in on statements * The State Variable Updates appear as variable assignments at the end of the on statement

  • State changes (known as Target State in the SBS table) appear as assignments in the on statement for the variable of type States defined at the beginning of the behaviour section of the interface or component

  • Parameter data types used in event declarations are best stored in a GlobalTypes.dzn as a single point of reference for multi-file models.

  • ASD TypeDefinitions appear as local type definitions within the behaviour definition : Integers as subInts, Enumerations as enums.

Enjoy this article? Don't forget to share.