Clone this wiki locally
Each UCOSP participant is asked to log all the steps they take as they make progress through the semester. This includes difficulties they faced (getting set up, 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.
Please record entries in reverse chronological order
February 15 - 21, 2016
Worked on and off on issues 656, 690, and 663. I opened discussion about 663, and explored some possible solutions. Oh, and don't forget more debugging :)
February 18, 2016
Discussed issue 656, 663 and 690 with Vahdat today. As previously stated, the solution regarding 663 is not readily apparent and will require some discussion. I began a discussion on the issue page to hopefully get some interesting feedback regarding some avenues that could be explored. I compiled my thoughts on the best way to tackle this issue, and am hoping to have some feedback before moving forward. The following is more or less paraphrased from the issue page itself, but it outlines my thought process for the best solution:
So assuming that we do in fact want to combine the code (and probably issue a warning as well), we'll need to consider a few cases. As Vahdat said, the order of the combined code will matter. I think it makes the most sense to insert the Umple generated code after the user code, as inserting it at the beginning could cause unwanted modification of functionality to the user code. For example, if the user code depends on the state, we don't want the Umple state machine code to modify the state before executing user code.
The simplest, but naive solution would be to simply insert the generated code at the end of the user defined function and before the return statement. Of course, this will require consideration of functions with multiple return statements. For example, if the function contains a conditional block with a return statement in each, should the state machine code be inserted before each return? While this is the only way to ensure that the correct transitions are triggered before returning from the function, it could possibly result in an abundance of duplicated code, which is a poor code smell. A possible solution to this case would be to pull the generated code into a separate function, and call this function before each return statement. This could result in cleaner code.
Another case that we should take into account is what will happen if the user intends to handle the transition manually. If the user needs to do something fancy for a particular transition and doesn't want the Umple code to be generated, we may want to have some mechanism to signal this. In particular, perhaps the user creates a function with the same name on purpose with the intention of overriding the Umple generated code. In this case, we should not generate code for that transition at all. A mechanism for this could be investigated further if we want.
These solutions still depend on the user knowing what they're doing, and cannot guarantee against unforeseen behaviour in the function. As such, I think a warning should still be issued when dealing with this case.
Assuming that this solution will meet our requirements, it should involve no more than some modification of the model before code generation. It will also require checking for duplicate method/transition names during the parsing phase, which is similar to issue 656. As such, I am working on the two of them simultaneously.
February 13, 2016
Today I got in touch with Aliaa in regards to the code generation errors. I sent her an email and a Git patch to reproduce where I am with my solution. As of this point, I am convinced that the code generation is the culprit, but the code is quite complex and I would value her help before moving forward.
February 9, 2016
Today, I had a very productive, albeit tedious, day debugging through the Umple code. Using the Eclipse environment, I was able to track the changes made to the Umple model in regards to issue 656. The issue remains that the correct methods are not being generated from the Umple model. After making some changes to the files UmpleInternalParser_CodeStateMachine and Umple_Code, I was able to ensure that for each state machine, the correct transitions were being stored in the model. Because of this fact, I am now convinced that the error may lie with the code generation. This led to some very long hours going through the Jet code trying to figure out why some transitions were being ignored. Unfortunately, the JET code is quite long and complicated, and little progress was made here. Vahdat was able to put me in touch with a colleague with knowledge of both the code generation aspects of Umple as well as the state machine implementations, who might be able to shed some light on why this is still a problem. Since the Umple model appears to be correct before entering the code generation steps, I can only conclude that it does not parse the model correctly. The only other alternative is that the model is not correct, and some crucial part was missed. In either case, I will work with Vahdat's colleague this week to try and get this sorted out. I also intent to contact Vahdat so that I can begin work on my term project. There are a few ways to approach this problem, and I would value his opinion on the best way to go about it.
February 6, 2016
Today I spent considerable time attempting to enable the Eclipse development environemnt, which was successful in the end. Initially, when I tried to follow the eclipse instructions on the wiki, the projects would never compile and I could never develop using Eclipse. After spending some more time working on this with no progress being made, I decided to restart the process from the beginning. I theorized that perhaps the version of Eclipse could be the issue, or a crucial step was missed the first time though. Using Eclipse Mars, and after some trial and error to get the build working and the tests passing, I finally was able to get the development environment set up and working using Eclipse. I am still facing some strange issues, such as the following:
- making any minor small changes in an Umple file will cause completely incorrect Java comilings. In some cases, variable names are combined in seemingly random ways, and causes the build to fail. In order to work around this, I have to try a number of command line builds and Eclipse builds after any change. This is tedious but in the spirit of moving forward, it will do for now.
- the test case 'executeSimpleAntScript' still fails however, this doesn't seem to be a major issue and I will look into fixing it later. Now that I have the Eclipse environment setup, I should be able to much more efficiently close issues.
Jan 31, 2016
After hours of debugging and some consultations with Vahdat, I have discovered that the issue lies not with the model generation layer, but with the code generation. I spent the last week going through the code line by line trying to figure out why methods with the same name but different parameters were not being generated. I modified much of the code comparing transitions to consider function parameters as well, however the correct code was STILL not being generated. After much debugging, I can conclude that the events (created from the transitions) are in fact not being pruned from the model, thus the issue must lie in the code generation. If the model contains the correct methods, but the code is not being generated nonetheless, then I will have to work with Jet and the code generation layer to figure out why. Before I start on this, I intend to get Eclipse working, as it is much too tedious to debug through the code without a proper debugger. Today, I plan to work through the issues I had with Eclipse not being able to compile the projects, and get it configured so that I can work through the code generator errors. I may consult with Morgan Redshaw, as he has some prior experience working with Jet already.
Jan 30, 2016
Work continues on issues 656, 663, and 690. I lost a day and a half this weekend due to a Hackathon, thus I only had a few hours to spare today. I spent my time working on issue 656 in particular. I cannot figure out why the extra transitions are not being considered when they clearly should be. After running through multiple different test cases, I can see that the proper events are being created from the transitions, so these events must be getting removed from the model further down the line. I will explore this tomorrow.
Jan 28, 2016
Today, I had a meeting with Vahdat to discuss the issues I will take on going forward in the semester. We discussed a number of possible issues and the benefits of each. We decided that I would have until the end of the week to decide among several possible options. We also discussed some of the current roadblocks that I was facing with issues 656, 663, and 690. I sent him a patch of the work I had done thus far so he could review my work. After review, Vahdat made a few suggestions, which I will tackle either tonight or tomorrow.
Jan 24, 2016
This will be an admittedly uneventful log entry, as I was unable to accomplish as much as I would've hoped. After last weekend's code sprint, I spent much of the week recovering from the flu and playing catch up in my other classes. I was however able to spare a few hours during the week to try and close issue 656, however this has proven to be trickier than I expected. I have been encountering several roadblocks, most of which can be attributed to not having a thorough enough understanding of the cruise.umple project. In particular, the location where the warning is generated and where the additional method is being pruned from the token list are not in similar locations, and as such I am having trouble tracking down the location of the latter. I am confident however, that by consulting with Vahdat about my concerns in the next day or two, I can finally close this issue and move on to bigger fish. I will make a point of discussing this issue with Vahdat over Skype or email early this week.
Jan 17, 2016
Code Spring Day 3
The last day of the code sprint was spent trying to wrap things up and close the final issue I was working on. I was able to make progress on issue #656, however after consulting with Vahdat, it was discovered that there were extra cases that were not originally accounted for. In particular, although the original warning message has been suppressed, it the compiler still will not generate the desired Umple code. This will take some more digging to track down why this is not happening. As it was a short day, I did not have time to close this issue, and will likely be addresses later this week.
Jan 16, 2016
Code Spring Day 2
Today, I finished testing the patch from the day before, committed my changes and submitted a pull request. This pull request was accepted and my changes were merged into the master branch later in the day. After this, I self assigned myself issue #656 and began tracking down the location of the issue. As before, it took a little bit of time to locate the source of the issue and to propose a solution. There was a bit of confusion as to the expected functionality of the compiler after the patch, which was cleared up by Vahdat. Since Umple explicitly states in its documentation that a state machine cannot have 2 events with the same name, I needed to be clear that what I was doing was within the scope of the issue. As such, I would suggest changing this issue from a bug-fix to an enhancement.
Initially, the issue seems to arise from the fact that any two events are considered to be duplicate if they share the same name. My patch takes into account the entire parameter list when making the comparison and ignores functions with different arguments. I wasn't able to commit and create a pull request as I havn't yet accounted for all edge cases and tested the patch thoroughly enough, I expect I will do this tomorrow morning.
Jan 15, 2016
Code Spring Day 1
Today, myself and the rest of the team consulted with Vahdat and had a general discussion concerning the Umple project.
I assigned issue #516 to myself and began work on it this morning. It took me a little while to track down where exactly the issue was being generated and a little while to figure out a stable fix. Vahdat provided assistance by providing a high-level overview of the functionality of the cruise.umple project. The fix itself was quite trivial, the majority of the time spent on the issue was tracking down the location and ensuring that the patch did not interfere with other functionality. This patch was checked in early the next morning as I wasn't quite done testing the patch. At first, I was naively trying to test the private method that I had altered and I got hung up trying to use Java reflection as a means to do this. Eventually, I realized that it would be more useful to test the entire patch as a whole by writing same Umple files and ensure that the parser behaved as expected.
The day was extremely useful in general as I feel like I have a much better understanding of the cruise.umple project and how it functions. This is going to make it far easier and more efficient to commit patches and bug fixes to non-trivial issues in the future.
Jan 11, 2016
I managed to fix the issue regarding the Umple online development environment outlined in my Jan. 11 post, which failed to generate Umple code successfully. I noticed that Shikib ran into the same issue and followed his same steps: "Running ant -DshouldPackageUmpleOnline=true -Dmyenv=local -f build.umple.xml packageUmpleonline, which gives UmpleOnline access to the Umple jar files, fixed this issue and I'm able to use my locally hosted UmpleOnline with all of its features." Big ups to Shikib for noting this fix in his log. I also confirmed that I am able to use the command line tools to generate native Java code from Umple code. Using an example supplied on the web application, I was able to generate the expected .java files without error. Except for the outstanding issue with the Eclipse environment, this concludes the setup of my development environment. Next, I intend to find an outstanding issue with which to begin working on before the upcoming code sprint on January 15.
Jan 10, 2016
I made a fork of the master repository and began to set up my development environment on my machine. I'm running Mac OS, which made the setup quite easy. I was able to get the code to build successfully, and pass all test cases. The only major hiccups that I ran into was when trying to the Eclipse environment setup. For unknown reasons, I was unable to remove all of the errors from all projects, which in turn did not allow me to compile the code. Due to time constraints, I was not able to narrow down the problem just yet, I will revisit this in the future if needed. I wasn't planning on using Eclipse anyways, so this may be unnecessary anyways. I also tested and ran a local version of the web app on my browser, which appeared to function as expected. All of the UI tools function as expected, however there appears to be a problem with the code generation, which I am currently working to fix. In the meantime, I intend to familiarize myself with the code base in depth, as well as begin on an outstanding issue after I fix the aforementioned issues.
Jan 8, 2016
I began by experimenting with the Umple web app in order to get familiarized with the application. I played around with several of the supplied examples and created some of my own. I used the UML modeller interface as well as wrote Umple code in the textual input window. Next, I read the repository Wiki page and read through the Umple user manual. I covered what I considered to be the most pertinent categories, however the documentation is extensive and I intend to continue reading it throughout the week.