UCOSPLogJeanChristopheCharbonneau

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

December 8th

So I found my solution to be too laggy for my satisfaction, and I wasn't particularly a fan of the fact that the association line was reset to a predetermined point rather than taking into account where it was in the original class diagram. I spent today working up a new solution, learning more how umpleonline positioning works. I now use the AssociationSnap function which uses UmpleClass's perimeter function to locate the closest point on the edges of the class diagram to the provided point. I use this as the new point for each of the association's ends.

This solution is much faster than before, however it now messes up reflexive associations since both ends seem to want to go to the same point. I will try to fix this if time allows. I really wanted to commit this so that at least the major problem will be taken care of and we can put all of Kenan's and my work on the real UmpleOnline.

December 5th

In the past week, I've been unlucky again. My laptop screen doesn't work anymore (no electricity is getting supplied to the screen), so I've had to use a spare screen at school to finish my assignments, but this only works with Windows(maybe my ubuntu is missing drivers to project to a second screen? I don't know, I'm a total n00b with this stuff), so I couldn't work on umple for a while. I wanted to remove my hard drive and plug it into my old laptop but it would probably void my warranty so in the meantime I'm using a Linux LiveUSB (therefore, yes I had to resetup everything again, and now it's PAINFULLY SLOW).

Anyways...

So I've fixed the association lines that were not redrawing themselves properly after toggling methods/attributes. Unfortunately, I don't really know if my solution is good because it is very slow but this may be only because I'm working from a USB and perhaps on a normal computer it would be fine.

