Skip to content


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 y 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 in reverse chronological order

Dec 2nd

In the latest UmpleImport, r3264 (on Google Code)

  • Major feature
    1. Implement Association which support both bidirection and unidirection translation.
    2. Executable integrated into umple.jar, invoking by passing -i or --import followed by an ecore document.
    3. Large scale examples as test cases referred from the ECore Zoo.
  • Minor improvements
    • Singleton, lazy and more comments.

By this point, I think the major part for UmpleImportECore is done, however, more tests and bug fixes are required to make it perfect. If I have time, I will add abstract class and multiple package support to the ECoreHandler later this week.

Also updated user documentation for multiplicity syntax highlight in r3252 (on Google Code).

Nov 27th

Stuck on UmpleImport associations but I will be able to work it out. Will have around 12 hours to work on Umple next week. Should be able to check in association patch and get start on XMI2.1.

Committed Unidirectional Reference support for ECore generator and close issue332 (on Google Code) ECore update. Just noticed that ECore2.0 will release in June, 2014. Hope there will not be too many XMI syntax changes.

FYI, unidirectional reference support means different ECore will be generated for:

class A
 * aEnd <- * B bEnd;

class B{}
class A
 * aEnd -- * B bEnd;

class B{}
class A
 * aEnd -> * B bEnd;

class B{}

Nov 22nd

Created another patch for issue220 (on Google Code) with respect to yUML generation. Implemented method support and scoping support for both attributes and methods.

Close issue461 (on Google Code) one-to-one association with lazy attribute. JET was fun. JET to code is like PHP to webpage, they both look messy and confusing at the first place but can generate magical end results somehow. Spent most of time tweaking test cases for all languages. A better way for doing those is to temporary comment out the teardown methods so that you can access those generated files and then use diff tool to check whether the updated part make sense before tweaking the existing test cases.

Commented on issue423 (on Google Code) private static to const. My concern was that they are not equivalent and my suggestion is to implement internal const so that it generates private static final.

Nov 19th

Before continue working on associations for UmpleImport, I decided to check in the existing copy to be agile enough :)

In the latest UmpleImport

  • Major feature
    1. Implement DataType and Class attributes for the ECoreHandler
  • Minor improvements
    1. Error handling to make XMI parsing more robust.
    2. use const instead of public static final to reduce the amount of extra code
    3. use of associations instead of manual model bindings.
    4. use String[] instead of self-defined ArrayList<String>

By saying that, I really hope that issue96 (on Google Code) Multiplicity for List attributes is supported, because those information can be handled better when parsing the Ecore XMI. But I don't think I will have time to work on that due to other projects and finals. Something to do with UmpleToTemplate though.

Commented on issue298 (on Google Code) singleton with Java enum, after I updated the syntax, the src-gen-umple is not able to compile due to debug annotations. Maybe it's because enum is generated during compile time while the annotations are runtime. I might be wrong.

Raise and fix issue458 (on Google Code), another singleton related issue, but much more straight-forward. Just needs properly handle predefined variables and const. With that fixed, I can use singletons in UmpleImport in the next iteration.

As per issue220 (on Google Code), it finally became a yUML feature update. yUML is so much fun. Interface inheritance is now supported in yUML generation. There seems to be a bug in yUML where interface cannot have attributes properly displayed. There are some workaround by using Unicode, but I don't like that.

Nov 16th

Checked in the umplified version of UmpleImport prototype in r3207 (on Google Code). Now working on class attributes and hopefully associations later this week.

Interesting things found during umplification:

  1. Umple doesn't support string-based switch. So I have to use if-else if instead. C'est la vie.
  2. Overloaded constructors are treated as extra code. Better if there is a way to detect and organize these constructors.
  3. Is there a way to override methods of an external class? Otherwise they are put under DEVELOPER CODE - PROVIDED AS-IS. Like does.

Also take a look at issue298 (on Google Code) singleton pattern. Since umple only compiles in jdk1.6 just a little bit concerned whether enum form of singleton pattern will be supported. Anyway, I will give it a try.

Nov 14th

During the umplifying, issue245 (on Google Code) is really bugging me because the import statement doesn't get down to the grandchild class, i.e., class dependancy problem.

I made the original fix in the JavaClassGenerator through jet template but later I realize that the updated logic should be encapsulated in JavaGenerator so that it became a more robust and straight-forward implementation level fix.

I also raised issue455 (on Google Code) during the testing of ECore generation. What happened was that when multiple interfaces are associated with one class, only the first interface is getting parsed. So I added loops to traverse all associated interfaces and append the corresponding xmi to the string builder.

It's also interesting to notice that the change also has impact on Master.ecore where missing interfaces appears.

That's the note for today's commits. Now move on umplifying...

Nov 13th

Working on UmpleImport during the last week.

Wrote a small benchmark test on JAXP framework for stream-based vs tree-structured processing in particular. And it turns out that a stream-based push API called SAX is more suitable for this project since it consumes less memory and we don’t need the XPath feature for tree-structured DOM/jDOM to parse an xmi file.

A note for SAX project, surprisingly, there is no copyright for this API as stated in Copyright Status:

SAX is free!
In fact, it's not possible to own a license to SAX, since it's been placed in the public domain.

In terms of the project, I completed and checked in a prototype version of UmpleImport which parses ecore xmi and obtain the corresponding package, class and interface names. It’s written in Java, so I will umplify the project and integrate it into cruise.umple in the next iteration.

So at last, this project will be written in umple and compiled to Java which will generate umple out of various xmi versions.

Additionally for the umpleImport prototype, build.xml is provided in root level which will perform clean, compile, run and test by default.

Nov 6th

Work on importing XMI, doing some research on third-party library XMI parser, however, all of them are under GPL license, which I think is incompatible with Umple's MIT. May end up using XML parser and making some modifications.

