In MagicDraw 19.0 with Alf plugin, we defined an activity with import statements. The Alf code starts with:
private import Util::Protocol::Messages::Start;
private import Util::Protocol::Messages::End;
activity ‘AbstractSemanticTest$behavior$1’() {
The compiler marks the first word “private” as an error:
What’s wrong? Private import statements are supported by Alf.
Tim
The issue is that the MagicDraw Alf Plugin implements Alf at the so-called “full conformance” level. This level includes all the behavioral elements of Alf (i.e., statements and expressions), which can be used to specify the body of an activity or opaque behavior. This is the core use of Alf as an “action language”.
However, Alf can also be used to specify complete structural element definitions for activities, classes, packages, etc. Import declarations can only be attached to such Alf units, as they are attached to an activity definition unit in the code shown in your question. But units are only included at the “extended conformance” level of the Alf standard, so they are not supported by the MagicDraw Alf Plugin. (Note that Eclipse Moka implements Alf at the extended conformance level, and so would be able to accept the above code.)
In order to get this code to work in MagicDraw, remove everything but the sequence of statements in the body of the activity definition. Assuming that this code is already attached to a UML activity called AbstractSemanticTest$behavior$1, you can then re-create the import relationships in the UML model from that activity to the Start and End elements. Or you can just use fully qualified names in where the elements are referenced in the code.
The plugin’s error is about the input form it accepts, not the legality of private import in Alf. Since the editor expects an activity body, it encounters a unit-level declaration before the body and rejects it. Keeping imports in the UML model and supplying only the behavior body matches that plugin’s full-conformance interface; support in another Alf implementation doesn’t imply the MagicDraw plugin accepts the same source form.
Changing private to a public import won’t fix this: the plugin doesn’t accept import declarations at all, regardless of visibility. The important distinction is where the Alf is being parsed. The plugin accepts Alf action-language bodies, while imports belong to a full Alf unit. Keep the activity body in the plugin and express the dependencies through UML relationships or qualified names, as Seidewitz suggests.
MagicDraw’s plugin accepts Alf behavioral code, but not Alf units, which is the level where import declarations belong. Keep the activity body in the editor and create the Start and End imports as UML model relationships, or use fully qualified names at each reference. Changing private to another visibility won’t help, since the parser rejects the unit-level import syntax itself.
The private modifier isn’t the problem here. The plugin rejects the import declaration because it only accepts Alf behavioral statements and expressions, not complete Alf units. Put the code in the activity body without the imports, then add the UML usage relationships to Start and End or refer to them by qualified name.
MagicDraw’s Alf editor is parsing this as an activity body, not as a complete Alf unit. So the error at private is about the plugin’s supported input form, not the validity of private imports in Alf generally. The existing workaround is to put only the statements in the editor and represent the imports in the UML model, or qualify the names in the code.
The plugin is rejecting the unit-level syntax, not the private visibility itself. In MagicDraw, keep the Alf text to the activity’s statements, then create the Start and End import relationships in the UML model, or qualify their names in the statements. The distinction is that the plugin supports Alf behavior bodies, while parsing activity-definition units requires extended conformance.
The private modifier isn’t the problem here; the plugin is parsing the snippet as an activity body, not as a complete Alf unit. Import declarations belong to the latter, which this MagicDraw plugin doesn’t support. Put the imports on the UML model side as import relationships, or qualify Start and End at their use sites. Changing private to public won’t address the compiler error.
For the UML-model route, use private ElementImport relationships to Start and End if you want to preserve the visibility of the original imports; otherwise the fully qualified names avoid needing imports in the action body.
The parser is rejecting the unit-level import declaration, so changing private to another visibility is unlikely to fix it. In the plugin, keep the code editor content to the activity body, then make the Start and End imports in the UML model or qualify their names in the Alf references. The import syntax itself belongs to extended conformance, which this plugin does not implement.
The parser is rejecting the location of the declaration, not the private visibility. In this plugin, the code field is parsed as an activity body, where Alf expects executable statements; import declarations belong to an Alf unit, which the plugin’s full-conformance implementation doesn’t support. Keep the body there and represent the imports as UML relationships, or qualify Start and End where they’re used.