New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

different behaviour for activities and actions #853

Closed
vahdat-ab opened this Issue Jun 20, 2016 · 1 comment

Comments

Projects
None yet
3 participants
@vahdat-ab
Member

vahdat-ab commented Jun 20, 2016

consider the following example:

class A{
    sm{
      s0{
        entry / {s0_entr1();}
        entry / {s0_entry2();}
        e0 -> s1;
        exit /{s0_exit1();}
        exit /{s0_exit2();}
      }
      s1{
        entry / {s1_entry1();}
        entry / {s1_entry1();}
        e0 -> s1;
        exit /{s1_exit1();}
        exit /{s1_exit1();}
      }
  }
}

This is the part of the generated code for entries and exits.

 private void exitSm()
  {
    switch(sm)
    {
      case s0:
        // line 8 "model.ump"
        s0_exit1();
        // line 9 "model.ump"
        s0_exit2();
        break;
      case s1:
        // line 15 "model.ump"
        s1_exit1();
        break;
    }
  }

  private void setSm(Sm aSm)
  {
    sm = aSm;

    // entry actions and do activities
    switch(sm)
    {
      case s0:
        // line 5 "model.ump"
        s0_entr1();
        // line 6 "model.ump"
        s0_entry2();
        break;
      case s1:
        // line 12 "model.ump"
        s1_entry1();
        break;
    }
  }

As we can see we have both s0_entry1() and s0_entry2() in the generated code. The same thing is correct for exit actions s0_exit1() and s0_exit2(). However, in the state s1 we have the same structure but this time the actions for entries and exits are exactly the same. However, in the generated code we have just one s1_entry1()' ands1_exit1()`.
Looks like we detect duplication and remove it. However, it violates the semantics of having several definitions for entries and actions inside a state. I think we should repeat them in order to have a consistent semantics.

@marc22alain

This comment has been minimized.

Contributor

marc22alain commented Sep 24, 2016

Another comment about the intent of this change: while the parser proactively deletes duplicated actions, the user might have perfectly valid reasons for having duplicate actions. We want to allow the user to do so.
The Umple parser does create Tokens for all of the entry and exit actions, so the trouble occurs later when instantiating and adding actions to the state machine.
The call to add an action occurs in UmpleInternalParser_CodeStateMachine.ump, at lines 956 - 959:

      else if (subToken.is("entryOrExitAction"))

      {

        fromState.addAction(analyzeAction(subToken, fromState));

      }

Then, the auto-generated code for addAction() includes a check of whether the action is unique. This check uses the Java equals() test. The Action class includes auto-generated code that overrides equals() and defines its own criteria for equals(). The criteria are defined in the Action class code in StateMachine.ump at line 184 with:
key { actionType, actionCode } .
We can fix this by adding the position property as a criteria for determining uniqueness, since each line of code has a different position value.

marc22alain added a commit that referenced this issue Sep 24, 2016

Committing fixes for #853
One word addition to StateMachine.ump; added the issue example as the
test, with java.txt and php.txt generated code.

vahdat-ab added a commit that referenced this issue Sep 24, 2016

Merge pull request #888 from umple/fix_853
Committing fixes for #853
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment