Skip to content

UCOSPLogAlexRingeri

Kevin Brightwell edited this page Aug 26, 2015 · 1 revision

Each UCOSP participant is asked to log all their accomplishments as well as the difficulties they have getting set up to understand Umple and other experiences they have. Difficulties might include understanding how to model in Umple, using UmpleOnline, code that is difficult to figure out, and development tools that are hard to figure out, or don't seem to work properly. The more log entries added the more we can better get a grip on the usability issues with Umple, and the more we can help future new contributors come up to speed. Mention issue numbers and revision numbers in your log to help create hyperlinks.

Log entries in reverse chronological order

December 2 2014

  • Committed a fix for Issue 657 (on Google Code).

I've added: * Template tests to check that the code to synchronize threads before an auto-transition is generated correctly. * Warnings for duplicate/conflicting auto-transitions in the same state. Tests have been added to check the simple case, the case after multiple do activities and the nested state machine case. * I added a testbed case to ensure that multiple do activities complete their execution before taking a transition.

December 1 2014

  • I worked on Issue 657 (on Google Code) today. The issue also applies for multiple auto transitions without do activities.

I have successfully raised a warning when having multiple auto transitions in a state. All transitions after the first are ignored. Ignoring a transition after a do activity was a little trickier. The activity token is a subtoken of the auto-transition. This means that when the error is detected, we keep the activity token and disregard the transition information.

  • I still want to add a few final test cases for the error detection and to add activity synchronization to the testbed. I should have a commit for this issue soon.

November 27 2014

  • I have raised and started Issue 657 (on Google Code): Auto-transition support for multiple do activities.

I have identified where the thread synchronization must occur when generating do activities. I will create tests for code generation and the testbed to ensure that auto-transitions are working correctly.

  • I have found that having multiple transitions will be an issue. This is related to Issue 524 (on Google Code) and an error may need to be raised. For example:
  class Test{
    sm{
      start{
        do { System.out.println("Activity 1"); } -> s2;
        do { System.out.println("Activity 2"); } -> s3;
      }
      s2{}
      s3{}
    }
  } 

November 25 2014

  • I committed a fix for Issue 644 (on Google Code) last Friday (19th)
  • I am now looking at auto transitions for multiple do activities. I am planning on having one thread in a state wait for all other threads in the same state to finish. Once all threads have finished, the transition to a new state can be taken. Here is an example to clarify:

Umple code:

  class Test{
    sm{
      start{
        do { activity1(); }
        do { activity2(); } -> end;
      }
      end{}
    }
  }

Snippets of generated Java:

  ...

  //Test Do Activity Threads
  Thread doActivity0SmS1Thread = null;
  Thread doActivity1SmS1Thread = null;

  ...

  private void doActivity0SmS1()
  {
    try
    {
      activity1();
      Thread.sleep(1);
    }
    catch (InterruptedException e)
    {

    }
  }
  
  private void doActivity1SmS1()
  {
    try
    {
      activity2();
      Thread.sleep(1);
      doActivity0SmS1Thread.join();
      __autotransition1__();
    }
    catch (InterruptedException e)
    {

    }
  }

  ...

November 19 2014

  • I have all my tests working correctly for Issue 644 (on Google Code). I will now review my code and double check that everything is correct before committing.

November 18 2014

  • I updated Issue 644 (on Google Code): The issue is also occurring when using the 'entry' and 'exit' keywords.
  • I have created the tests that demonstrate these issues and they are currently failing. I will make my modifications soon and have them validated.

November 17 2014

  • Issue 644 (on Google Code): I've decided to add the thread creation code as an entry action for a state. This will occur in the generation step when 'prepare' is being called on a state machine. The code below will be removed from the jet template and generated as an action. This will keep the code generation consistent for both thread launches and thread interrupts.
    entryActions.append(StringFormatter.format("\n        {1} = new DoActivityThread(this,\"{0}\");",gen.translate("doActivityMethod",activity),gen.translate("doActivityThread",activity)));

