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.

Log entries

December 7th

As of yesterday I finally committed my feature with almost everything completed for Java. However, I quickly learned that the build server does not support Java 7 libraries, specifically the java.nio library, which I used for my code. I used this library due to a bug in the Java 6 URI relativize function, where it is not able to return any paths that involve "../" . This of course is a problem for our code, where the paths will certainly involve a lot of "../"s. I had to comment out the relative paths, so it's using absolute paths right now instead (except for the case where the .ump is in the same folder). As of now, it appears that I have inspired an upgrade to Java 7 on the build server. This might allow my relative paths to work again!

On design

I want to improve the design of my addition, as currently it relies on going up the tree to find the UmpleModel and get the path, rather than the path being passed down by UmpleModel (reducing calculations and improving the style of things). This might get done over the next week, passed the UCOSP deadline.

On UCOSP and Umple

I had a great experience overall with UCOSP. The amount of work required was reasonable and it was a really valuable learning experience. My only regret was that I didn't organize my time as well as I could, but that is always going to happen with school - slowly getting better at that! On that note, working on this project was good practise for time organization. Throughout the semester I mostly ended up working on Umple only once or twice a week, with longer sessions. In most cases I ended up working on Thursdays, as I had the day off school and had the added motivation of having a group meeting the next morning!

Tim and Andrew have been really helpful throughout the process. Tim has been very consistent with helping with issues, and always checks our logs and keeps track of all of us. Andrew was invaluable during the code sprint in helping us understand the code base. We were all fighting for him, haha. Starting off was one of the hardest parts.

For new UCOSP students

Umple is a big project, and it's really confusing in the beginning. There is a lot of different stuff interacting, and lots of different build steps. In the beginning, you will be confused! There's templates, umplifying, compiling, and testing - there's a lot to it. But the effort is worth it, because by the end everything will come together, and you will realize it does make sense after all. Good luck!

November 29th

I've had some trouble getting relative paths working, as there is currently no support for that in the filename. Looking back, I should have probably committed a version of my build without relative paths before starting to work on them. Of course, I didn't know how much work would be involved, as a lot of the infrastructure just contains the filename without path. I've gone through a lot of the structure now and I've successfully been able to pass in the full path of the .ump file that is being parsed, which is a start. Next I have to figure out how to find the location of the output .java files. Is namespace the only factor involved here?

I've also made a test that tests my line comments. With this test done, the relative paths are the only thing keeping me from doing a commit and build.

November 22nd - Update

During my work today I discovered that my regex missed some state machine code injections due to an extra space. This broke one of the tests in my main project, so I posted a new patch to umple-dev that fixes this.

I've now managed to eliminate all the test failures in my main project, which is a big step forward. Next on the list (back to where I was ages ago before the indentation issue!): writing tests and making sure relative paths work correctly.

November 22nd

A couple weeks remain in UCOSP for this semester. I had a lot of issues with my patch for 350, firstly involving missing generated code, and secondly running across some conflicts that required merging.

I misunderstood the patching guidelines, where they said that generated code should not be included, but meant that it should not be included if not necessary. In my case, generated code was necessary because the templates were updated, but the system could not build given those new templates without the functions the templates called being already built. Adding the changed code from src-gen-umple solved this problem and allowed the build system to complete the build.

The second problem was that after I submitted my corrected patch some changes were made in the SVN before it was applied. This caused my patch to be out of date and not apply correctly. If I were submitting many patches, or if the Umple SVN updated more often, this could be a common problem, but in our case it's a relatively rare situation. Anyway, I simply had to perform a SVN update on my code, and resolve all the conflicts (which happened to be a lot!). After that I had to resubmit the patch to umple-dev and hope no more changes were made! Thankfully, I was in luck, and my patch applied.

Today I will perform an SVN update on my old branch working on line comments, and continue working on it for a little while, making use of my changes with issue 350 (on Google Code).

November 15th

Had a relatively busy week but submitted a patch for issue 350 (on Google Code) tonight. It's a partial solution that will at least allow me to continue working on my line comments issue.

I've looked into a more complete solution that indents pre-indented things correctly (does not result in extra indentation), however due to the nature of the code I've found it hard to implement. We have no way of knowing how much indentation is on the first line, since the token seems to start at the first character, which seems deeply ingrained in the parser. I can't think of a way to properly guess the correct indentation for the rest of the lines, because it mostly depends on the first line. I've tried various solutions but they all have problems, due to the main conceptual issue here.

I've come up with a hack that uses the character offset of the injection to get the indentation of the first line, but haven't tried it out yet since it depends on the Position variable being there, which is actually in my other patch for line # comments.