Essentially, after days of not understanding why in the world the lines don't figure out by themselves that they're not connected to the class outline anymore, I decided to just fudge it. So when the button is pressed, I call a function which creates a new association line to the midpoint on the edges of the class diagrams and then trip any overlap. This ensures that the lines are always actually connected to the diagram, although the location might not be the same as originally (I attempted to take that into consideration by checking to see if any of the ends of the association was actually intersecting a diagram edge, but that didn't seem to work and erased some lines).

I don't know if this solution is great. I would like to have the lines just figure out that they're not touching the edge anymore and update themselves like generalizations do. I think this is because classes have references to their generalizations but not to their associations. It's really weird though because when you move a class diagram, then the associations do realize and update themselves...

I've also made sure that starting with attributes off and then loading the example doesn't mess up anything. Basically, anything thats not the default(attributes on, methods off) will call my update function before the canvas draws and make sure everything is presentable.

November 27th

So I committed last wednesday. However, Tim didn't really like that hiding attributes/methods messes up association lines(which I was going to fix afterwards anyways) so my commit wasn't forwarded to the official umpleonline yet, so I really need to fix this first.

Fixing the tests that broke(JsonTemplateTest and EditAction) wasn't too bad, it just involved adding an empty method array to the output json. The part that made me rage is that you can't just do:

ant -Dmyenv=local -f build.umple.xml template.test

You actually have to do a full build (which makes no sense to me because I only changed broken tests).

~

I haven't had much time to work this week since it's the last week of classes and I have pretty big assignments due. I will definitely work on Umple all the way after I'm done with regular classes.

I intend to first fix association lines so my project wasn't in vain. Then I intend to work on several issues: Displaying constant's values on umpleonline(and also having them sync to the code). I would also like to allow my methods and these constants to work with GraphViz. Lastly I want to add more keyboard shortcuts(some already exist) which is issue 49 (on Google Code).

November 17th

As mentioned in my previous log, I've been working in UmpleSync_Code.ump, adding the code to deal with methods in EditAction. I initially copied the code from attributes since that worked before, but then I realized methods are actually much more complex.

First off, a big problem was that I'm passing the method's parameters back from UmpleOnline as an array, but this is totally broken up in the Json format so I have to merge all the characters back together. I have a function for that since I need to do this for delete,new and edit operations. I couldn't have them as a string because I kept running into problems when a method had no parameters (there's probably a much more elegant solution). Ironically the fact that it was an array kept causing javascript errors when trying to use my hide/show methods button, and I have no idea why this is happening (I mean I know split() isn't defined on arrays but I have no idea why in UmpleMethodFactory the params are already sometimes arriving as an array). Can be fixed later, for now there's a lame way I made it work.

I completely understand how SynchronizationActions work now. They have a textparser parse the current umplecode into umple Token objects(left hand side) and a JsonParser parse the diagram json code into umple Json objects(right hand side). Then the go() method is implemented for the desired syncing behaviour by inserting data from the jsonparser into Tokens that are inserted directly into the textparser. Because of the way this is done, I realized that I wouldn't have any trouble leaving the method bodies unchanged when I edit the method signature in the class diagram: Everything is a token and I'm not touching that one further down the tree (and coincidentally, a delete to the method diagram deletes the method root token and so the whole token subtree so that's perfect).

So I first did the delete operation since thats the easiest. I just go find the method token (which, by the way, is "concereteMethodDeclaration" not "method" as I thought, and a method's name and params are actually in a subtoken called "methodDeclarator"), and delete the one which matches the name. It was only later upon testing I realize this fails for overloaded methods, so I had to add lots of code to fetch the method's parameters' type into an array and individually compare them to the json's types to make sure they all match.

Next I did new which is tricky because I had to go find where to insert the method. I had to find the last method token if there are methods, and if not, find the last attribute, or if not either, the start of the class(I also had to go change attributes, to make sure they were inserted after all attributes but before methods). Once I find the spot, I just insert a new method token with all the data, and create default names for the parameters like arg0, arg1, arg2, etc.

The hardest part that I've not perfected(because it's not urgent) is the edit operation. I go find the method using the same technique as delete (name, and matching parameters) and then make the changes to type or name or visibility or parameters. It's parameters I've not perfected. Currently, I'm just overwriting the left hand side because it would require lots of code to know where to insert/edit/delete the new param (lots of matching to do), and the only side effect of this is that the user provided names for the args are reset to arg0, arg1, etc. This can be fixed in the future, but I don't feel it's worth holding up my commit.

Right now I'm just fixing tests and finalizing stuff. I will be comitting what I have by Wednesday if all goes well, and little issues like what I just mentioned can be fixed at a later time.

November 14th

Working on implementing the ability to add methods from the diagram side is proving to be more complex than I anticipated. I realized that there are in fact 2 parts to this. First, I needed to be able to keep the data in the class diagram when it is input by the user, instead of vanishing immediately (and possibly deleting everything unexpectedly). Secondly, I need to be able to sync the diagram's code with the editor code.

That first part is done. I had to create a new umple_method.js file, which is pretty much exactly the same as umple_attribute.js, except for the fact that parsing the input into method visibility, type, parameters and name is much more complex than type and name for attributes. Methods that are input without a type are void by default, and without a visibility are public by default. Next, I had to add functions in umple_class.js to add, edit and delete methods to the class itself(not just the html), as well as event listeners (Actions) for the same 3 operations. The code is almost identical as for attributes.

I'd also like to log this:

• methods (or attributes) objects have their default member variables, for example: this.name, this.type
• When they are newly created, they also gain the member variables with the prefix 'new'. ex: this.newName
• When they are modified they have the prefix 'old'. ex: this.oldName
• When they are deleted, they have the prefix 'delete'. ex: this.deleteType

I'm pretty sure this is used as tags for the syncing with the editor side code. I'll know more when I work on that.

I also had to add a function to check the validity of the user's input for a method(yay huge regex!)

So the second part will have to deal with UmpleSync_Code.ump. I have figured out that whenever class diagrams are modified (especially by those 3 events mentioned above), there is an ajax call to compiler.php which executes UmpleSync.jar. I looked into MainCode.ump to find where it goes (based on the commandline parameters it was being passed), and it looks like it's doing SynchronizationActions. In particular I was looking at EditActions, which seems to be using JsonParser to parse the json passed from umpleonline's diagram side, and merging it with the current umplecode from the editor side. The json parser is not the problem I think since there's nothing in it specific to any umple features. I believe the EditAction is simply missing if statements to deal with my methods. I believe it shouldn't be too different from what I had to do in the javascript, essentially repeating the behaviour for attributes.

I will need to take into account method bodies which don't exist in the diagram side. A new method will need to be created with an empty body to be filled in on the editor side by the user. An edit will leave the body unchanged, and a delete will delete that body. I think this is fair. Furthermore, a method's parameters don't have names on the diagram side, only types, so I will need to fill those in with dummy names like arg0, arg1, arg2, etc, and apply the same behaviour as with method bodies.

I think I can be done this issue by next week. However, I've noticed that state machines seem to be broken on my local machine (no idea why since I didn't touch them), so I will need to fix that.

November 6th

So I've been working on displaying methods on UmpleOnline, as discussed in a previous google hangout. I finally got around to formally raising the issue as issue453 (on Google Code). I'm also working on issue 158 (on Google Code) which is about hiding attributes (and now methods).

Displaying methods on the umple class diagrams was very easy. All I had to do was edit Generator_CodeJson.ump to almost copy the way attributes were packaged into a json by Umplesync.jar . Then I had to edit umple_classes.js where jsons are unpacked and displayed into class diagrams to account for methods. I also had to edit the styles.css for methods (again, copying the same styles attributes had).

The harder part was to add the ability to hide attributes and methods.

I had to add actions in umple_action.js to handle the events(not yet decided whether it will be a checkbox or button). I had to go through a few ideas until I got it right:

1. Originally, the actions simply toggled the visibility attribute of the methods/attributes html, but this idea failed because they were clearly still on the canvas, just invisible (i.e. attributes left a gap, methods didn't get pushed up; also, the class diagram was still draggable/highlighted from the invisible parts).

2. My second approach was to remove the elements from the DOM when the event was triggered to properly hide stuff, not just make them pseudo-invisible. This mostly failed because I could not figure out how to re-add them again, and more importantly, adding new classes afterwards made the behaviour inconsistent(i.e. some attributes or methods showed, some didn't (was also a problem in #1)).

3. My last solution and the one I'm using is: Keep a static boolean in UmpleSystem that keeps track of the state. If allowed, add the html to the canvas to display the classes, and don't if not allowed. When the event is triggered, change the boolean only, and then call the method to redraw the canvas. This solution works because it is consistent and properly hides methods/attributes.

The only problem left with this is a width problem I have when removing parts and re-adding them. I had a height problem too which I fixed, but the width problem is annoying and I'd rather not write the ugly code I might have to write in order to fix it. I'll also need to decide whether I want a button or checkbox.

The last step to finalize issue 453 (on Google Code), and possibly the most complicated yet, is to allow methods to be input from the diagram side without screwing up anything. Currently, if anything is done to the diagrams(inputting or moving), the system freaks out and deletes everything on the editor side. This is because none of the methods exist yet to handle this behaviour. It should be more copying of attributes, but we'll see...methods have bodies which attributes don't.

There is also a slight concern about associations: the lines are not lining up to the classes properly anymore. Generalizations do though, so that's good. I'll have to look into that.

Naturally, I can't commit any of this until I'm definitely sure it's not super breakable, but it should be soon enough.

October 16th

So I still haven't committed issues 89 or 443 yet, but today I decided to work on issue 409 (on Google Code) since it looked interesting. It involved being able to declare keys and constraints before the attributes they used were declared. The mechanism for multiple analysis passes was already in place, I just had to find the way to use it.

At the beginning I was trying:

if(analysisStep == 1 || shouldProcessClassAgain)
{
  shouldProcessClassAgain = true;
  return;
}

to request a 2nd pass in analyzeInvariant(), but this didn't work, constraints were just completely ignored now (so the tests and build epically failed) and for the longest time I had no idea why because the same code was actually already being used in analyzeTraceToken() and analyzeLayoutToken().

Then after further figuring out the mess that is the overloaded analyzeAllTokens() and analyzeToken() methods(see below), I noticed that at the start of analyzeClassToken(), there is an if statement that ensures execution only on 1st pass:

private void analyzeClassToken(Token token, UmpleClass aClass, int analysisStep)
{
  if (analysisStep != 1)
  {
    return;
  }

This is to prevent the analysis from thinking there are duplicate attributes and such.

Therefore, there was no way to force a 2nd pass for analyzeInvariant() in analyzeClassToken(). So I pulled it out and put it directly in analyzeToken() in a new method I called analyzeDependentTokens(). I also transferred analyzeKey() there since keys had the same issue as constraints. analyzeToken() now does all the 1st pass methods first then calls my new method.

So now, this is approximately how the analysis goes:

parse()->
 analyze()->
  analyzeAllTokens()->
   analyzeToken()->  
    analyzeClassToken()-> 
     analyzeClass()-> 
      analyzeAllTokens()->  //not the same as above method, here it is overloaded to analyze a specific umpleClass
       analyzeToken()->  //also overloaded
        analyzeClassToken() //also overloaded
        analyzeDependentTokens()

So I committed it and now keys and constraints can be declared before their attributes.

So this is pretty much fixed now except for mixin classes which still cause warning 28. I have an idea on how to fix this.

October 9th

I've been extremely busy the past 2 weeks so I haven't had much time to work on Umple. Since my last log, I've reinstalled ubuntu 12 and did the whole setup again and now apache works! I ran into a problem though where my local umpleonline couldn't read the results from the compiler and for the longest time I thought it was a permissions problem and was chmod-ing everything. In the end I realized it was simply a problem that the path to java was wrong, so I fixed it and since I've been able to work on issues related to umpleonline.

Fixing issue 89 (on Google Code) was very easy once I remembered where to make the changes (I had found the place last time I looked at it, back when I couldn't test my results using a local umpleonline). Then the next thing I did was make sure adding lists as a type was also do-able from the diagram side, which previously wasn't since [ ] isn't alphanumeric. I thought it would be more complicated because the part that deals with fetching the type and name from the diagram simply does a split(":") on the data and puts the left half as the name and the right as the type, and we certainly don't want [ ] in the type of an attribute(goes in the isList). However, my understanding had been wrong and I noticed to my surprise that it worked perfectly as soon as I added ([])? to the regex. This is because it simply appends [ ] to the type, but in the code side not in the metamodel, which was my previous understanding. Then Umple parses the code and deals with the [ ] appropriately, as if it had been entered in the code side all along. I also noticed hilariously that the same regex only allowed digits from 1-8 not 0-9, so someone could not have entered a type containing a 0 or 9 from the diagram side previously.

I will continue to work on small issues on umpleonline like these, but now I have much more time to work on Umple, so I should be able to tackle bigger issues like before. I will commit my changes when I am sure I have enough time to dedicate in one sitting in case I break something.

Updates:

-fixed issue 443 (on Google Code) (not submitted)

September 24th

So I should definitely be writing a log to summarize the code sprint.

On thursday, as mentioned in my log, I worked on issue 419 (on Google Code) on the bus. Then on friday, the first official day of the code sprint, I worked on issue 386 (on Google Code). This issue was about comments for internal, const and derived attributes. Because these kinds of attributes do not have getters, any comments written for them were lost. I had to really learn how jet works so that I could know how to place the comments above the attribute declaration instead. I had a lot of problems with jet, which was only resolved at the end of saturday. More on that later. The other problem I had with jet was that I was editing the templates, but nothing was happening in the generated code. After a lot of frustration, I finally realized that I had not setup eclipse properly, since I've been using commandline only until now, and you have to use eclipse for jet. In the jet settings, you have to provide a directory for the generated code, which I hadn't.

On saturday, I decided I should finally finish issue 419 (on Google Code). I changed my implementation again from using a codeblock to using a list of codeblocks. Before, it would've been really messed up if someone had entered java code then ruby then again java, for example. The code specific to a language would've combined and it would've been all out of order. Now, each entry is an individual codeblock in extracode, so the order never gets messed up. With that, I was able to finish 419 and do my first official commit. That was pretty scary, but it all went fine. We got a tour of mozilla's office, and then Kenan and Greg both brought up the same problem I had on friday. Tim investigated into the revision changes and noticed that indeed, somehow, my patch from friday had deleted a bunch of code accidentally. But it wasn't my fault. After lots of investigating and some panic, we managed to merge the broken jet files with ones before they were broken. It turns out that Geoff had not followed the instructions to only edit the UmpleToTemplate files a few weeks ago in one of his commits. Those files are like master files and their changes get propagated to all the languages. He had only edited the language specific files. Then on friday when I worked on jet, the target 'codegen' propagates the umpletotemplate files, and so I overwrote geoff's changes, but some of the other code still depended on it. That's why it would always break after a build, but it worked when I reverted, but it never worked after my patch of issue 386 (on Google Code) because the problem had been committed.

Tl;dr always edit in UmpleToTemplate.

On sunday, we only had 3 hours but I solved issue 426 (on Google Code)(which I had raised) and issue 390 (on Google Code). It's hilarious because 390 involved just adding a ? to the boolean methods in ruby (convention). However, because I edited some jet (which worked perfectly now), and this change broke many tests, the patch ended up being a whopping 800kb!(just for adding a question mark...) So I got to do 2 more commits. Still scary but I'm very careful testing everything beforehand to make sure it won't break.

In conclusion, Tim asked us what we wanted to work on this semester. I think I would like to work on constraints, UmpleOnline, and design patterns. We'll see.

September 19th

Not much to say for now. I've been travelling all day to come to Toronto for the Code sprint. I worked on issue 419 (on Google Code) on the bus. I've made a new class ExtraCode to replace the string extraCode declared in umpleElement. The interface is still the same, but now it is implemented as a codeblock. Now in UmpleInternalParser, when the line number comment is added to the extracode segment, I have change it so that Ruby gets its proper form using the codeblock.

One thing I'd like to mention for today is how frustrating it is, and I don't know what causes it, when the java files don't update. I compile new umple code, and the java files just won't change. I notice this when compilation fails due to errors, and I fix them in umple but I keep getting the errors because they've remained in the java. Svn reverting them doesn't work. I was warned not to edit them, so I'm not sure how to deal with it. The only thing I've found for now is to rm them and then to svn revert. I wish I knew why this was happening.

September 16th

I finally submitted the patches for issue375 (on Google Code), as well as issue373 (on Google Code) and issue400 (on Google Code). Testing was frustrating because I did compiler and implementation tests and it kept failing for silly reasons(for ex: comments didn't match up). I learned I could check the xml files in dist/qa to see why exactly they went wrong, so that was helpful. Then patch creation was another nightmare because I didn't svn up before making the patch(at least I think that's why things went wrong). When I applied the patches on my test trunk they failed so I svn updated and remade the patches but that still failed, so I had to revert and reload my code from backups. Also, it seems like every time I svn up there's conflicts with tracers (I just accept their conflicts since it's usually just a path difference anyways so when I build, it comes back to my path).

So yeah, issue 373 (on Google Code) was quite interesting. I learned how code generators/jet templates work a little bit. This issue involved unimplemented void methods of classes inheriting from an interface. They were returning null which was uncompilable java code. I found where the code asks for a translation of the method return type into a value to return, and I added the type void as "" instead of the default "null" so it now writes "return;" instead of "return null;". As well, it was missing the return values for type double, so I quickly fixed that.

I finally created the issue about Ruby I talked about in a previous log (issue 419 (on Google Code)), although I'm not sure it's a template problem. I am learning about codeblocks to solve this.

I find it very handy to keep several trunks so I can work on multiple issues at a time independently, and that way I can make separate patches. I work only in commandline so it's not difficult to keep open more than 1 "workspace" if I wanted (actually useful when testing).

I'd like to come up with something original or work on something big, but I'm afraid of messing up and there's still so much I have yet to learn.

September 10th

Sorry for my lack of logs. The day after my last post, I continued working on issue 375 (on Google Code), got it to detect object construction, but I had a lot of trouble finding out whether it was possible to completely extract the info using regex. After lots of experimenting, I could not find a regex that could differentiate between, for example, new X(new Y()); (which is of type X) and new X().someMethod(); (which might return something entirely different) so I have only inferred object types for the basic case, that is, new X(); (inferred as an X). I have not made Umple complain about X = new Y(); because I don't have any way to know about inheritance). Furthermore, I realized that I was missing the builtin umple Date and Time types, so I added those. I also realized that the boolean values True and False are capitalized in PHP, so I will have to implement that.

Lastly on that day, I edited the regex for valid type names. Now it allows for a proper typename, followed optionally by <> inside of which I couldn't really match something specific since it's recursive, but at least that's a much better regex than before. I will have to amply test this, and run it by the bosses of course since I don't consider myself to have such rights.

Next I solved issue 400 (on Google Code) quite easily by checking to see if the attribute modifier is const before throwing the warning about it being in caps. But I have not submitted this patch yet, because like above, I have not tested it enough.

Since then, I've been working on issue 89 (on Google Code), which is labelled as very-easy...This is not very easy. It's maybe very easy once you know where to look, but finding it was extremely long. I had to look through dozens of php, javascript and umple scripts to completely understand what is going on on UmpleOnline. I can also say I've become quite good friends with grep.

In the process, I've learned that there's also many bugs if you type stuff from the diagram side. I would explain what I've discovered here but it would be lengthy. Suffise it to say that I'm worried I'm going to have to modify a lot of code, because neither direction cares about lists, only type and name, and isList is its own parameter in Umple, not part of the type. So either I add isList to every part of the way that deals with UmpleOnline(lots of steps) or I somehow encode/decode .md into the type.

I'm having problems with apache2 on my machine to be able to run a local copy of umpleonline. Until that works, I can't really continue this issue...

September 2nd

So today I decided to look at the different issues and think about how I could go about them. I decided to try issue 375 (on Google Code). It was actually quite simple. The issue was that attributes of undeclared type are by default String, and even if you initialized the attribute to anything, it would still be a String. ex: a=2 would be generated as private String a; and then later initialized to a=2; in the constructor. Thus it generated invalid code.

First I had to ensure that the attribute's type is null, because if the type is declared, then we have no problem here(actually,later Dr. Lethbridge showed me this was still an issue. more on that later). Then I added a few if statements in UmpleInternalParser_CodeClass.ump to check if the token representing attribute value matches certain regex's(had to learn about how Umple models tokens). For example, if the value matches -?[0-9]+ then I assign the type to Integer. Similar process for other builtin Umple types. If it cannot match anything, then I still assign it to String.

I tested my code with examples I compiled with umple.jar. Everything worked. So I followed the procedure I found on the website which said to make tests...but I couldn't find any documentation about what consists a test nor what to do with it exactly. I figured out there are two kinds of tests. There's the tests in cruise.umple/test which seem to be people's preference(seeing the huge number of tests in here), and there's the testbed. I believe the first way is to include your ump file and java file and Umple compiles the .ump and asserts that the java files are identical. This seems impractical to me because the test could break very easily in later versions. I chose to make a testbed test, which is basically: you include your ump class in a certain file related to what you're testing, umple it will compile it, and then you write a java class with a method that includes a bunch of assert tests you specifically want. Through reflection the testing process will call your method. This seems much less likely to break, but involves lots more preparation.

Then the next step is to make a patch. This was straight forward but quite scary because when I looked in the .diff file I saw a bunch of things I hadn't changed, hadn't even looked at! It seems like they were included because of line number differences or something. So I sent the patch to Dr. Lethbridge and he reassured me that it was normal that all those files had been modified. However, there was still a problem with issue 375 (on Google Code). Someone can still write String a = 2; and it will work, but is invalid code.

So I then added another if statement to check if both type was declared and value was initialized. I basically then just check if the type matches the inferred type and if so returns true, and if not, raises a warning(added a new warning in error.en). However, if it can't infer the type, such as with Objects, then nothing happens because then it's in the hands of the user. I have plans to work on this.

September 1st

I can't say setting up was without troubles. I followed the tutorial but of course when it came to downloading Eclipse Modeling Tools I got Kepler instead of Indigo and thus couldn't install Jet for no apparent reason. Afterwards, I installed the Umple plugin, and tried to build Master.ump with it, but nothing happened. So I switched to using the command line with ant, but that did not work either. After lots of reading up on all the stuff I don't know (quite a lot), I still had not a clue as to why the build failed on line 102 (apparently related to javac). I decided to get another fresh trunk and to NOT try the plugin on it this time, as strongly recommended by Geoff. Indeed, building it with ant worked flawlessly. He also showed me the command to build much more quickly next time, since building every time I make a tiny change would be long and painful.

So far I've read most of the manual (Alhough I have not covered State Machines yet) and some of the wiki. What I really found interesting was reading the .grammar files. I also started to read through the .ump files in cruise.umple, but it is hard to know where to start. I looked at UmpleInternalParser since that was related to grammar, but I definitely can't say I understand much yet. I hope eventually I can hold the big picture in my head.

I also tried some of the Sample problems on the website, which was excellent practice. p0 was a joke, but p1 was quite a bit more challenging since I had to write in my own extracode methods that used the getters and setters generated from attributes, with knowing if it works(since Umple doesn't actually tell you your Java code is wrong, it just copy/pastes it). I find associations harder to conceptualize than lists, but I can see their potential.

What I found more interesting for now was messing with UmpleOnline. I've found many issues, one of which I reported to Dr. Lethbridge. It concerned identifiers such as class names and attribute types/names and whether they should be allowed to be Umple keywords. I wasn't sure if this was a feature since most of those words are meaningless in the generated languages, or a bug since in no language can you use keywords as identifiers. I know how to fix it, should it be deemed a bug.

I've also found an issue with Ruby related to extracode. Umple writes a comment in the generated code saying which line the user's "as-is" code came from, but I'm assuming it does so in some .ump file for every language rather than in a Jet file for the specific language. Thus, Ruby code is generated with comments starting with // as opposed to #, which cause fatal errors. Java/C++/PHP comments use // , so I can see why this was overlooked when Ruby was added. I would like to fix this if possible.

I'm also quite interested in the SQL generation, since it seems to me like associations, keys and other features of Umple would be mighty helpful for sql.

Overall I haven't edited/written any code yet. I'm just learning my way around first.