generates:

    doActivitySmS1Thread = new DoActivityThread(this,"doActivitySmS1");

November 16 2014

  • Looking at the generation of exit methods for state machines with no transitions ('simple' statemachines). I've found that thread interrupts are exit actions but thread launches are not entry actions. I think we might want to set the code used for a thread launch as an entry action. I think this would clean up how the activity code is generated.
  • I've also been thinking about how to implement auto transitions with multiple do activities. I think we may want to designate a single activity thread to wait for all other activity threads (in the same state) to finish. Once all the activities in the state have completed, a can transition can be made to another state.

November 14 2014

  • looking at Issue 644 (on Google Code), my suggested fix from yesterday does not produce the correct result. The correct thread interrupts were generate but since there are no transitions the code is unreachable. I now think the state machine should stay as a "simple" type. The thread interrupts should be generated as exit actions to a state with do activities. The thread launches should also be generated but as entry actions.
  • This is an example of what could be generated.

Umple code:

  class X{
    sm{
      s1{
        do { System.out.println("Activity1"); }
      }
      s2{
        
      }
    }
  }

Generates something like:

  public class X
  {

    //------------------------
    // MEMBER VARIABLES
    //------------------------

    //X State Machines
    enum Sm { s1, s2 }
    private Sm sm;

    //X Do Activity Threads
    Thread doActivitySmS1Thread = null;

    ... 
 
    public boolean setSm(Sm aSm)
    {
      if (sm == Sm.s1 && aSm != Sm.s1 ) { exitS1(); }
      if (sm != Sm.s1 && aSm == Sm.s1 ) { enterS1(); }

      sm = aSm;
    }

    private void exitS1(){
      if (doActivitySmS1Thread != null) { doActivitySmS1Thread.interrupt(); }
    }

    private void enterS1(){
      doActivitySmS1Thread = new DoActivityThread(this,"doActivitySmS1");
    }

    ...

November 13 2014

  • I've traced through the generation code and found the cause of Issue 644 (on Google Code). I found that the generation of the exit methods is dependent on a state's type. In this case the 'getType' method, either returns "Simple" or "Complex". The issue is occurs when a state with a do activity is a "Simple" type. I have modified the 'getType' method to return "Complex" when a state has one or more do activities.
  • I should have a commit for this issue soon. I would first like to check that the traceItems in this case are consistent and the currently functioning cases.

November 6 2014

  • I've started to look into Issue 644 (on Google Code) where a state machine with no transitions and a do activity is producing code that will not compile.

for example:

class X {
  sm {
    s1 {
      do {System.out.println("something");};
    }
    s2 {}
  }
}

The problem lies in the setSm generated method. exitS1() and exitS2() are being called but they are not defined in the generated code.

public boolean setSm(Sm aSm)
{
  if (sm == Sm.s1 && aSm != Sm.s1 ) { exitS1(); }
  if (sm == Sm.s2 && aSm != Sm.s2 ) { exitS2(); }
  sm = aSm;
  return true;
}

We should handle this case with no transitions by generating the exitS1 and S2 method or by replacing the calls with a thread.Interrupt(). I am looking in to how the setSm method is currently generated.

November 3 2014

  • I looked at other places where position information is handled for multilingual code. I found that method bodies kept track of this using a hashmap of positions associated with a language.
  • I implemented the same approach for method bodies as for activities. The line number information for each multilingual code snippet should now be accessible. I committed the changes in r4702 (on Google Code).
  • I also fixed a very small bug from my patch in r4628 (on Google Code). It was in the UmpleToRuby template for a do activity to translate the activity to the proper thread name. The generated file did not match Jet template. It was initially missed because the generated file was not changed until the jet template was compiled in eclipse
def <%= gen.translate("doActivityMethod",state)%>

to

def <%= gen.translate("doActivityMethod",activity)%> 

October 31 2014

  • I've still been looking into positions for activities. When we have an active object with multiple languages specified we can see that an activity's position will be different for the Java and Cpp code.
class X{
  active Java { 
    doJava(); 
  } Cpp{ 
    doCpp(); 
  }
}
  • In the generated output we would like to point to the proper line number based on the target language. Currently, the activity.getPosition() will be the same for both languages. This may be an issue for other parts of umple so I will look through and ensure that the positions of multilingual code blocks are treated consistently.

October 28 2014

  • I've been looking into adding positions for an activity's codeblock. This might involve modifying the codeblock class to support positions. I'm not certain that the position information is necessary for each activity's code snippet since we already able to get the position information from an activity object. I will discuss this with Tim and Ahmed to ensure that enough position information is available in the code generation steps.

October 23 2014

  • Committed r4656 (on Google Code) to fix the initialization of an activity's position when using the "active" keyword. I found that when an 'activeDefinition' token was being transformed into a stjatemachine with a do activity, the position not being passed along.
  • I've updated issue pages for 635, and 629 to MostlyDone and have added the revision numbers which patches were committed.

October 22 2014

  • I am working on some do activity issues raised by Ahmed. Currently, an active object's code position is being lost (returning null). So code like (active { blah; } ) will return null when calling getPosition(). Since the active keyword is syntactic sugar and is represented as a state machine with a do activity in the model. I suspect that the position information may not be being passed over when producing the model.
  • I have looked and found that token position information was not being passed through for active objects in the internal parser. I have made some changes and tests to resolve this. I should have a fix committed soon.

October 18 2014

  • Submitted patch for Issue 635 (on Google Code)
  • Here is a summary of what was done:
    • I changed the State model to have a (1 -- * ) relation with Activity
  • I modified the model querying and generation steps to iterate over multiple Activities in a State.
  • I created a new translate method in the CodeTranslator interface that accepts an Activity and generates a unique string based on the number ​of activities in the State.
  • I have created some parsing, generator, template and testbed tests for each of these steps.

October 16 2014

  • I am getting very close to a fix for Issue 635 (on Google Code). Thread naming is working as expected for Java, Php and Cpp generation. Exit methods are being produced correctly for multiple threads (each one is interrupted). The generated Java code is compiling and the testbed tests I wrote earlier are working correctly. I've noticed that a do activity's code is not placed in it's own thread when generating Php. Thread generation for Php may be in progress.
  • I now plan to review and clean up my changes for submission. I will make sure that I have the proper tests for these changes.

October 15 2014

  • I've managed to generate proper thread names for do activities. I did this by adding a new translate method for each generator to specifically handle do activities. I chose to create a new translate method because the previous approach only used the activity's state for the naming. This made it difficult to distinguish between activities in the same state.
  • These changes had broken a few of the previous doActivity template tests. This was because I have appended numbers to the thread names and the tests weren't handling them. I resolved the majority of test failures by appending numbers to the thread names only when there is more than one activity in a state.
So :
  class X{
sm {
s1{
do { blah; }
e1 -> s2
}
s2 {}
}
}
will produce thread:
    ...
Thread doActivitySmS1Thread = null;
...
and
  class X{
sm {
s1{
do { blah; }
do { blah2; }
e1 -> s2
}
s2 {}
}
}
will produce :
    ...
Thread doActivity0SmS1Thread = null;
Thread doActivity1SmS1Thread = null;
...
  • I've also found that one of the existing Generator tests may not be relevant when when having multiple do activities. The 'translate_states()' test was calling translate on a state that has no do activities. The tests checks whether the proper naming would work for a do activity thread. I can see that this test may be relevant when there is only one activity per state. I think it should be replaced by a new test that uses a state with one or more do activities.

October 14 2014

  • I am looking at the naming of do activities in Issue 635 (on Google Code). Currently, umple thread naming only supports a single do activity per state. If two activities are in the same state, they will be generated with the same thread name. The occurs because in the Generator's Translate method, the do activity is named based on the state and state machine it is in. I think I should extend the Translate method to accept an Activity object. This should allow me to name each activity thread and method based on the activity number within each state and state machine.
  • I have also found that exit actions (Thread.interrupt) for do activities are only being produced for the first activity in a state. In order to solve this, I suspect that I will need to generalize the generation of these actions to handle multiple threads.

October 9 2014

  • I have raised Issue 644 (on Google Code) (Exit methods not being produced for a do activity in a state with no transitions).
  • After a quick search I was able to find out how to compile and run the tested tests. I will need to work at the code generation before my new testbed tests can compile and run.
  • I have created a new template test that consists of a state machine with 2 states and 2 do activities in state 1. This test currently fails since the threads for each activity are named the same. I will work at a way to number each distinct thread and its activity.

October 7 2014

  • I am still working on Issue 635 (on Google Code)
  • I have created some parsing and metamodel tests that should succeed with multiple doActivity support.
  • I have added more testbed tests for multiple doActivities. I have created new tests that expand on the existing tests to handle multiple activities. I will be working to add more tests that are specific to having multiple activities. I am currently not sure how to run the testbed tests. (I will ask around and make sure that these new tests fail)
  • In addition to adding testbed tests, I plan to add template tests for the code generation.
  • I also plan to look into doActivities and Tracing. There are some sections in the StateMachine Jet templates where TraceItems are used with an activity's code block. I plan to learn more about how tracing works in Umple, and that having multiple activities will not affect the traces.

October 3 2014

  • I have made some changes that allow states to contain multiple do activities. Some initial testing shows that the umple model is being populated correctly. I am able to parse a file with multiple do activities and these activities are present in the state object.
  • I did a quick (uninformed) changeover of the generation code to support multiple active objects. I did this in order to play around with multiple do activities without looking at the generation stage in detail.
  • From these initial tests, the generated code is producing code with multiple activities but the naming of the activities is incorrect. I will look into the naming of the activities and generation state at greater detail to ensure that I am producing the correct output. (I also plan to add the appropriate tests for each stage)

October 1 2014

  • I have been looking into Issue 635 (on Google Code) where multiple do activities in a state are not working. Currently a state only has a single activity. I have been looking into modifying the state class to make it possible to have multiple activities (Many activities for one state). This will require most changes in the code generation where state machines are being analyzed.
  • I am currently looking into how the code generation and Jet templates work. I am looking for places where the code generation will need to handle the multiple activities for each state.

September 26 2014

  • I submitted a patch for Issue 629 (on Google Code).
  • I resolved this issue by changing the getExistsLanguage(lang) method from the Method class in the metamodel. I modified the 'getExistsLanguage' method to query the Method's CodeBlock and determine whether a language had been specified. If one of the languages specified for the 'CodeBlock' is not same as the 'lang' parameter, the 'getExistsLanguage' method returns false.
  • Note: This patch fixes the empty method bodies when generating Php and Java. It appears to handle language specific methods differently in Cpp and other languages. The method definition is still added in the generated Cpp code but a //TODO comment is included in the method body.
  • I will now begin looking into Issue 635 (on Google Code)

September 24 2014

  • I have been looking into Issue 629 (on Google Code) where this code:
      class A{
    public String doSomething() Java {
    return "Hello";
    }
    }
generates an empty method in Cpp and Php called 'doSomething'. My initial attempt has been to change the Method class which is inside the UmpleModel. The getExistsInLanguage(lang) method will return true for above code with getExistsInLanguage("Php"). I feel that this Method should not exists in the Php language if it has been specified for Java. My initial attempt to solve this issue was to modify the getExistsLanguage(lang) from:
  public boolean getExistsInLanguage(String lang) 
{
if(getMethodBody().getExtraCode(lang)==null)
return false;
else
return true;
}
to:
  public boolean getExistsInLanguage(String lang) 
{
if(getMethodBody().getExtraCode(lang)=="")
return false;
else
return true;
}
This worked correctly for my test case but affects other tests since Methods without a specified language will not be generated. I think my next approach will be to set the extraCode of a Method to null for all other languages than Java (for the above example).

September 23 2014

  • I have been assigned to state machine and do activity related Issue 629 (on Google Code) and Issue 635 (on Google Code).

September 22 2014

Code Sprint Summary

  • I had a great time in Toronto for the code sprint this past weekend. I am very glad to have met the other students and mentors in the Umple project.
  • This weekend, I learned a lot about Umple coding practices, test driven development and creating/submitting patches.
  • I spent the weekend working on 388 with Andrew and Tim. There were a couple of approaches that I tried before resolving this issue. The first approach Andrew and I attempted was to modify state machine definitions to be associated with different code languages. Some work was done towards changing the state machine (grammar) but was abandoned after discussion with Tim.
  • I backtracked a bit to revert the changes to the state machines. My second approach was a lot simpler than the previous. This approach was modify the Umple Internal Parser when analyzing active block definitions. 'ActiveDefinition' tokens were restructured into tokens for a state machine with a topLevel state, a threadLevel state and a do activity. In this approach I was able to associate the code blocks within an active object to a specific language.
  • The naming of the state machine tokens in this approach created a small problem. The previous implementation of the active objects calculated the total number of active objects in a class by counting the number of 'activeDefinition' tokens in the class token. The naming of the state machines depended on having the number of active objects. Since I was removing and replacing the 'activeDefinition' tokens with do activities, the number of active objects in a class could not be found by checking for 'activeDefinition' tokens. I modified Umple Internal Parser to increment the active object count whenever an 'activeDefinition' was found. I also reset this counter when entering a new class definition.
  • I added tests to check:
    Correct parsing for: the active statement
    Correct parsing for: multi lingual active statements
    Correct model (and language associations) for: multi lingual active statements
    Correct state machine naming with active objects

September 19 2014

  • Working with Andrew on active code specific blocks, and raised 629 for language specific method code generation

Current Goals for the Term

I currently working on my first issue (388) with multilingual active blocks and would like to resolve it as soon as possible.
I have interests in the concurrency and state machines in Umple and would like to focus on improving these areas as I continue this term. I am currently undecided on which larger issues I plan to work on. For now I hope to fix and patch as many bugs as I can.
Here are some of the UCOSP issues which interest me currently and may take up in the future:
324 : Translating examples in model repositories to Umple
611 : Allow generation of state tables and sample runs
240 : Support for Final state and End state in Umple along with Done and automatic transition.
497 : Implement a suite of graph walkng and analysis algorithms

September 17 2014

  • I have written some template tests that indicate errors with the generated output for multilingual active blocks (Issue 388 (on Google Code)).
    I had a bit of trouble trying to generate the correct .cpp.txt files. I found that using the command line umple compiler with the [-g SimpleCpp] option produced the matching Cpp code for the template tests.
The code below is an example where the output is generated incorrectly:
  class A{
active Java{
doSomethingInJava();
}
Cpp{
doSomethingInCpp();
}
Php{
doSomethingInPhp();
}
}
  • I have also found that when an identifier for the active block is given, the proper output is generated in Java, but not for Php or Cpp.
    So in this example:
  class A{
active activity1 Java{
doSomethingInJava();
}
Cpp{
doSomethingInCpp();
}
Php{
doSomethingInPhp();
}
}
The Java output will include the 'doSomethingInJava()' line.
The Php output will include the 'doSomethingInJava()' line instead of the 'doSomethingInPhp()' line.
The Cpp output will not include code from any of the blocks.
  • I will continue looking in to this. I will learn more about how these active blocks are represented in the model and how they are generated in to the target language.

September 15 2014

  • Last week I was assigned to Issue 388 (on Google Code). I have been looking at the active blocks and how well it is currently supported in Umple.
Using the example given in the Issue 388 (on Google Code) log (below), I have noticed that concurrent objects are not being created in the generated code.
class A {
name;

active Java {
System.out.println("Object "+getName()+ is now active);
for (int i = 1; i < 10; i++) {
System.out.println(" "+name+" was here");
Thread.sleep(1000);
}
}
Cpp { blah;}

public static void main(String argv[]) {
new A("1");
new A("2");
}
}
I had a closer look at the grammar for active objects:
activeDefinition : [=active] [name]? [[moreCode]]+

moreCode- : [[codeLangs]] { [code] }

codeLangs- : ([=codeLang:Java
|RTCpp
|SimpleCpp
|Cpp
... )* )?
By modifying the example as below, I found that the concurrent objects are being created correctly in the generated java code.
class A {
name;

active ObjName Java {
System.out.println("Object "+getName()+ is now active);
for (int i = 1; i < 10; i++) {
System.out.println(" "+name+" was here");
Thread.sleep(1000);
}
}
Cpp { blah;}
}

It seems that there is an issue generating the active objects when the [name] Identifier is missing. The language name (eg. 'Java') may be expanded as [name] instead of a [[codeLangs]]. So the following will successfully generate active objects in Java:

active ObjName Java { ... }
active Java, Cpp { ... }
active ObjName Java, Cpp { ... }

but this will not:

active Java { ... }

It appears the code is parsed correctly when the [name] Identifier is included, but there are problems generating code for other languages. No code is generated when put inside a Cpp{ } block. When generating Php, the code inside the Java { } block is generated in the final Php code.

My next steps from here are:

  • Create some tests that will fail when attempting to have multilingual code in an active block.
  • Look into the code generation for different languages (Cpp, Php ..) and ensure that the correct code blocks are being sent to the generator.
  • Look into the grammar for the ActiveDefinition and ensure it works when the [name] Identifier is omitted (maybe removing any ambiguity).

September 10 2014

  • I began looking at the Issues I could be working on in UCOSPIssues and SuggestedIssues. Issue 388 (on Google Code) interested me and I spent some time reading about Umple's parsing, metamodel and state machines.

September 9 2014

  • I am Learning more about how to use Umple by working through the SampleModelingProblems using UmpleOnline. I am becoming more familiar with the UserManual and the different feature of Umple.
  • I am experience problems when trying to compile 'Master.ump' inside Eclipse (Luna). Eclipse is reporting errors with the generated Java code. This looks similar to what Nabil and Mark are reporting in their logs. There are no errors when compiling and building from the command line.

Example code generated from Eclipse (umple/docs/DocumenterMain.java):

   // line 19 "../../../../src/Documenter_Code.ump"
public static void main(String [] args){
Thread.currentThread().setUncaughtExceptionHandler(new cruise.umple.docs.DocumenterMain.UmpleExceptionHandler());
Thread.setDefaultUncaughtExceptionHandler(new cruise.umple.docs.DocumenterMain.UmpleExceptionHandler());

Example code generated through command line (umple/docs/DocumenterMain.java):

  // line 19 "../../../../src/Documenter_Code.ump"
public static void main(String [] args){
Thread.currentThread().setUncaughtExceptionHandler(new UmpleExceptionHandler());
Thread.setDefaultUncaughtExceptionHandler(new UmpleExceptionHandler());
I will look into this further, but may just use the command line to build umple for now.

September 6 2014

Set up development environment for Mac OS (Mavericks 10.9):

  • Installed and tested the Eclipse plugin
  • Successfully ran a full build from the command line.
  • I had a bit of trouble when running the JUnit tests in Eclipse: The 'BuilderTests' failed when running through Eclipse but did not fail when they were run through the command line.
  • I read the BuilderTestFailingOnWindows wiki article and discovered that my Eclipse configuration did not have the proper path when calling ant. I resolved this issue by adding my system's PATH variable in to the run configuration in Eclipse.
Clone this wiki locally