UCOSPLogAdamDzialoszynski

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

Each UCOSP participant is asked to log all the difficulties they have getting set up to understand Umple. This includes understanding how to model in Umple, using UmpleOnline, code that is difficult to figure out, and development tools that are hard to figure out, or don't seem to work properly. The more log entries added the more we can better get a grip on the usability issues with Umple, and the more we can help future new contributors come up to speed.

Log entries

Entry 1:

Started looking at the online version as described here: https://code.google.com/p/umple/wiki/UmpleHome

Ran into my first issue quite quickly. Seems that when I try to make a variable private in the UML frame, it causes the web application to fail until the page is refreshed. Ex: Make new class: Speaker. Make new variable: volume : int The above causes no errors. However, if you add a '-' to indicate that the variable is private, like so -volume : int then the output code on the right is:

class Speaker
{
  int -volume;
}

Which is incorrect (variables can't start with non-alphanumeric characters) Furthermore. if you change the UML on the right to - volume : int Then the code in the right frame disappears entirely. If you manually press the "Generate Code" button, you receive the message at the bottom of the page:

// An error occurred interpreting your Umple code, please review it and try again.
// If the problem persists, please email the Umple code to
// the umple-help google group: umple-help@googlegroups.com
// or post an issue at http://bugs.umple.org -- the Umple issues page
// We are aware that error messages are not useful or nonexistent and
// we are working to fix that.

The only way to clear the error at this point is to refresh the page. Correcting your syntax does nothing to return the application to a normal state.

Also, if you simply write in the code frame:

class Speaker
{
    private int volume;
}

Then the UML frame shows a class called Speaker, but which contains no variables. Everything works correctly if you remove the "private" from your code.

I'll check later if this occurs on the non-web version as well.

Entry 2:

After playing with UmpleOnline and reading the user manual, I have a much better idea of what Umple is. I have also installed and set up Eclipse according to https://code.google.com/p/umple/wiki/Install_Eclipse_Plugin and https://code.google.com/p/umple/wiki/DevelopmentSetUp

Unfortunately, after following the instructions in the provided YouTube video, it mentions that there should be no errors once complete, however, I had 217 errors. I went back to https://code.google.com/p/umple/wiki/DevelopmentSetUp and tried the steps written there. They are different then the ones in the Youtube video. The DevelopmentSetUp page says, in step 4, to "Import the libraries [junit, hamcrest, ant, ant-launcher, tools]". The video however, shows junit, hamcrest, and umple being imported, nothing else.

After undoing what I did and importing the libraries listed on the webpage, my number of errors went down to 211.

I looked closer and noticed that, also in step 4, the webpage states that "The most important once you will need are are cruise.umple.xtext, cruise.umple.xtext.ui and lib." when referring to projects to import. The video omits cruise.umple.xtext.

After importing that project as well, my total number of errors went down to 7. All remaining errors were "cruise.umple.parser cannot be resolved to a type" or "UmpleParser cannot be resolved to a type".

Figuring that something was still missing, I noticed that, again, in step 4, the step "Go to the properties of the project cruise.umple -> Java Build Path -> Projects Tab and add the project cruise.umple.xtext." was omitted entirely in the video.

After completing that step, I ended up with 0 errors and could continue.

That said, step 5 results in 344 errors and 802 failures.

Entry 3:

I'm not sure what happened. I loaded up Eclipse today to browse through some code but Eclipse is telling me that there are 2597 errors now... I fiddled with it for a little while but couldn't solve it so I deleted the project and started over, repeating the steps I did yesterday. However, I still have ~2600 errors... It looks like every .ump file in the project directory is throwing errors. Lots of unresolved class definitions.

I'm assuming that this has something to do with ant, since I downloaded and ran that earlier today. However, when I tried restoring my working copy of the repository, my SVN application returned 0 updates. So... I guess ant didn't change anything...

I'm going to ignore these issues for now and try to get this set up on my laptop, since that's what I'll be bringing to the code sprint in a week. Maybe I'll have better luck with that.

Entry 3.5:

I set up my laptop with no issues. Though I almost missed a step that was covered in the video but not on the DevelopmentSetUp page (converting the project to a plug-in project). After completing this, I compared the setup to what I had on my desktop and noticed that one of the libraries was missing (antlr-generator). After re-adding it, all errors vanished. Now I can get back to playing around with Umple.

Entry 4:

Code sprint has begun. I currently plan on making a example system/program for testing/showing off UMPLE. However, before I do that I have decided to make a bunch of bat files that will accomplish common tasks for me with ease. Right now I am attempting to make a bat file that compiles my UMPLE code, then compiles the resulting Java and run it. Of course, I need to put in some checks to make sure it stops if errors occur. I'm making decent progress on this, but unfortunately, it will only work on Windows machines.

Entry 4.5:

Task complete. Beginning to work on my example program now.

Entry 5:

While working on my example, I came up with an idea. I wondered what would happen if I made an association with multiplicity on a class which is a singleton. This logical flaw is a programmer error, but I was curious to see what UMPLE would do when given this code. The testing of this lead to the following issue getting created.

https://code.google.com/p/umple/issues/detail?id=254

Entry 5.01:

Again, while working on my example, I ran into the following situation. I wanted to model a class (A) which owns a certain number of another class (B) that could be modified during the program's execution. I had a A 1 -- B association already and was about to create an integer attribute in A which would be the number of B's it has when I thought about using the association itself to accomplish this. A 1 -- n B relationship where 'n' is a variable that can change during runtime. I made a quick test example in UMPLE Online to test this. The result of which is the following issue:

https://code.google.com/p/umple/issues/detail?id=255

Looks like I'll be going back to my 1 -- association with the attribute.

Entry 6:

Things are going well with my example. I am running into what I assume is a predictable issue when trying to make a model of a complex system like the one I am building. My model is starting to show some significant overlap with existing Java libraries. In other words, I'm making my own classes for things that I know should exist in the model, even though I know those classes already exist in standard Java libraries. For example, one of my objects is associated with an object that represents a frame within a window on your system. In normal programming I would just import the required Java library but in UMPLE's model oriented programming style, I need to show the association to the class, which means I need the represent the class, which means I need to extend the existing Java class. However, this doesn't really solve the issue since I should still have a "isA" relationship from my class to the original standard Java class... Clearly there is something wrong with my thinking here. I need to figure this out.

Entry 7:

Well, I eventually decided to drop my example. I assume the difficulty/annoyances I was running into were my own fault, but I can't help but feel like Umple kept getting in the way of my progress. For example, I was getting frustrated when I wanted to include private helper variables but would then need to include them all in the constructor. This quickly caused my constructors to become extremely complex. Also, a related issue was having to predict Umple's method generation and enter so many before/after statements for each one, in order to slowly bend the generated code into doing what I wanted it to do. Frustration and lack of progress eventually meant that I decided I should move on to SQL generation, a much more worthwhile contribution to Umple then my example.

It didn't take long to see the beginnings of how the Umple was converted into SQL by looking at the jet files. I got hung up on trying to get Umple to build properly. Had to remove my 64bit copies of Java and, by extension, Eclipse, and replace them with 32bit versions in order to get Umple to build. It wasn't the end of the problems though. I noticed that the tests were all failing and really wanted to get to the bottom of it. After a bunch of back and fourth between Andrew, Tim, and myself, Tim eventually suggested wiping my entire repository and downloading a fresh copy. This had a unforeseen consequence. Now, instead of the Umple build tests all failing, I get one failure, a Build test failure, which presumably prevents the other tests from running. I found this wiki article https://code.google.com/p/umple/wiki/BuilderTestFailingOnWindows which seems to address the issue. After playing around with the suggestions there and adding some println statements into the .ump code and building, I found that what was listed in that page wasn't the problem.

My investigation currently dead-ends at the BuilderTests.java file, located in Trunk\umple\cruise.umple\test\cruise\umple\builder. This file seems to be written by hand and is not a UmpleToJava generated file. There are a few AssertionFailedError errors and ClassNotFoundException errors, found when I looked in the TESTS-TestSuites.xml file after building Umple.

Luckily, I just finished my second round of exams in my other courses and have reading week approaching. I should have plenty of time to get to work improving our SQL generation. That said, I desperately need to get this working so that I can make some significant progress by this coming Tuesday. On that note, I still haven't figured out how to get Eclipse to actually convert the Jet files into the Java files I know they should turn into in order to actually build with my changes and begin the iterative process of improving the project.

Haven't written a log entry in a while, so had a lot to write.

Entry 8:

Firstly, I made a few changes to the DevelopmentSetUp wiki page so that it more accurately reflects what is actually required in order to get set up to develop Umple.

Secondly, with help from various people, I managed to get my environment into such a state such that I can actually begin developing. I immediately jumped into to fixing the existing SQL generation. The output it gave before was not valid SQL even for very simple Umple code. I have been working on fixing this.

Completed changes:

  • Fixed handling of attribute types.
    • Previously, Umple primitive types were being incorrectly converted to SQL and non-Umple types were being converted to BLOBs. Now, Umple primitives are correctly converted to SQL and other types are passed through.
  • Fixed handling of packages.
    • Previously, packages/namespaces were converted into "modules" which is not valid SQL. Now, they are converted into working CREATE DATABASE statements and subsequent CREATE TABLE statements correctly place themselves in the created database schema.
  • Fixed handling of comments (more testing needed)
    • Previously, comments were either ignored or converted incorrectly. I fixed the conversion but comments within classes are still being ignored. I assume that's bad but the current Java generation has the same behavior so I'm not sure.
  • Added handling of the Umple keywords "autounique", "defaulted", and "const", and added support for initialized attributes. "lazy" and "settable" are ignored since they're behavior works by default. "immutable" is not enforceable in SQL so I have no plans to add it.
  • Fixed the existing handling of the "key" keyword and added detection and handling of cases where the user omitted a key from a class.
    • SQL tables must have unique Primary keys. If the user does not specify one in Umple, then Umple generates one and outputs a warning comment. I'd like to change this to a compile warning, but don't know how...
  • Added support for associations (incomplete).
    • Previously, the existence of an association in the Umple code would cause glaring errors in the generated SQL. With my changes, 1 -- 1, 1 -- N, N -- N, 1 -- *, and N -- * associations are correctly handled.

Things to add (in no particular order):

  • Would be good to convert non-SQL types to BLOB. Complete list of valid SQL types would be required.
  • Address issue 87 (on Google Code) and add support in the SQL generation for the "unique" keyword (should convert into the SQL keyword "UNIQUE").
  • Address issue 187 (on Google Code) and add support in the SQL generation for constraints (should convert into the SQL keyword "CHECK").
  • Add support for "NOT NULL" by adding a new keyword to Umple.
  • Throw a warning when a class has no key.
  • N..M associations are unenforceable in SQL. Throw a warning when they are detected.
  • Add support for * -- * associations. Involves generation of an association class.
  • Treat N..M -- X..Y associations as * -- *
  • Throw warning when 1 -- * or 1 -- N..M associations are being treated as unidirectional (since there is no other way).
  • Create a testbedSQL which executes meaningful tests. A foreseeable problem may be the non-allowance of DROP DATABASE or DROP TABLE statements. Could cause buildup of test databases on the developer's SQL server that prevents further tests from being executed.

That list is probably missing some things... Anyways I'll keep working on this later. At some point I'll call it quits and make a patch file so Tim has something to look at on Tuesday. Time for sleep.

Entry 9:

Creating all the tests for SQL was the next most important thing to do. I jumped straight into writing all the test case files but realized that, since I was writing them by hand, and because there are so many, I might slip up and introduce inconsistencies into the "correct" output of the tests. After realizing that, I started work on a specification document so that I could refer to it every time I was writing a test case. While writing this I came to the realization that I forgot to add foreign key constraints to the changes I submitted over a week ago... test first!

Another part of the reason I spent so much time writing this specification document is because I wanted to write down every "issue" I could come up with regarding how to implement certain items of the SQL generation. Not everything in a programming language makes sense in database design, so I mostly wrote about things of that nature and possible ways to implement something that makes sense. Hopefully these sorts of cases can be discussed and resolved by the end of the hangout today.

Entry 10:

Created the SqlGenerationSpecification wiki page. It took me a while to figure out those SQL triggers but I managed. Hopefully the wiki page will allow some good back and forth to occur regarding certain questionable issues. In the mean time, I can get back to work on the test cases and SQL generation itself on the more straight forward and agreed upon components of UmpleToSql.

Entry 11:

Couple things to report. Firstly, while creating the SQL test cases I noticed that the toUnderscore method in the StringFormatter class was acting strangely. Though it was a simple and effective method, its algorithm would turn strings like "HELLO" into "h_e_l_l_o". It also converted strings with numbers in them badly ("var123" => "var_1_2_3"). I decided to fix this so that it would separate the string into tokens. Groups of lower case characters would be grouped into a single token. Same for uppercase characters and numbers. The only special case was that a lower case token could begin with an upper case letter iff it wasn't the first token in the string. That sounds complicated, but it's not. I made the changes, tested it using my own tests and also made sure it built properly (didn't break anything else by mistake). Everything seemed good so I committed it. Others caught on that something was wrong though and I ended up having to make an additional fix to the Ruby testbed files, whose file names were being changed thanks to the new toUnderscore method. I had thought that those testbed tests were run when Umple was built, but I because of this, I learned that that is not the case.

Secondly, I came to the realization that, due to the limitations of SQL, the UmpleToSql code generation would be made vastly simpler if I could made changes to the Meta-model before the code generation takes place. Andrew confirmed that this is possible by modifying the prepare() method in the code generator class. However, he informed me that I would have to revert whatever changes I made using the postpare() method after the code generation was completed. After about 6 hours of work, I came to a conclusion. It seems as though I have two options.

  1. Don't use the prepare/postpare functions at all and implement everything I need without modifying the meta-model.
    • While this is somewhat easier to code vs modifying the meta-model, it would cause much worse run-time efficiency since many things need to be recalculated over and over.
  2. Use the prepare/postpare functions do make drastic changes to the meta-model.
    • This would make the run time calculation much more efficient. However, it also makes the code generation considerably more difficult. For example, if I add some internal attributes to a class in order to replace something in the meta-model that is problematic, how do I get the code generation to ignore that problematic thing? I would have to put lots of complicated checks for certain conditions in various places, making the code messy.

The thought that maybe I should introduce an "isExternal" flag for attributes, associations, and key members crossed my mind. If the isExternal flag is true, then whatever it is will be ignored by the code generator. This is not an ideal solution though, as it would require the addition of lots and lots of trivial if statements in all of the existing languages' code generation code, despite the existing languages not having a need for it (currently)...

At the moment I'm not sure what to do about this... I think I'll sleep on it and work on less technical parts of the SQL generation for now.

Entry 12:

Added a List of SQL Generation Issues section to my SqlGenerationSpecification page. The list contains the more serious issues I'm trying to face regarding the complexities of generating valid SQL code from Umple. I also added a "Status" section to each of the existing SQL generation topics that gives a brief indication of the current status of those parts of the generation. Note that since I haven't committed any of my SQL changes yet, those statuses are not reflected by the SVN's version. That should change within the next few days as the term winds down... I really wish I was able to get further toward completion.

Entry 13:

I have committed my latest SQL changes. In the process of doing this I realized that one of the patches I sent out to UmpleDev a while ago WAS committed by someone and has been working on UmpleOnline for a while. Kind of a shame since I wanted to do a before/after comparison. Oh well... Tim says that I have until April 10th (technically the 11th, but presumably Tim needs some time to come up with a mark) to continue working on things. As much as I would love to pour my weekend into changing the getCode() or writeFile() methods, I have a final exam in another course on the 13th that I REALLY need to study for... Passing that exam is much more important then getting a few more marks from Tim so, unfortunately, I'll probably have to call it quits here.

It is SOOO tempting to keep working on this though... In the middle of writing this log entry (literally), I came up with a solution to my latest conundrum: how to solve the #2 issue from the SqlGenerationSpecification wiki page. I wrote it down there. I might try to work on that, if I can find time.

Entry 14:

This will probably be my final entry. I just commited my latest changes to the SQL generation. I feel like I added a significant amount to the SQL generation, but that most of the usefulness of my contribution will probably be found in the SqlGenerationSpecification wiki page. I had to put a lot of time and thought into some of the issues with converting a Umple model into a not-programming language. There is still a long way to go it seems...

I wanted to thank Andrew, Tim, and the UCOSP organizers for the opportunity to work on Umple this term. I value and enjoyed the experience greatly. Lastly, to the other UCOSP students, good job and good luck on your exams!

The following is a copy of the commit log from my last commit:

This commit contains significant changes to the writeFile() method of the SQLGenerator class. The changes allow for the addition of Foreign key constraints. Thanks to these changes, associations of multiplicity 0..1, 1, and N are now supported. I began to add support for associations of other multiplicities but it is incomplete at the present time.

Also added in this commit is MySQL support for const attributes. MySQL does NOT support the CHECK statement, so additional triggers were required. They have been added.

I have also added the first automated tests for the SQL generation. The tests include association tests for the supported types of associations listed above, as well as a test for the attribute types. The attribute type test should probably be rewritten though, since it does not fully test the SQL generator's attribute generation.

Lastly, as part of making the automated tests work, I had to change every use of the term "SQL" to "Sql" within all the source files. This meant renaming some files as well. This will probably be my last commit for the official UCOSP Winter 2012 term. After my final exams though, I may try to get the other association types working.