Also learned about current XMI standard which is XMI 2.4.1, however, for ecore, I only find XMI 2.1 online. As soon as I figured out the latest standard, I will update issue332 (on Google Code), the Ecore generator update.

Nov 3rd

Refactored existing logic for checking warning condition in order to support not only the inline association but also independently defined association.

Inline association

class A
class B
  1..4 -> 0..1 A;

With warning generated

Warning on line 5 : The specific multiplicity bounds [1, 4] cannot be managed by generated code, since this is a directed association.. More information (36)

Independently defined association

class A
class B
  1..4 B -> 0..1 A;

And the corresponding warning

Warning on line 7 : The specific multiplicity bounds [1, 4] cannot be managed by generated code, since this is a directed association.. More information (36)

In terms of testing, I overloaded function to support checking multiple warnings for each test case

public void assertFailedParse(String filename, int expectedError, int expectedErrorIndex)
    boolean answer = parse(filename);
    Assert.assertEquals(false, answer);
    Assert.assertEquals(expectedError, model.getLastResult().getErrorMessage(expectedErrorIndex).getErrorType().getErrorCode());

Where in my case, non-constraint warning is defined as type 36


Oct 31st

Spent a few hours just to figure out that the constraint that issue347 (on Google Code) referred to actually means association in umple grammar. After working on the right object, which is UmpleInternalParse_CodeClass.ump, everything is straightforward again.

Side note for association multiplicity:

Multiplicity Name
* 'any number' or 'many'
1 'mandatory'
0..1 'optional'
1..* 'mandatory many'

Warning message was added under en.error file:

36: 3, "", The specific multiplicity bounds {0} cannot be managed by generated code, since this is a directed association. ;

Things left up to this point:

  1. Cleanup existing test cases since this additional warning message fails several assertion methods
  2. Update user doc component instead of pointing to PageBeingDeveloped.html

Oct 30th

Still got the ant issue but I leave that alone and continue my work on issue347 (on Google Code) which is putting warning when that is a hard constraint, say [1..4], on the non-arrow side.

I start by add test case for and modifying UmpleInternalParse_CodeConstrain.ump to put the warning in the appropriate place. Should be able to make a patch by this week.

Also started to work on import/export umple by trying to get all files ready and hopefully accomplish something by this week.

Edit: Error message for eclipse Junit failure

java.lang.AssertionError: expected:<true> but was:<false>
	at org.junit.Assert.failNotEquals(
	at org.junit.Assert.assertEquals(
	at org.junit.Assert.assertEquals(
	at cruise.umple.builder.BuilderTest.executeSimpleAntScript(

Solved by:

  1. Run Configuration...
  2. Environment tab under Junit
  3. Select... and choose PATH and make sure it contains the path that "which ant" has

The reason for this error is that the "ant" that eclipse referred to is not the same as the one we use on command line.

Oct 29th

Stop working due to personal reasons, but now I'm back logging!

In the last week, I did my Mavericks upgrade on my Mac so I need to reinstall ant, java and command line tools in order to build from command line, work from eclipse and reveal changes in local umpleonline.

The only issue left is the eclipse test failure for executeSimpleAntScript. I have seen this error during the code sprint and I believe it has something to do with ant settings.

Oct 2nd

Will continue work on issue 332 (on Google Code) ECore generator update.

For the Ecore generation task, it seems to me that the schema hasn't been changed much. However, I will still need to verify that by installing EMF and generate some Ecore XMI using the latest package.

Sept 21st

Learned yUML syntax (which can generate UML diagrams) and worked on issue 243 (on Google Code).

[User],[Client],[Client]clients *<-user 1[User],

Learned papyrus XMI syntax (close to XML) and add support for Float attribute for issue 28 (on Google Code).

<ownedAttribute xmi:id="Car-value" name="value" visibility="private">
      <type xmi:type="uml:PrimitiveType" href="pathmap://UML_METAMODELS/Ecore.metamodel.uml#EFloat"/>
      <upperValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="Car-value-_upperValue" value="1"/>
      <lowerValue xmi:type="uml:LiteralUnlimitedNatural" xmi:id="Car-value-_lowerValue" value="1"/>

And worked on issue 408 (on Google Code), where updating syntax highlight for regex bound support in User Docs.



Generate docs:
ant -Dmyenv=local -f build.umple.xml packageDocs

Docs location:

Sept 20th

Learn about grammar for umple, work on issue 379 (on Google Code) and create unit test and patch for it.

Create patches:

svn diff -x --ignore-eol-style > ~/patch-TIANYUANCHU-379-semicolon_extracode.diff

A neat way to specify global svn ignore property:

cd ~/.subversion
vi config
global-ignores = *.class bin Bin obj Obj

Sept 19th

Eclipse env setup. Full JUnit tests without errors.

Sept 18th

Set up local copy of UmpleOnline

Error: mkdir() [function.mkdir]: Permission denied in ...
Fix: In httpd.conf, change User from _www to your login user name

Take a look at issue 379 (on Google Code) and issue 399 (on Google Code). They are both defects marked as very easy, so I though they might be a good point to start working.

Sept 11th

In the last week, I've been working on development setup and going through resources on Tutorials and Sample problems.

For the dev setup, problem still exists in the eclipse setup (command line build and tests are successful), I have followed the steps, but seems still not working properly and I've noticed that src-gen-jet\cruise.umple.compiler package is missing. Maybe it's because of my project setting problem, I'll do a fresh check out to verify.


It turns out that we need to edit the Exclude property under the source type and also remove some source entries.
The updated Development setup guide works for me

Next week I will focus on exploring and getting familiar with the code trunk and also UmpleOnline associations and state machine.

Clone this wiki locally