Skip to content
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

Final states should not have do activities, exit actions, nested state machines, nor outgoing transitions #925

Closed
vahdat-ab opened this Issue Dec 3, 2016 · 19 comments

Comments

Projects
None yet
4 participants
@vahdat-ab
Copy link
Member

commented Dec 3, 2016

The current implementation of Umple doesn't restrict final states from having do activity, exit and entry actions, and any outgoing transition. Consider the following example

class X{
  
  status{
    on{
      turnoff -> off;
      powerOff-> FINAL;
    }    
    off{
      turnOn -> on;  
    }
    final FINAL{
      entry/{entry();}
      do{exe();}
      exit/{exit();}
      turnOn-> on;
    }
  }
}

The snipped parts of the generated code

private void exitStatus()
  {
    switch(status)
    {
      case FINAL:
        // line 15 "model.ump"
        exit();
        if (doActivityStatusFINALThread != null) { doActivityStatusFINALThread.interrupt(); }
        break;
    }
  }
 private void doActivityStatusFINAL()
  {
    try
    {
      exe();
      Thread.sleep(1);
    }
    catch (InterruptedException e)
    {

    }
  }

  private void setStatus(Status aStatus)
  {
    status = aStatus;

    // entry actions and do activities
    switch(status)
    {
      case FINAL:
        // line 13 "model.ump"
        entry();
        delete();
        doActivityStatusFINALThread = new DoActivityThread(this,"doActivityStatusFINAL");
        break;
    }
  }
@vahdat-ab

This comment has been minimized.

Copy link
Member Author

commented Dec 3, 2016

More information about the keyword final is in issue #140

@vahdat-ab vahdat-ab changed the title final state should not have do activity, exit and entry actions, and any out going transition Final states should not have do activity, exit and entry actions, and any out going transition Dec 3, 2016

@vahdat-ab vahdat-ab changed the title Final states should not have do activity, exit and entry actions, and any out going transition Final states should not have do activity, exit and entry actions, and any outgoing transition Dec 3, 2016

@TimLethbridge

This comment has been minimized.

Copy link
Member

commented Dec 4, 2016

It is not clear to me that an entry action should be forbidden. After all, one does enter a final state. It might simply display something log a user out or something like that.

Outgoing transitions, however should definitely be ignored with a warning, and so should exit actions.

@vahdat-ab

This comment has been minimized.

Copy link
Member Author

commented Dec 4, 2016

The final state is a concept that must be kept the same in a state machine. For example, if there are two final states they should have the same concept and functionality. If we give an entry attribute to final states it means that they can be different.

final x{}
final y{} 

states x and y have the same semantic.

final x{entry/{log.msg("xxx");}
final y{}

states x and y are now different because x does something extra.
The above material is based on a formal definition of state machines, but there is no force for us to follow it.
BTW, What you pointed out can be done by having the logging functionality in the action of incoming transition. This satisfies the requirement and also keeps the concept of final state clean.

@TimLethbridge

This comment has been minimized.

Copy link
Member

commented Dec 4, 2016

I think it would be cleaner to allow action on entry into a final state. There can be more than one final state. E.g. in my tic-tac-toe game example, there is XWin and OWin. A final state is simply a state that the system then can't get out of. I am not even bothered by having a do activity in one ... it would just run on until it completes, or indefinitely. Unusual, but not inconceivable.

@vahdat-ab

This comment has been minimized.

Copy link
Member Author

commented Dec 4, 2016

In that case, we don't need to adopt the UML graphical notation for the final states because how we are going to show that there is an entry for that specific final state?
This should be clarified because @marc22alain is working on the graphical representation of state machines.

@TimLethbridge

This comment has been minimized.

Copy link
Member

commented Dec 4, 2016

My take on this is the following: The original graphic notation for state diagrams, before UML and before entry and exit actions being put in diagrams, was simple: Put a dark circle in it when it is final. When entry and exit actions were put in them, then that resulted in them having to simply prevent entry and exit actions if they wanted to preserve the circle notation. But there was no other logic reason for this ... merely to preserve nice graphics. Note that when the circle with a dot is used, you can't even name the state with a circle inside!

What we could do is this: Simply put a dark circle dot inside (top right) any final state.

@marc22alain

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2016

My approach for naming the final state was to put the state's name below it.
Putting the 'final' circle inside the state's rectangle is also possible; I am doing this with a different icon to indicate the presence of nested state machines.

@TimLethbridge

This comment has been minimized.

Copy link
Member

commented Dec 4, 2016

I agree then with the last comment. In other words, if there are is no entry action/ do activity (or if the option is set such that they are not displayed) then the normal circle with a dark circle inside would be displayed as per standard UML, and the state name below it.

@vahdat-ab

This comment has been minimized.

Copy link
Member Author

commented Dec 6, 2016

Why do we need to have a do activity? we want to specify exactly that if an object is in this state (final) it must be terminated. Putting a do activity just makes the concept more complicated.
I can consider the case in which system is running while it shows it is in a final state.
An entry action makes sense somehow because it's gonna done once.
However, I still think that by having features like entry we pollute the concept of final which is simple and easy to understand. It is also easy to deal with its formal definition.
@opeyemiAdesina I wonder if you have any comment on this subject as well

@TimLethbridge

This comment has been minimized.

Copy link
Member

commented Dec 6, 2016

Right OK. No do activities.

@TimLethbridge

This comment has been minimized.

Copy link
Member

commented Jan 27, 2017

So we simply are going to allow entry actions only. No outgoing transitions, no do activities, no exit actions. The object is deleted after the entry actions are done.

@jblang94 jblang94 self-assigned this Jan 27, 2017

@TimLethbridge TimLethbridge changed the title Final states should not have do activity, exit and entry actions, and any outgoing transition Final states should not have do activity, exit actions, and any outgoing transition Jan 27, 2017

@jblang94

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2017

When outgoing transitions, exit actions, and/or do activities are detected in a final state which of the following should happen:

  1. Compile the user's Umple file, remove the elements from the final state, and issue a warning to the user that they were removed.
  2. Throw an error and don't compile the Umple file.

I also noticed that Umple accepts nested state machines within a final state. Should nested state machines also not be allowed? From #140, I read that final states should not have substates.

final FINAL{
      entry/{entry();}
      do{exe();}
      exit/{exit();}

      nestedSm {
        s1 {
          -> s2;
        }
        s2 {

        }
      }
}
private void setStatus(Status aStatus)
  {
    status = aStatus;

    // entry actions and do activities
    switch(status)
    {
      case FINAL:
        // line 12 "final_state_ex.ump"
        entry();
        delete();
        doActivityStatusFINALThread = new DoActivityThread(this,"doActivityStatusFINAL");
        if (statusFINAL == StatusFINAL.Null) { setStatusFINAL(StatusFINAL.nestedSm); }
        break;
    }
  }
@TimLethbridge

This comment has been minimized.

Copy link
Member

commented Jan 30, 2017

Remove and throw a warning would be the best approach.

@jblang94

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2017

@TimLethbridge remove nested state machines as well?

@TimLethbridge

This comment has been minimized.

Copy link
Member

commented Jan 30, 2017

@jblang94 Regarding moving nested state machines. Very interesting question! It seems to me that either: a) Simply don't allow them (final states must be leaves) or b) Declare if non-leaf is 'final' that implies that all its descendents must be final too, and then apply all the same rules recursively to those; but it must also be the case in b that there must be direct transitions to all substates.

