Simple model not getting executed as expected

[bedo2991]

Hi, this is most likely a model problem but unfortunately, I can't figure out what's wrong with it. I would be very thankful if anyone can help me out.
The problem happens using all versions between fUML v. 1.30 and 1.4.2 (from the Dist folder)

Model: SequentialWriteline.uml.txt <- Please remove .txt from the extension

The CallBehaviors call fUML_Library.xmi#BasicInputOutput-WriteLine

The execution (fuml.bat SequentialWriteline.uml SequentialWriteline) prints:

A
B
A <- Wrong

With logging level set to INFO:

[---]\fUML-Reference-Implementation\org.modeldriven.fuml\dist\fuml-1.4.0-distribution\fuml-1.4.0\bin>fuml.bat SequentialWriteline.uml SequentialWriteline
===============================================================================

  fUML Runtime Environment

  FUML_HOME: [---]\fUML-Reference-Implementation\org.modeldriven.fuml\dist\fuml-1.4.0-distribution\fuml-1.4.0

  JAVA: C:\Program Files\Java\jdk1.8.0_231\bin\java

  JAVA_OPTS:  -Dprogram.name=fuml.bat -server -Xms128m -Xmx512m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000

  CLASSPATH: ../lib/*

===============================================================================

22 Jan 2020 15:55:22,962 INFO  fuml.Fuml loading artifact, SequentialWriteline.uml
22 Jan 2020 15:55:23,019 INFO  config.FumlConfiguration initializing...
22 Jan 2020 15:55:23,020 INFO  config.FumlConfigDataBinding loading schema chain...
22 Jan 2020 15:55:23,282 INFO  config.FumlConfiguration loading configuration, DefaultFumlConfig.xml
22 Jan 2020 15:55:23,353 INFO  model.InMemoryRepository initializing...
22 Jan 2020 15:55:23,354 INFO  repository.RepositoryConfigDataBinding loading schema chain...
22 Jan 2020 15:55:23,378 INFO  model.PrimitiveTypesAssembler initializing...
22 Jan 2020 15:55:23,405 INFO  model.UMLAssembler initializing...
22 Jan 2020 15:55:23,426 INFO  model.InMemoryRepository cacheing classifier attributes and operations...
22 Jan 2020 15:55:23,835 INFO  fuml.Fuml executing behavior: SequentialWriteline
22 Jan 2020 15:55:23,836 INFO  fuml.Debug Execute activity=SequentialWriteline
22 Jan 2020 15:55:23,842 INFO  fuml.Debug Fire activity=SequentialWriteline action=ValueSpecification1
22 Jan 2020 15:55:23,843 INFO  fuml.Debug Fire activity=SequentialWriteline action=CallBehavior1
22 Jan 2020 15:55:23,844 INFO  fuml.Debug Execute activity=WriteLine
22 Jan 2020 15:55:23,847 INFO  fuml.Debug Fire activity=WriteLine action=StandardOutputChannel
22 Jan 2020 15:55:23,848 INFO  fuml.Debug Fire activity=WriteLine action=writeLine
A
22 Jan 2020 15:55:23,850 INFO  fuml.Debug Fire activity=SequentialWriteline action=ValueSpecification2
22 Jan 2020 15:55:23,850 INFO  fuml.Debug Fire activity=SequentialWriteline action=CallBehavior2
22 Jan 2020 15:55:23,851 INFO  fuml.Debug Execute activity=WriteLine
22 Jan 2020 15:55:23,852 INFO  fuml.Debug Fire activity=WriteLine action=StandardOutputChannel
22 Jan 2020 15:55:23,853 INFO  fuml.Debug Fire activity=WriteLine action=writeLine
B
22 Jan 2020 15:55:23,858 INFO  fuml.Debug Fire activity=SequentialWriteline action=ValueSpecification1
22 Jan 2020 15:55:23,859 INFO  fuml.Debug Fire activity=SequentialWriteline action=CallBehavior1
22 Jan 2020 15:55:23,860 INFO  fuml.Debug Execute activity=WriteLine
22 Jan 2020 15:55:23,861 INFO  fuml.Debug Fire activity=WriteLine action=StandardOutputChannel
22 Jan 2020 15:55:23,861 INFO  fuml.Debug Fire activity=WriteLine action=writeLine
A

The same happens if the control flow goes from the initial node to the ValueSpecification or if the Initial node is left out completely.

I'm attaching the fuml.log file with all log4j.category.org.modeldriven.fuml.* set to DEBUG, too.

[seidewitz]

The XMI in your UML file is technically ill-formed. The nodes in the activity are serialized both in a list in an XML attribute node of the XML element for the activity SequentialWriteline and as nested node elements of the activity. This is causing the XMI loader to create duplicate entries for the nodes of the activities in the list of nodes in memory. By happenstance, it seems that the second WriteLine call for A is executing before the activity final node fires to end the activity execution.

This duplicate serialization of nodes is a general non-conformity of Eclipse UML XMI. It is actually a result of a difficulty with the serialization of structured activity nodes in UML 2.5. Due to an oddity in the UML abstract syntax, and if the rules of XMI 2.5 are strictly followed, structured activity nodes should be serialized both as nested stucturedNode elements and as node references. The Eclipse XMI implementation does this right, putting the node references into an XMI attribute. The problem is that it also serializes non-structured nodes as both nested XML elements and in the XML node attribute, which is not technically correct.

Most tools handle this OK when importing Eclipse UML XMI, because the node property of an activity is supposed to be unique, so duplicates are eliminated. However, for historical reasons, the fUML Reference Implementation uses lists for in-memory storage of all collections and the XMI loader presumes that the XMI is correct. Thus, loading activities from an Eclipse file results in duplicated node entries.

It is not likely that the Eclipse implementation of UML XMI serialization is likely to change any time soon. And, since it is intended that the reference implementation should be able to read Eclipse .uml files, I am classifying this issue as a bug. Fortunately, the fix should not be difficult.

[seidewitz]

I have pushed a fix for this bug. I am not going to make this an official maintenance release, because the v1.4.3 tracking release should be available in the next month anyway. However, you can try the new interim distribution for v1.4.2a, which should resolve your problem.

[bedo2991]

Thanks a lot, Mr. Seidewitz, the fix works perfectly.

[seidewitz]

Resolved in v1.4.3.