UCOSPLogFiodarKazhamiaka

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

MMM DD

December 2, 2013

The past week was spent wrapping up my work on issue 287 (on Google Code). I found the correct jet file to modify, and spent some time looking up jet tutorials to get an idea of how it works. I found it pretty intuitive once I spent some time looking at the jet file and the corresponding generated code. I had a conflict when a ran svn update before committing, but I resolved it by running the codegen build command and generating a new JavaClassGenerator file in UmpleToJava. I wrote up a test and committed my change a few days ago.

I still need to go through the issue list and add comments to the ones that I have worked on over the term. I also plan on going through the manual and fixing any simple grammatical/spelling errors that I find, as I have seen some when I read through it at the very beginning of the term.

November 25, 2013

Over the past few days, I have spent some time finding a simple solution to fix the delete method (issue 287 (on Google Code)). I tested the issue using students and mentors with a Mentor 0..1 -- * Student association. I would like to change the delete method to something like the following code (yet to find the correct jet template to change, maybe I'm searching in the wrong place?):

public void delete() {
    while(!students.isEmpty()) {
      students.get(0).setMentor(null);
    }
  }

However, during my investigation of this issue I found that the result of calling setMentor(null) on a student does something very redundant. A call trace looks like this: student1.setMentor(null) -> mentor.removeStudent(student1) -> student1.setMentor(null)

If I were to change the call in the loop to removeStudent(students.get(0)), the call trace would look like this: mentor.removeStudent(student1) -> student1.setMentor(null) -> mentor.removeStudent(student1).

In both cases these is an unnecessary last call to the original method being called. This problem exists in the unchanged version of the delete method, and is not something introduced with my current fix. I am wary about making larger changes to the generated methods lest I screw up as the end of the term approaches. This problem doesn't break any code, so I will try and implement my current fix and plan on raising an issue about the problem.

November 19, 2013

I have started looking at issue 287 (on Google Code) a few days ago. I recreated the problem and then did some research about the exception being thrown. I documented all this briefly in a comment for issue 287 (on Google Code).

The desired behaviour of the delete method where there is a one-to-optional many association (eg. A 0..1 -- * B) is that the object where delete was called (A) has their list of associated classes (List<B>) traversed and the reference to A removed from each B in the list. The way this is set up right now has an additional modification where each of the B instances removes their reference from A's list of B's. Because this is done using an iterator through the list of B's, an exception is thrown because the iterator does not like the list to change size (which happens every time a B removes their reference from A's list of B's) while it is iterating.

The way around this seems to be to avoid using an iterator, but I haven't gotten the exact semantics of it down yet.

November 13, 2013

Today I have typed up three descriptions for warnings that will go into the Umple User Manual once Tim has approved them. I have also looked into the key statement to see if there are any other bugs in them. I found a couple, but they are small and involve me removing code rather than adding, so I did not raise an issue for them.

One of the bugs was the behaviour when a key statement is empty (key {}). This case has specific handler code in the parser, and I want to double check with Tim to make sure that we want a warning thrown here. The other bug involved the first end of an association (ie. the class itself) being treated as a valid key value for the class, and was solved by removing a few lines of code from the parser. I always question myself when removing code, since there is usually a good reason why it is there in the first place. Perhaps removing it breaks some function of Umple that is desired but not tested in the build? Hopefully my changes don't have any negative effects.

November 10, 2013

A few days ago a committed the work I did on fixing Issue 284 (on Google Code). I had to fix some of my code to make sure the parsing of association keys works as it should. Essentially, only the first letter of an association role name in a key statement is lower case and the rest of the letters stay unchanged. I had to make sure that if the class-name of the Association is given in the key statement instead of the role name, it would still generate proper code because the intentions of the programmer are clear and unambiguous.

Since I have familiarized myself with the parsing of keys, I'm going to spend a bit of time running tests in umple online to see if I can find any errors similar to Issue 284 (on Google Code).

November 5, 2013

I started working on Issue 284 (on Google Code). My first thought was that it has to do with Associations not being recognized as key values, thus generating incomplete code. A warning was generated when I tried to generate java code using the umple example given in the issue description, and this warning led me to believe that if I manage to get Associations properly recognized as keys, the issue would be solved.

As it turns out, if an attribute is a key value, it needs to be in lower-case letters in the key statement. I changed this so that it accepts both the lower-case version of the class it is associated with as well as the actual way the class is defined. This change, however, only removed the warning and did not solve the problem.

My initial thoughts on how to solve this issue were derived from the test case provided in the issue description. This example does not use a lower-case version of the class name in the key statement; when I replace the class name with the lower-case version in the key statement, the generated java code seems to be complete. I will need to discuss this with my fellow developers during the next hangout to see what the proper behaviour should be when the class name in the key statement is not all lower-case.

October 31, 2013

I searched through the warnings of template type attributes in order to convert any lists that I found into multivalued attributes. There was about 7 of them in total, and one (found in GrammarParsing.ump:115) I couldn't change because there were other methods that depended on it. Again I learned the value of triple-checking to make sure I won't break anything when I tried changing the List I found in Grammarparsing.ump. I ended up messing up some parser java files and had to use the set of aliases that Greg posted in his blog in order to revert the files before I could build again.

October 29,2013

I finally converted my first template type attribute into a multivalued attribute. The actual change took 10 seconds: I commented out

internal List<Comment> lastComments = new ArrayList<Comment>();

and replaced it with

internal Comment[] lastComments;

I did some research beforehand to make sure that this won't break anything, and found out that the generated java code for a multivalued attribute is just a list. So all the parser methods that use lastComments' list methods are still valid. Changing converting Map types will require some more thinking; I was thinking of making a class that contains the key and value as attributes and having a multivalued variable to hold these "key-value pairs", but that wouldn't mimic the behaviour of a map because it would allow duplicate keys. Mimicking this behaviour would require me to write a method for inserting values into the map-replacement, but this is basically rewriting the basics of a Map container which seems silly.

October 27,2013

This week has been slow in terms of umple work. I found a place in the code where I can check if the type of an attribute has angle brackets <>, and generated a warning. A full build showed that there were 36 places in the umple source code that threw the warning I just created. Making changes to all these source files would take a big push of work, and I am just starting to investigate how I should make the changes. It has been a busy week with school work, but I hope to make some progress soon. Once I figure out how to replace template types with a more umple-friendly type, I will document my method and let others (who are more familiar with other parts of the source code) replace the template type attributes elsewhere. After all, it is important that our source code follows our rules!

Update: I had some trouble committing for the first time. I looked at the blogs to see if anyone else had the same issue, and found that Greg had the same problem and discovered that he was supposed to use a generated password instead. For all you first time committers, the generate googlecode password can be found here

October 22, 2013

Today I started looking at how to fix issue 276 (on Google Code). It was suggested that I make a warning every time a collection type (eg. List) is used instead of associations in Umple code. This requires the compiler to first be able to differentiate between 1-dimensional and n-dimensional (n >= 2, ie. collection type) attributes. I don't see how this can be done in a general way, unless there was something that was common in the declarations of ALL n-dimensional types that could be caught by the parser.

I need to think more on this issue. In the back of my mind I feel like there is a simple solution that I'm not seeing, so perhaps I'll bring this up during the next hangout. After I am able to generate the warning, I will start going through the Umple source code and changing the attributes that are caught by the warning. It would be nice if Umple source code followed its own conventions!

I also had to check out new code because of my newly appointed role as a committer! Along with this came the usual half an hour of setting up the project in eclipse, setting up debugging configs, figuring out why the debugging configs aren't able to see a file that I'm passing in as an argument, etc.. The brief period when I couldn't get eclipse debugging to work made me appreciate what an especially useful tool it is for working on the parser!

October 16, 2013

Today I wrote up a test for issue 427 (on Google Code). I was hoping that the fix I made to comment attribution would work for Association Class as well, but this was not the case.

The problem is that Association Variables hold the comments of an association, but because the Associations in Association Class is unlinked until after all the comments are parsed, there isn't an easy way to attribute comments to these Associations because the Association Variables are made during the linking phase. This seems to imply that the Associations defined in Association Class can't have any comments attributed to them, but I did not test this further.

In order to make the tests, I had to familiarize myself with some handy methods that were no doubt made for testing purposes. One of these methods is numberOfComments(), found in both the Attribute and Association Variable classes. This function allowed me to easily compare how many comments are attributed to each Attribute/Association, which was very handy when testing my patch for this particular issue.

October 13, 2013

Today I wrote a patch for issue 427 (on Google Code). I actually started forming the idea of how to solve this issue a few days ago by looking through the Internal Parser code and using the eclipse debugger to step through the some tests. I found that comments are parsed in a way that means only the comment preceding a member get attributed to that member. In order to fix this, I had to keep track of the last attribute/association that was parsed, and compare their line number with the line number that is being parsed.

I was hoping that I could use the superclass of the Attribute and Association classes so I could keep track of the last one parsed, but this superclass does not have any Comments member. Thus, I resorted to using a a few variables instead. The AssociationVariable class that holds the comments of an association does not have a Position member, so I had to use the position of the token that is parsed to be the association for my comparison. It is not an elegant solution, but it works.

I also wrote a public method for the Position class that allowed me to get only the line number of a Position. These changes allowed me to write a function that adds comments to the last parsed association or attribute if the comment is found on the same line as the member.

All I have left it to figure out a way to write some tests. I have stepped through a couple test cases and found that comments are now attributed properly, but I don't yet know how to write a automated test for this behaviour.

October 8, 2013

It has been almost a week since I have last worked on Umple. My classes have kept me busy, but now I have some time that I will use to make up for my lack of work here.

I wrote a patch for issue 306 (on Google Code), which had to do with attributes that are used as key's also being given an initial value. The fix here was to show a warning, and while the code I wrote was very short, it took me a lot longer than expected. I kept trying to call String.equals(null), a rookie mistake because if the string IS null then I can't really call one of its methods without getting a null pointer exception. Once I figured that out, the rest was simple.

I also feel like the appropriate behaviour for issue 306 (on Google Code) would be to throw an error instead of a warning. If we are trying to give an attribute an initial value and also use it as a key, there is a contradiction. In such a situation, most of the time the user likely made a mistake and did not actually want the initialized value of a key to be the same across all class instances (contradicts the definition of a key), and would appreciate an error being thrown so he can fix the mistake. In the odd case that the user DOES want to have a key start with an initial value, Umple should be the "voice of reason" and prevent such a thing from occurring.

Of course, my argument is blown away if we can fathom a case where we DO want the keys to start with the same value. Anyway, my patch throws a warning, as requested.

October 1, 2013

I have almost completed working on issue 429 (on Google Code). I made my code give a warning instead of an error until the issue I described at the end of my last log entry is fixed.

I also wanted to make sure that my code solves the issue when there is a long chain of inheritance in Umple classes. The code seems to work most of the time, but not all time even though I ran the same tests. I showed my problem to Dr. Lethbridge and he was puzzled by it as well. He recommended that I move my code to another place in the parsing in hopes that I can avoid this problem, which will require some more digging to acquaint myself with the structure of the parsing.

UPDATE: moved the code and finally got the patch to go through. Time to start looking for other issues with the grammar and compiler. I want to focus specifically on making sure that bad code is never generated. It would be a huge bonus to Umple's usability if we can safely say that it generates only correct code.

September 25, 2013

The last two days of the code sprint were very productive. I was working on Issue 429 (on Google Code), which was much more challenging than the first issue I dealt with. A lot of time (~3 hours) was spent exploring the structure of the parser code in order to find out where I could add a fix.

I continued working on this issue after the code sprint ended. There was a problem with calling setFailedPosition to give an error because the position I wanted to use was null for some reason. I saw that a few lines of code above me someone else dealt with the same problem by making their own position and using it in place of the null, so I tried this out for myself. The result was that the error messages do not indicate the file and line numbers of where the error is occurring. However, this allowed my code to compile without any runtime errors due to a null position being used.

I tried building to see if my patch works. It works, but the build fails because there is code that fails to compile because the change I made causes it to be flagged as an error. The problem is that certain classes have attribute names that duplicate attribute names of their superclass, and issue 429 (on Google Code) is all about catching this and showing an error instead of generating code.

To summarize, I solved issue 429 (on Google Code), but it won't build until all the umple code is fixed so that it stops violating the duplicate attribute name rule.

September 21, 2013

Yesterday -the first day of the code sprint- was very productive. I tackled Issue 412 (on Google Code), and learned the process writing tests and how to test and submit the patch. The change I made to solve the issue was actually quite small, but I was only able to send in the patch at the very end of the day because of the time it took to learn this development process. I am very happy to have made a contribution to the project only 3 days after joining the Umple team!

Today I have started exploring Issue 420 (on Google Code) and Issue 324 (on Google Code). I have been searching for machine-readable examples of UML examples in formats other than Umple, and I have learned that these examples are tough to find. The best I have seen have been from embedded Umple examples on UmpleOnline that can generate code for other UML test formats such as TextUml, Ecore, Papyrus, and more. The idea is to go backwards, to automate translation of other UML text formats into Umple code. To test: 1. Umple code -> 2. other text format -> 3. translator -> 4. Umple code i.e. The correctness of the translator can be verified by comparing the Umple code at step 1 and step 4. Writing such a translator seems like a huge task, and I am not sure that I'm up for it yet.

September 19, 2013

Just got to the hotel for the code sprint. After many hours of trying, I am still having issues with the eclipse setup, hoping that tomorrow I can get some advice from the other group members and get everything running. In the mean time I have been getting familiar with Umple state machine notation, as well as how the mixin feature works.

I also checked out the Issue list to see if there are easy ones that I could start on for my first patch. Issue 412 (on Google Code) looks pretty straight forward, and I plan to work on it over the next few days.

September 17, 2013

Due to some confusion with UCOSP forms, I am just starting my work on Umple. The first step was to read through the user manual and familiarize myself with the program. After that, I played around with UmpleOnline to see how everything works.

Time to set up the development environment. I have eclipse set up on Windows, but Dr. Lethbridge strongly hinted that a Linux environment would be best so I decided to set everything up on my Ubuntu partition. Getting everything set up is proving to be a big pain, especially when I really want to get caught up on the development work. At first I was having an issue with installing Ant, and with running a full build (kept getting stuck on line 102 in the build.umple.xml file for some strange reason). I had to take a break to go to class, and when I came back and turned on my computer, the build worked! Looks like I needed to restart my computer after updating my environment variables and putting everything in the proper directories, but I don't know exactly which of my many changes since the original build fail fixed the problem.

Continuing with the next step: setting up the project in eclipse. After changing the Java Build Path properties, I wound up with 5777 errors and 75 warnings... great! Noticed that eclipse was using an older vesion of the java jre, and after setting the default to be the latest release, I eliminated a whopping 67 errors. And its almost midnight. Not the fast start I was looking for; will have to ask some questions at my first online hangout tomorrow and get some tips.