I can see an argument for b (e.g. there may be several ways of ending a game and you want to do the same entry action for them at in a compound state, and then separate entry actions for each leaf). But I think this is too complex, so I am OK with option a, which is what you were proposing. However I think @vahdat-ab should comment on whether he concurs as this could have an impact on traits.

@vahdat-ab

This comment has been minimized.

Copy link
Member Author

commented Jan 30, 2017

I would choose a because we need to keep the concepts clear. The scenario Tim pointed out can be satisfied with one state before the final state. If the final state is that much complicated, it must be par of the real modeling part.
Therefore, a final state is a state that can have just entry action. others elements should not be allowed.

@jblang94

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2017

I would like to confirm that I am looking at the correct files.

To remove the do activities, nested state machines, exit actions, and outgoing transitions:

  • Add test cases to JavaClassTemplateTest.java and PhpClassTemplateTest.java
  • Add my fix to UmpleTLTemplates/state_machine_Get_All.ump for both UmpleToJava and UmpleToPhp. I believe this is the correct file to modify because I can remove all of the invalid elements from the final states of all state machines before code generation begins

To implement the warning that informs users that the final state will be modified:

  • Add test cases to UmpleParserTest.java
  • Add the code that determines if the warning needs to be shown to UmpleInternalParser_CodeClass.ump
  • Add an entry for the warning into en.error
  • Add a .txt file for the warning to build/reference
  • Add example Umple files that produce the warning to umpleonline/ump/manualexamples

From my understanding, the .txt file should reference the examples that I add to umpleonline/ump/manualexamples. The .txt file is rendered into HTML, and is provided as a page under the "Errors and Warnings" section of the Umple user manual.

@jblang94 jblang94 changed the title Final states should not have do activity, exit actions, and any outgoing transition Final states should not have do activities, exit actions, nested state machines, nor outgoing transitions Jan 31, 2017

@vahdat-ab

This comment has been minimized.

Copy link
Member Author

commented Jan 31, 2017

@jblang94
if you work on the file UmpleTLTemplates/state_machine_Get_All.ump it means you're dealing with the issue at the code generation level. You need to do this at the modeling level so all generators will get the valid final states.
The detection must be done once a state is recognized as a final state. After that, if there are any of those unwanted elements, it must be removed and the user must be informed.
This modification should be done inside the class UmpleInternalParser

@jblang94

This comment has been minimized.

Copy link
Contributor

commented Jan 31, 2017

@vahdat-ab thank you for the clarification, it makes much more sense to put the fix in the modelling level

@vahdat-ab vahdat-ab closed this Feb 3, 2017

jblang94 added a commit to jblang94/umple that referenced this issue Feb 16, 2017

Add User Manual entries for E073 and E074
* Add user manual pages and examples for E073 and E074
* Add additional test case which is also used as a user manual example
* Modify E074 error message
* Update links in en.error for E073 and E074
* Add missing link for W072 (from my past fix for issue umple#925)

jblang94 added a commit to jblang94/umple that referenced this issue Feb 17, 2017

Add User Manual entries for E073 and E074
* Add user manual pages and examples for E073 and E074
* Add additional test case which is also used as a user manual example
* Modify E074 error message
* Update links in en.error for E073 and E074
* Add missing link for W072 (from my past fix for issue umple#925)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.