Anyway, I'm going to leave it as is for now. The patch at least is an improvement and I hope it applies successfully!

November 8th

After my discovery of issue 350 (on Google Code) when working on Sunday, I decided to focus on fixing that issue before continuing on my line comments, as it directly affects them.

To fix issue 350 (on Google Code), I created a new function to add proper indentation to multiple lines in GeneratorHelper, and then went to fix the templates. Since there are a huge amount of templates that add indentation incorrectly right now, I had to write a regex to replace them all at the same time, while maintaining their subtle differences. After applying this replace, I had to make some small changes to some files that were breaking tests, as my indentation function now assumes that there is no pre-existing indentation.

Fixing this issue cost me a lot of time today, but with these changes done // line comments can now be added smoothly. I've made a patch for the changes I made today which modifies a total of 249 files, wow! I should note that this change was made across all languages.

However, due to the nature of my change another issue has arisen. Before, with no pre-existing indentation there would be no indentation at all. Now if there is pre-existing indentation, there is excess indentation, which is not good for multi-lined injection. This doesn't break any code, nor break any tests, but this means the patch doesn't completely fix the original issue. I'm going to fix this before submitting the patch, and I want to add a test to it as well. However, the current patch has been submitted as a comment to the issue as it is the first step towards fixing it. Will discuss this with Tim tomorrow.

October 30th

Did a little work today on the tests. Managed to fix template tests since those already have their own line-by-line testing function. I put in a check that ignores an unmatching line if it is a // line comment in the actual output.

However there are still a lot of tests failing. I found that these failing tests are the ones using Assert.assertEquals manually. I wrote my own assertEqualsSafe in the AssertHelper class, which I'm using for a few of those. Seems to be working but there are still a couple lines that are producing errors, so I'll look into that later. My assertEqualsSafe is more or less an exact copy of the code in the template class, except it tests strings rather than files. I'd like to combine these to make for better code.

Anyway, I'll pick it up again later this week. I'm not sure if replacing all the assertEquals is the way to go. However, since the line numbers will easily change it might be the only way to go, since the only alternative would be editing the expected templates.

October 27th

The goal of my session today was to finish line comments for all the required scenarios. I'm happy to be able to say I have completed that goal.

Line comments now work for:

  • Classes
  • Methods
  • Extra code
  • State machine guards, activities, and actions
  • Before/After code

I had to fix the code for transition actions, where I had forgotten to add it to the jet templates.

Before/After code proved to be a little difficult, since there were a lot of different places in the template that it was being output. In many cases, the source was Umple generated therefore line numbers need not be added.

To put the code output all in one place, I had to make a change to the class GeneratorHelper's toCode method, which tured out to be the source of a lot of frustration today. After my change, comments would be added to the front of the code. However, the way I did this was to concatenate the comment string and code string. Today I learned that if a "" string is concatenated with a null string, it outputs "null" as a string. This was not desired, and ended up polluting the generated code with the word null everywhere that there were before/after statements checked. In reality, nothing was supposed to be output when the code was null.

The fix for this was a simple if statement to check if it was null before concatenating the strings, however there were a lot of compile issues.

Since I had run umpleSelf already, the generated code was full of these null statements, which prevented it from compiling. Since I could not fix this bug in the compiler without the code compiling, I was kind of stuck with a chicken-and-egg problem. Once I discovered this was the problem, I compiled a stable umple.jar file from the current SVN and used that to temporarily regenerate the code properly. After the code was regenerated, I was able to compile the compiler, then regenerate the code with my new version. Self-compiled languages are confusing!

However, today was a great learning experience and once I moved on from that I got a lot done. Next step: fixing tests! (Which should have actually been the first step according to test-driven development... oops!)

October 25th

The broken state machine building from last session was actually just due to some null pointers. Since I had lazy init set up for positions, and positions were uninitialized, I had some null pointers. In reality, there are some situations where the position may not be set, such as in test cases where they are manually generated, so the lazy keyword will stay. I put in a != null check for all the line outputs, and today I finished the initialization for them when they are generated normally.

As far as I can tell I'm basically done fixing the issue for Java, however there may be some situations I am still missing. So far I have completed line comments for:

  • Classes
  • Methods
  • Extra code
  • State machine guards, activities, and actions

Just realized there is also the before/after code to finish as well.

These are all the situations mentioned by Tim in the issue itself, however there may be some more we haven't thought of. At the meeting tomorrow I will discuss this with Tim.

I still have to make it work for relative paths, which I haven't done yet. So far it's just showing the filename without a relative path. My assumption is that the relative path should be displayed as the path to the source file relative to the current .java file.

