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

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

NOTE: Entries are listed in reverse chronological order.

December 3rd - December 10th

More work on 304. Updated the meta-model to contain arguments for events. As I hadn't previously touched JET templates or done any implementation tests I spent some time learning that. Implementation tests have been put in place for Java, PHP, and C++ and the relevant code changes have been made to pass those tests. At this point I'm not certain if Ruby supports state machines or not. In try.umple.org it generates code for SMs that looks correct, however I am not familiar with Ruby so I am not certain. There do not appear to be any state machine implementation tests for ruby, or any language besides the ones mentioned above, so I have not implemented this change in anything else.

November 27th 2012

Finished my first set of tests for issue 304 (on Google Code) and modified grammar to accept it. I had some trouble with the grammar not affecting the outcomes of the tests immediately as I thought they would, so I wasted some time trying to find the error in my grammar that was resulting in my test case always emitting "extra code". I've also been looking at the rest of the implementation. It looks like in order to have event arguments available to guards and actions all that needs to be done is emit the event with arguments inserted. For it to be available in state entrances, exits and dos it is still going to have to be passed from the generated event function to the setState method and/or elsewhere.

November 15th 2012

Started looking into Issue 304 (on Google Code), just familiarizing myself with the problem and the proposed solutions. Started by writing the .ump files for the test-cases.

November 9th 2012

Tim pointed out that the two strategies are not mutually exclusive; The general strategy can act as a catch all for whatever the specific strategy missed. I have implemented the first strategy and submitted a patch.

There were conflicts from an incoming svn update and I ended up accidentally reverting the file with my test. Fortunately all the test files were still intact so it was relatively quick to redo the tests.

I attempted to loosen the grammar for extra semi colons using r2145 (on Google Code) as a reference, but within the context of state machines, it is causing numerous tests to fail at least some of them due to differently generated code. I will have to look into this further. Generated code should not change as a result of this.

November 8th 2012

Located the relevant code with Tim's help and identified two strategies with which the problem could be solved. The first is a general strategy of checking generated extra code to see if it "looks like" a state machine and raising the error. The second is a specific strategy that changes the grammer to be more loose so specific problems could be caught individually in the parser for more resolution and more helpful errors.

November 2nd 2012

Started tackling the final segment of 318. Implemented all of the test cases necessary. I spent a fair bit of time digging around trying to find where the final decision for whether a token gets passed off as "developer code" is. As far as I can tell it is at a step somewhere above the state machine token analyser which means I'm back in unfamiliar code.

October 26th 2012

Finished re-factoring code so all valid identifiers are checked in the Token class. This took longer than I'd hoped as I had to stop and rethink it part way through. My initial plan had been to have a method in the token class that would check it's name against a regex to determine if it was a valid identifier, however during debugging I discovered that state tokens used the "stateName" property instead of the "name" property to store the token's identifier. In state machine transitions tokens where states can be generated implicitly a similar issue was present. As a result I changed the isValidIdentifier method into a static method and passed in the appropriate property.

October 19th 2012

Fixed a minor bug with the previous patch where the state name in question was not being shown correctly. Expanded the tests for invalid state machine names and invalid state names to be more comprehensive and more in line with the patch committed by Russell. Started re-factoring code so all valid identifiers will be checked in the Token class when necessary. No problems today.

October 18th 2012

Finally I'm making some progress. Rather than trying to debug the Umple code itself I have found it significantly easier to modify the Java files to get the desired effect (making full use of the Eclipse Java toolkit) and afterwards change the Umple code to generate the desired Java code. Hopefully this reliance on Java will lessen as I get more used to Umple. I have prepared a patch for part 1 of issue 318 (on Google Code) to throw a warning when using undeclared states. I've been having some problems with my wireless card, so I will submit it some time tomorrow.

October 12th 2012

After Tim voiced some concerns that I might be going about the previous segment in the wrong way, I began working on other sections of 318. I wrote the unit tests for the sections regarding error 150 and 152. As per the suggestion that the same checking code be used as for invalid attributes I followed up on bugs 330 and 337 to see the solutions used there. I've sent a suggestion to umple dev that the three solutions be centralized in some fashion for consistency and less code duplication. After getting the go-ahead I returned to work on part 1 of 318. I had thought I understood the state machine parsing, but that is evidently not the case. I have tried several methods to populate the list of undeclared states, but to no avail. I will consult umple-dev on the matter.

October 7th 2012

Finished writing tests for part 1 of error 318. Most of the solution is in place but the warning is not being added in the right place yet. I had a fair bit of trouble with a line of umple passing straight through without being umplefied. The problem turned out to be a result of whitespace not being recognized.Map Needed to contain no spaces) I'm not sure if this warrants raising a ticket.

September 29th 2012

The BuilderTest is still unresolved. I've selected the focus of my first fix: Issue 318 (on Google Code). The bug has since been elaborated to include a number of sub problems within the same ticket. I started to work on the issue that should produce Warning 50, following issue 295 (on Google Code) as a model for the process as much as possible. A large chunk of time was spent looking at the how the state machine code and the parser work as well as how the structure for the test.

September 28th 2012

Prior to this date I had gotten the Umple command line compiler and Umple Eclipse installed and working for small bits of code, but not yet working for compiling Umple itself. The problem was apparently the result of an error nine days prior that there had been a broken commit that wherein the java code had lowercase vector instead of Vector and for whatever reason SVN wasn't picking up on the relevant changes. An SVN revert fixed followed by a SVN update fixed that problem. Another problem still exists that causes the BuilderTest to have two errors (at load on MeToo and loadWithPackage on Aha.MeThree) and four failures (at compile, compileTwiceInARow, compileReturnsUrlToJar, executeSimpleAntScript). At Tim's suggestion I tried reverting my ant version from 1.8.3 to 1.8.2 which worked for him, but it didn't seem to make a difference. At Andrew's suggestion, the rest of the day was dedicated to finding a good bug to start with.

Replace this with the date e.g. Mar 22nd 2012

Replace this with the text of your entry.