Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
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
Over the last few days, I spent close to a total of 25 hours trying to perfect the automated testing of autogenerated methods. I brought it upon myself a bit, as I basically completely reworked my initial implementation, but I think it is in a much better state. I wanted to make sure I left this project for the next person as something I could be proud of.
April 7-8: I found doing a build on Friday morning that extra methods were being added to the Violet and Umlet generators, and causing compilation errors that resulted in a failed build. I spent a (in the end unnecessarily large) amount of time trying to debug where the problem was coming from. Because I had changed about 140 files, I had to do some process of elimination and stash some of the files, then run the build to see if it failed. I managed to narrow down the file, and then had to narrow down which change was causing the issue. I found it; I had commented out one line completely unrelated to the build issues while trying to test something. I am still confused as to why this caused the compilation errors that it did, but alas that is the mystery of Umple.
April 8-10: I then perfected the automated testing of autogenerated association methods. I ran into a bunch of issues, including a "code too large" compilation error that required a few iterations of changes. Because I was editing over 100 files in the UmpleTL, there was only so much time that mass find and replace could save. It is finally an implementation that I think will be very effective and useful though, so I am happy with the final product.
I went back and looked at my original job, which was adding the API methods for associations to the model. I used the generator as a guide to determine the order/logic in which methods should be added, multiplicity checked, etc for querying link methods. There is still a lot of work to be done, but whoever takes on the project next should find that everything is set up for them to be successful; a lot of the initial research/set up that was time consuming to do is complete.
While building, I found that something I had done had messed up the VioletGenerator, so I am currently trying to figure out what I did. Then, to finish up the term, I will write up documentation for the next student who continues this project so that they have solid information to start with, and can understand what I have done so far.
I realized I had missed a bunch of the association UmpleTL files because they are used in JavaSpecGenerator, not JavaClassGenerator. I added the debug statements to these files as well. Debug statements for generated association methods are completed.
I then created a test file which has all of the Java generator association tests. These are all set to debug mode, and the idea is that whoever works on this project can run and compare the output from the generator to the methods in the model, as their signatures will be output to the console.
Next, I will use this verbose testing environment to continue with adding association methods at the model level; I'm not sure how far I will get, but I will try to complete as much as I am able. I will not be able to finish it before the end of term, as it is a huge amount of work. However, whoever takes on this project next should have an easier time as really everything is set up for them to go forward, and I will write documentation on what I have done and how to proceed.
I went forward with putting in debug statements into the UmpleTL files for the Java Generator. If in debugMode, whenever the generator creates an association API method the signature is output to the console. Similarly, the method signatures I have added at the model level are also output to the console so comparison can take place. While this was not necessarily a difficult task, it was time consuming. Next, I am creating a test file which will contain all the tests already used to validate association generated code in the generator, except they will be run in debug mode so these debug statements can be used to verify the implementation at the model level.
After reading Tim's comments on my issue, I started investigating how I should proceed with adding in these debug statements to verify the model's autogenerated methods for associations. I used Eclipse's debugger to step through a simple association code generation test, and found the code where association methods are generated. I then found the corresponding UmpleTL file, and am currently experimenting with how I am going to verify. The UmpleModel currently has a debugMode flag that I think I can use. I can add a variable to TemplateTest called debug, and set this to true if I want to go into "debugMode", and then correspondingly set this in the model. Then, I will have to put logic in the UmpleTL files to verify methods in the model are being generated, and that the model has no extraneous methods. This is what I am going to be working on over the next few days.
I spent time looking into how to identify reflexive and symmetric reflexive associations. In other parts of the code, I saw that checks for reflexive associations were done by checking the equality of the two association ends' class names. Then, to identify if it is symmetric reflexive, I can use the modifier variable on the association - if it is symmetric reflexive it will be "symmetricreflexive".
After our meeting on Friday, and looking at the generated code tests for generating association API methods, I realized there were a lot of cases I wasn't thinking about. Therefore, I started creating tests for the model level autogenerated methods based on these existing tests for the generators. This will take some time, as there are a lot of combinations of multiplicity and such, but this will be most effective in me being able to ensure my logic and autogenerated methods that I add are correct and complete. Once these tests are completed, I will continue with implementation.
I continued researching into my next task. I have realized that I will have to approach associations in a somewhat different way from attributes. For attributes, I was able to add the API methods once analyzeAttribute() had been called, and the attribute created. I can't do this for associations, as sometimes the class that is part of the association has not yet been parsed and created at the model level itself. Therefore, I will add the methods from postTokenClassAnalysis(), much like the "unlinkedAssociationVariables" are.
Today (March 22) I made great progress. I started by adding a very simple test, so that I can debug and see results as I go. It consists of one association in the form 0..1 -- *. Today, I completed the addition of all querying link API methods for associations of all types except array attributes, and reflexive and symmetric reflexive associations. I need to look further into how to identify these types of associations.
I completed the last thing for my pull request to be complete. Vahdat had pointed out to me that I need to handle the case where attributes are removed, and remove them from the autogenerated constructor as well. I completed and tested this. I then moved on to the exploratory/research part of my next step, which is adding the API methods for associations to the model. I spent time looking through the Association class, and its associated class, to become familiar with the information I will have available at model creation time.
I added methods to remove both all autogenerated methods, as well as only those associated with a given attribute. I also created tests to test these methods correctness. Currently, these methods are not called anywhere in the code, but they may in the future become useful. I also continued working on the autogenerated constructor. I had worked on this in the previous week, and so most of my time was spent debugging and cleaning up my previous changes. I wrote test cases, and found that I had to rethink a lot of the logic I had used, as I was not handling all cases properly. One such case was that if an attribute is initialized, it is not passed as a parameter to the constructor. As well, one of the checks I had before adding an attribute to a constructor was if its modifier was settable. If it was, then the attribute should be added. However, through my tests I found that auto unique and lazy attributes have the modifier settable, and so handled these cases as well.
During the past couple days, I have been working on generating a constructor, and adding attributes to the constructor as they are encountered. This has been more time consuming than I thought it would be, as my changes often break builds and I have to go back, figure out why, and how to fix it. I am realizing how finicky it can be working at the model level, as even a small change can cascade throughout other compiler classes and cause things to fail that you would have never expected. I have been able to work through my build issues, but I will come back on Thursday with a fresh mind to ensure I am doing the correct things, and not putting in hacks in order to have successful builds.
Today, I started adding the methods to remove autogenerated methods from the model. I ran into an issue where I can't use the Glossary of StringFormatter in the model, as it fails during building. I will investigate this further, but I would guess it has something to do with the order of compilation.
Week of Feb 27-Mar 3
During multiple different this times this week, I was fixing up my pull request as per Vahdat's comments. It is now ready to be merged!
Today was an extremely productive day devoted entirely to Umple. I went through the last failing test cases I had after fixing the Ruby generator, fixed more generators that I had missed, created a new test for the added feature of get/set methods at the model level, and cleaned up/did minor fixes for the code I had written to add these methods. I created a pull request for my work so far. Next, I will add the functionality to remove these API methods from the model and add constructors and constructor parameters upon reaching an attribute.
I looked more into the issue of new lines with Ruby generated code. Because of the added methods, we were hitting a new if case (the class being analyzed now has methods because of the get and set API methods). I added logic in the Ruby generator to avoid going into this if case to add methods if there exists no method whose source is not fAutoAPI (i.e. not an API auto-generated method).
I spent time adding changes to add a set method for attributes at the model level. I also updated the other language generators to skip fAutoAPI methods. I then ran the test suite, and spent a lot of time debugging failing Ruby tests. It seems additional empty lines are being inserted into the generated code, and I haven't been able to figure out why yet.
I am happy with the progress I made. I debugged an issue I had where my changes caused a Null Pointer Exception in the build process - this was fixed by setting positions (i.e. Position class) for the get method I was adding. After I fixed this, I then ran the build again. It was unsuccessful again, because duplicate methods were being added. This made sense, as I add get methods for attributes at the model level, so then in compilation/code generation two get methods get generated. To solve this, I added another type to the Method.Source enum I am calling fAutoAPI. At the Java code generation level, I then check a method's source before generating code for it - if it is fAutoAPI, it is skipped. I will have to look into the other generators to ensure the same issue is not repeated. I am also anticipating that I may have to work on some of the tests as there are additional methods being added to the model now.
I had many midterms/projects/assignments due for my other courses this week, and so was unable to make progress with Umple. However, I am on reading break next week and will have no trouble more than making up the time.
I continued working on generating the correct names for get/set methods. My research into Umple brought me to the StringFormatter class which I am now using. I am running into a NullPointerException when I build and try to test my changes; I am currently debugging this, and have a workaround in terms of building for now so that I can build successfully and test some of my changes.
I spent a lot of time over these two days looking into my term project, which is to add API, Umple generated methods to the metamodel representation. As I am starting with attributes, I first read through the Umple user manual Attribute section again, and made notes on the different Umple modifiers that may be used, as these will define what methods need to be generated. I also looked through some of the compiler code, trying to find where I need to start making changes. I found the method analyzeAttribute in UmpleInternalParser_CodeClass.ump. This is where tokens identified as attributes in parsing are added to the meta model. It is here that I can identify attributes that need API methods, and I am creating a helper method that analyzeAttribute will make a call to in order to add the correct methods to the meta model. I was also looking at the UmpleToJava generator classes because this is where these methods are currently created, and it will help me to use the process in the generator level as a guide for additions at the compiler level. Through this, I found the Glossary class, which has methods (e.g. getSingular) that I can use to generate the proper names for the getX and setX methods. Not too much progress in terms of actual code has been made, as I am still in the learning process for this project and a lot of my time is spent navigating unfamiliar code, and dealing with build issues. However, I have spent a lot of time understanding the code base, and can feel things becoming more familiar and easier with each hour I spend. Over the next week, I hope to be able to make significant progress.
Fixed one more issue and closed issue 961
I finished up the second bug fix for the PR for issue 961. I am going to run a full build at UBC tomorrow, and then submit my changes. My plan for my term project:
- I will be starting with moving getX and setX API methods for simple attributes.
- I need to familiarize myself with the code in the meta model that builds these components.
- Whenever an attribute is encountered, the meta model needs to have the API methods added for this attribute as well
- I also need to look into what warnings/errors/hacks can be removed/modified as this information becomes available in the meta model
I started looking into the comments Vahdat made on my PR for issue 961. I fixed the issue where the error printed twice when there was a reflexive association in the superclass and the subclass had an association with this name as well. I have a really busy week this week, so I am hoping to finish the other bug tomorrow night, but if not will fix it Friday night. I will also be devoting a lot of time this weekend to starting on my term project.
Today, I had a google hangout with Vahdat to talk more about my term project. He showed me some of the situations I will be handling, and took me some of the code that will be impacted. I will be starting with adding the API methods for attributes first.
Today, I finished up with issue 961. I cleaned up my code to make it both more readable and more logical, and submitted a pull request.
I looked at past commits and emailed Vahdat to understand what I needed to do to add a new error message. I worked on creating the necessary files, and wording the error message for issue 961. I also encountered another case I had not thought of previously for issue 961. I was not handling cases where the superclass had a reflexive association, which I came across while creating another test. I spent some time debugging to find the root of the problem, and fixed my code. I am almost finished issue 961, but want to clean up my code a little first before issuing a PR.
Today I was working on the UBC campus, and did a full build - IT WAS FAST! Only took about 4.5 minutes. Until I can find a solution, I will definitely build at UBC instead of at home. Today I am working on adding more complex test cases for issue 961, and cleaning up/commenting the code. I hope to have it done and in a PR by Friday.
I created and got a test going for issue 961. It passed, and so did all the other JUnit tests I ran in Eclipse, so I decided to try a full build. A bunch of association specialization tests failed, and I realized I was not accounting for these cases in my implementation. A specialized association would have the same role name and possibly be to a different class, but is not an error. I am fixing the code using the isSpecialization boolean that is part of the Association class, and will build again tomorrow.
Jan 20-22: Code Sprint in Calgary
- worked on issue 26, fixing generation of abstract classes in PHP. Although it was an easy bug, I feel I have a much better understanding of the architecture of Umple, as well as testing procedure. Submitted a PR at the end of the day for the fix.
- I am having trouble running a full build. It takes almost 40 minutes, and after following Tim's suggestions in regards to disconnecting from the network I am seeing no improvement.
- started on issue 961, which Vahdat and I came across while looking into another issue.
- I spent a good amount of time looking at the Umple.ump to understand what I have to work with in terms of the meta model, and UmpleInternalParser_CodeClass to find where to make my change
- I found a method in UmpleInternalParser_CodeClass called checkDuplicateAssociationNames(). It is very similar to what I need to do, and I am using it as a guide.
- After coming up with an implementation, I found that some tests were failing, and used the Eclipse debugger to find out why, and make the necessary changes to my implementation
- Continued with debugging. All tests pass, now working on writing my own tests for this bug fix. I used closed issue 84 to find where my test should go, as it expects an error in generation.
- I ran into a problem where I would make changes, and then build, but my changes were not being picked up. Running the first-build again before building solved this issue.
I got sick over the weekend, and so I have not been able to make much more progress since last week. I am feeling somewhat better today, so my goals for today and tomorrow are to set up a local version of Umple Online, and to find an easy issue to start looking into before the code sprint, so that I can become more familiar with the Umple codebase.
Looking at the suggested first issues, this interests me in that it seems very straightforward, but would definitely allow me to look deeper into code generation: https://github.com/umple/umple/issues/26
I installed the Eclipse plugin for Umple, and used UmpleOnline to explore more Umple examples.
Followed the instructions at https://github.com/umple/umple/wiki/DevelopmentSetUp Completed all the steps, except for setting up a local version of UmpleOnline. I will set this up later this week. I was able to successfully build and then set up the projects and run tests in Eclipse. All the tests are passing, although 154 have been skipped - I am unsure of whether this is supposed to happen or not. Also to note, I am working on a Mac, running MacOS Sierra 10.12.2.
Reading through the Umple user manual, tested out UmpleOnline, and read through the wiki pages listed for UCOSP students at https://github.com/umple/umple/wiki/UCOSP