My goal is to get everything working perfectly with Java first before changing to other languages. I haven't written any tests yet, and I still have all my tests failing due to the outputted code being different. This will be the next thing I look into if I've covered all the situations.

My understanding of state machines is weak, so I had some trouble finding the locations of where all the line comments should go in the output file. I'll post what I have currently below:

 1 namespace example;
 3 class LightFixture
 4 {
 5   bulb
 6   {
 7     On {
 8      entry / { doEntry(); }
 9      exit / { doExit(); }
10      push -> /{ doTransition(); } Off;
11      do { doThisContinuouslyWhileOn(); }
12    }
13    Off {}
14   }
15 }
/*This code was generated using the UMPLE modeling language!*/

package example;

// line 3 "state.ump"
public class LightFixture


  //LightFixture State Machines
  enum Bulb { On, Off }
  private Bulb bulb;

  //LightFixture Do Activity Threads
  Thread doActivityBulbOnThread = null;


  public LightFixture()


  public String getBulbFullName()
    String answer = bulb.toString();
    return answer;

  public Bulb getBulb()
    return bulb;

  public boolean push()
    boolean wasEventProcessed = false;
    Bulb aBulb = bulb;
    switch (aBulb)
      case On:
        wasEventProcessed = true;

    return wasEventProcessed;

  private void exitBulb()
      case On:
        // line 9 "state.ump"
        if (doActivityBulbOnThread != null) { doActivityBulbOnThread.interrupt(); }

  private void setBulb(Bulb aBulb)
    bulb = aBulb;

    // entry actions and do activities
      case On:
        // line 8 "state.ump"
        doActivityBulbOnThread = new DoActivityThread(this,"doActivityBulbOn");

  // line 11 "state.ump"
  private void doActivityBulbOn()
    catch (InterruptedException e)


  private static class DoActivityThread extends Thread
    LightFixture controller;
    String doActivityMethodName;
    public DoActivityThread(LightFixture aController,String aDoActivityMethodName)
      controller = aController;
      doActivityMethodName = aDoActivityMethodName;
    public void run()
      if ("doActivityBulbOn".equals(doActivityMethodName))

  public void delete()


As you can see, for activities it goes outside the method itself. However for actions I have it right above the actual code. I'm not sure if this is the ideal display or not. I'll discuss it tomorrow at the meeting.

October 23rd

At the end of the day, I seem to have broken code generation for state machines in my build! However, I'll be sure to get that fixed next session.

Today I've worked on adding line numbers for generated code including state machine guards, activities, and actions as requested in the issue. State machine templates are quite a bit more complex and difficult to understand than some other elements, so I've had some issues. Theoretically though it should work very soon, it's just a matter of fixing a few small bugs.

For loose generated code, the line output is already working fine. Since the output is not affected by language anyway, I put the comments directly in the code itself (the generatedCode string) rather than in through the templates. I'm not sure if this is considered bad design or not, but I don't see any big issues with it. Since the generated code is just stored as a combined string rather than as objects, it wouldn't be that simple to add a position variable to it to be parsed by the template. However, if this was preferred I could add one.

Oh, I also added line numbers for methods, which was trivial.

It's coming along fairly well and I'll continue working throughout the week. Today's session was shorter than planned due to some things that came up, but I'll make up for it over the next few days.

October 16th

Today I fixed the problem with multiple sources for class definitions. Classes and interfaces now both have a list of Position variables for multiple sources, rather than the statically defined line number and file name variables before. Position variables contain the line number, filename, as well as line offset.

Now, when injecting the // line comments Umple will inject multiple lines for those classes that are designed using mixins.

For example:

class X {
  Integer stuff;
class X {
  Date helloDate;

The above code is a mixin, where X is defined in two different locations. Umple supports this, and a class named X will be created with both variables. That is, both definitions of the class will be mixed together. In this situation they are both in the same file. Next we'll see the java code output.

// line 1 "polygon.ump"
// line 5 "polygon.ump"
public class X

As you can see, both line 1 and 5 are now injected into the comments above the class definition. Of course, if mixins are not used only one line will be output.

An interesting thing today was that after refactoring some variable names I ran into some problems. The problems were reported to be in the generated java code from Umple. To solve the problems, I had to locate the Umple source files, and thanks to the new comments they were very easy to locate. This really made me feel like what I have done will be very beneficial to Umple developers and users, and inspired me to work harder!

Next I will work on injecting source lines for "extra code", ie. the contents of classes. This should be easier to pull off since I do not have to worry about mixins. However, it will be more difficult to understand the structure of how class contents are done in Umple.

October 12th

Since the code sprint finished I had to set up the environment on my home computer. I had very few issues with this, and it went smoothly after my experience with the code sprint. It also helped that I was using Linux, so less workarounds were involved.

I have now been assigned to issue/project 231, regarding adding comments to specify the umple file and line number origin of generated code. This is an interesting issue, as it requires the origin of classes and each method/variable in that class as well. So far, I have it working for the simple case where we have a class that was defined a single time. My code outputs a line # above the class definition so far.

As discussed with Timothy today at the meeting, I will look into class line numbers when mixins are used. In that situation, there may be many different definitions of the same class that are mixed together by the compiler, presenting problems for identifying the origin. Perhaps multiple lines of comments may be necessary, as those definitions might be in different files altogether. We also decided that for now the character position on the line should also be added, since it is provided by Umple's Position type anyway. However, we need to make an effort to stick with the standard format that's used by parsers.

Work is going well and I will continue to work on Umple this weekend. There will be another update following my next milestone.

September 29th

The first day of the code sprint went pretty well, and I feel that as a group we made progress to the point where most group members have been assigned issues and are working on them.

However, a lot of us are still having problems setting up the development environment. Especially those with Windows.

First, I am going to go over the solution to the duplicate class issue discussed above. Both me and one other group member have encountered this issue, but we don't know the cause. Somewhere down the line some files were copied that should have been. We ended up with some java files in the build folder, which were copies of those already in the cruise.umple folder. I don't have details of those files now, but another post is being made by Stuart Erskine with details.

To solve the issue, we just had to delete those duplicate files. This was easy to do by checking the SVN status, and identifying the non-versioned files. After this, the problem never came back, so we have no idea what the cause is.

At this point, I am able to build the code but there is one test that still fails. This is the BuilderTest, which fails with two errors: java.lang.ClassNotFoundException: MeToo java.lang.ClassNotFoundException: Aha.MeThree

A few of us have this problem, so hopefully we will figure out a solution soon. After that I think we will finally have a working environment to properly develop under. In the mean time, we can continue while ignoring this test, but that is less than ideal long term.

September 27th

I've been attempting to get Umple to compile in Eclipse. I eliminated a bunch of errors, but ultimately had some problems remaining, probably due to library linking.

As an alternative, I tried to build Umple using Ant, as I thought that would probably be the best way to build it anyway. I believe I have all the dependencies, and installed ant-contrib. Following the instructions in the Development Set Up wiki page, I ended up trying to build with the command: ant -Dmyenv=wlocal -f build.umple.xml build This is due to my environment being Windows (temporarily). However, regardless of what changes I make, I end up with an error that says:

javac E:\Documents and Settings\Andrew\My Documents\Code\umple\cruise.umple\src-gen-umple\cruise\umple\builder\Builder.java:9: error: duplicate class: cruise.umple.builder.Builder

javac public class Builder javac ^

Which also applies to the Command and DynamicClassPathLoader.

This is using the latest SVN downloaded version. I can't figure out how to solve it at the moment, so I'll continue working on it for the code sprint tomorrow.

September 6th

Today I will recount some of my first experiences with UmpleOnline, where I tried out some of the most basic features.

My experience overall was quite good, and I was able to create classes in the visual editor and have the code dynamically generated, and the other way around. I noticed that the refreshing script for the windows is quite intelligent, and refreshed appropriately when modifications were made to either side.

One thing I quickly noticed was that if there was a syntax error in the code, the visual screen only showed: "Diagram is out of synchronization with the text due to selecting Manual Sync or an error in the text." At first, I didn't notice the more detailed error messages at the bottom of the page. When editing, I would edit the script on the left and then look on the right for the results. I think a lot of users would make this same mistake and not immediately notice where the detailed error messages are actually output, so perhaps a better design would be to locate them in the right window, or at least output a message that states they are at the bottom of the page.

Another thing I noticed is that when there is a syntax error, and the "Generate Code" button is pressed, the response below the button is still "Done. See below", and then an error code is displayed below. A better response might be: "Code generation failed due to syntax errors. See details below."

One of the first mistakes I made when experimenting with Umple code was that I attempted to create an association with the line: 1--1 Person; This does not work, and an association should be done with spaces like: 1 -- 1 Person; However, the response was confusing as in the visual screen it created a variable of type 1--1 named Person instead of an association. This of course is syntactically correct according to the way variables are declared, but it is unlikely users want a variable type named 1--1 or --, and perhaps a warning should be output. A warning would be important especially for UmpleOnline, as a lot of new users would use it to experiment.

With that I conclude my notes for my first look at UmpleOnline. In the near future I will be installing an Umple development environment and recording my experiences with that.

Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.