-
-
Notifications
You must be signed in to change notification settings - Fork 197
UCOSPLogKenanKigunda
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 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.
Finishing up the Dropbox integration, I've committed some updates where the save button resets a couple of seconds after each save, thus allowing the user to continue saving their work. The Dropbox dropins integration should now be complete.
After my previous tests showing that the Dropbox saver works fine on an otherwise empty page, I started looking at the other JavaScript included in umple.php through _load.js, and sure enough the there is a conflict between prototype.js and dropins.js. Luckily, I found that updating from prototype.js version 1.6 to version 1.7 solved the problem, and Tim tested this out on the server, so now we have both the chooser and the saver working.
However, Tim has informed me of one more problem: the saver only works once and then blocks future saves. I'll be added to the success callback of Dropbox saves to work around this issue.
Been a busy week, but I've had a bit more time to test the Dropbox saver. I tried adding the most basic saver link to umple.php, but even this is still giving a generic error. I then tried setting up a very simple Dropbox dropins integration on WAMP in Windows using the same Dropbox dropins app key, to see if the error was with my app key. I created a mostly-blank PHP page with one saver button, and this works perfectly. I then tried the same page in apache2 on Ubuntu, and that also works perfectly, so at this point I am pretty sure that there is some conflict with one of the other JavaScript files included in umple.php.
So Tim pushed the Dropbox integrations to the test server. The chooser works fine, but we are still having problems with the saver. First, the saver was not calculating the links to the files to save properly. I fixed this, but the saver is still reporting some unspecified error. Although the error callback can accept an error message, the error message is empty and thus utterly uninformative. I'll have to do some more research and testing to find the source of this issue.
I have a working implementation of the chooser on my localhost, and I have set up the saver, but I will need to test the saver on an online test server because Dropbox does not allow files to be uploaded directly: instead, the saver takes a link to the online resource which should be uploaded to the Dropbox servers. Will be looking at setting up an online test server and verifying my current Dropbox dropins implementation this week.
I set up a system for receiving authorization for an Apps/UmpleOnline folder in a Dropbox account and I've now extended that to save a simple test file to that folder. However, as I've set things up I've realized that my current plan regard access tokens will not work very well.
The Dropbox SDK allows us to redirect a user to a page where they can authorize UmpleOnline to create, read, and write to Apps/UmpleOnline in their dropbox. This works great, but is intended to be used as a mechanism to link Dropbox to a user account in our app, and at least so far in my testing cannot be used as a general login mechanism. I had expected that, once a user has authorized UmpleOnline the first time, future login requests redirect to the Dropbox login page, allow the user to enter their credentials, and then redirect back to our app. This has been my experience using Google's similar API, but instead with Dropbox I am seeing that repeated calls to Drobox login continue to explain that "UmpleOnline would like to create a folder in your Dropbox", even when that folder has already been authorized, created, and has files in it, which is potentially quite confusing.
It seems, then, that the expectation is that we have our own login system, and that after the first authorization to Dropbox we store the user's Dropbox access token along with the user's other data in our system, and then every time the user logs in to our app we can retrieve the access token and perform operations to Dropbox without reauthorizes. Thus the SDK provides allows us to ask the user to link an account to Dropbox but we must still manage that account on our end.
This setup does not work very well with my proposed solution of using local storage or PHP sessions to store the access token, because while it maintains continuity while the user is logged in, it forces the user to reauthorize, and get a confusing message, every time they log out and log back in. In addition, local storage adds complexity because the token has to be transferred to the client, saved on the client side in JavaScript, and then sent back to the server, and storing the access token in this way is problematic when users are on public computers or in other scenarios where multiple users are on the same computer.
It seems to me that using the Dropbox core API still requires a user system to be set up on our end, unless I am missing something, so at this point I will first implement the simple chooser/saver pattern (https://www.dropbox.com/developers/dropins), and then reconsider my approach to the larger problem.
So I'm taking this long weekend to design a strategy for tackling issue 85 (on Google Code), and after looking at the Umple Online code and the Dropbox API, this is what I have so far:
DROPBOX INTEGRATION PLAN
Using the Dropbox API:
- Need to register app using a Dropbox account and going to App Console.
- Must accept the Dropbox API Terms and Conditions: https://www.dropbox.com/developers/reference/tos
Initial prototype:
- Allow user to sign in with Dropbox.
- Use an App folder permission.
- When user grants Umple access to their Dropbox, the /Apps/Umple folder is automatically created.
- Save user login details (account id -> access token) in session or local storage.
- When user grants Umple access to their Dropbox, the /Apps/Umple folder is automatically created.
- Use an App folder permission.
- Work alongside current model saving system.
- Every time the model folder is changed, save model folder to /Apps/Umple.
- Need to find each function that writes to the model folder and add Dropbox hooks.
- Not sure if possible to upload entire folder with one API call.
- May have to recursively create/open folder and upload/replace files.
- For now, continue using randomly generated integer id.
- Model folder to edit and autosave to dropbox is chosen from request parameter.
- Every time the model folder is changed, save model folder to /Apps/Umple.
e.g. umple.php?dropbox=131111235241 will extend current functionality of umple.php?model=131111235241
Extensions:
-
When user signs in, display all models in /Apps/Umple.
- Read through folders in /Apps/Umple and display buttons which folder names.
- Each folder button links to umple.php?dropbox={foldername}
-
Allow user to name model, rather than using integer id.
-
Save user login details (account id -> access token) more permanently
- User should not have to reauthorize Umple if they log in after session expiry or on a new browser.
Just pushed through a commit that (finally) finishes the Ruby implementation of the unique keyword. I've never written Ruby before so it was a bit odd for me - especially the distinction between class variables and class instance variables - but on the whole it turned out to be quite straightforward. I think I actually like Ruby quite a bit!
So my progress on my Umple work this weekend was stumped by operating system issues. I upgraded to Windows 8.1 on Thursday, and the upgrader ended up rewriting grub2 so that it just boots straight into Windows instead of showing me the bootloader. As far as I can tell though the actual Ubuntu partition is untouched — I can still see the unreadable D: Local Disk in File Explorer — so I tried using EasyBCD to have Windows recognize the other operating system, but that didn't work due to EasyBCD's compatability issues with UEFI. It looks like I'll have to boot from a Linux Live USB and rewrite grub. Sigh.
Getting into midterm season now, so things are really busy, but I've been trying to squeeze in work on Umple here and there. I've started working on the Ruby implementation of the unique keyword, which is a bit trickier for me because I have very little experience with the language, and I've taken a look at the Dropbox API for my next issue. I'm hoping to get a good session of Umple work done this weekend and get back into the swing of things.
So I asked Tim about the runtime behaviour tests and he directed me to the appropriate articles in the Umple testing architecture documentation, and it turns out that I had passed over the testbed folders because I hadn't imported them into my Eclipse project. For some reason Eclipse only allows me to import testbed_php, not testbed (for Java) or testbed_ruby, so I ended up just writing the tests that I needed in gedit. I created two testbed tests, one for Java and one for PHP, which make sure that for an attribute unique id: (1) an exception is thrown when trying to instantiate an object with a duplicate ID; (2) callers can check whether there is an object with a particular ID, and retrieve objects by their unique ID; (3) callers cannot change the ID of an object to an ID that is already taken; and (4) old IDs become available when an object gets a new ID or when it is deleted. At first I got thrown off because the values for objects from old tests were still stored in the unique map and causing constructors in subsequent tests to fail due to duplicates, but I sorted that out by calling the delete method in the tearDown method of each test case, and everything worked perfectly after that.
Tim had made me a committer after my first unique keyword patch, so after patching my changes over to a new trunk, making sure that I had svn added all my new files, running a clean build, and double-checking all the tests, I was ready to make my first commit. I was really nervous about it, though, and I only got more nervous watching the server take first ten, then finally almost twenty minutes to build the new revision. In the end the build passed (phew!), but there was one test,cruise.Batch-With-Multiple-Tests > generatePath, which failed, with a strange error saying "Forked Java VM exited abnormally." I was unsure what to do about this, since I hadn't seen any similar failures on my machine and the failure was too generic to know what was causing it, so I asked about the failed test in my umple-dev post about the new commit. Tim pointed out that they had seen this error come and go in the past, and that while it was something to look into it was of low priority since all other tests, and the build as a whole, passed.
So here we are: my first commit and the unique keyword implemented and thouroughly tested for Java and PHP. I'll be implementing and testing Ruby tomorrow, and by Wednesday the unique keyword should be complete for all three target languages.
So the issue with the Java references in PhpClassGenerator that I mentioned yesterday was sorted out, and I was able to finish my PHP implementation of the unique keyword. I just need to integrate my runtime tests with the testing framework and then I'll be committing my changes.
So I've been meaning to get back on the Umple train since Wednesday, but I received an added push today when Greg and Tim pointed out that there were references to files needed for the unique keyword, which I had so far only created for Java, that are holding back code generation from PHP (and also, presumably, Ruby). This seemed straightforward enough: I needed to copy the files to the UmpleToPHP and UmpleToRuby folders and edit them so that the code generation was appropriate for those languages.
It hasn't been so simple. After creating and editing the needed includes in UmpleToPHP, I was able to successfully update the JET templates, but I'm now having trouble compiling my changes. When I regenerate from attribute_Set_All.jet and attribute_Get_All.jet, I get errors in PhpClassGenerator because there are references to baseJavaLine, isFake, and getAttributeCode, which are not defined for the PHP code generation.
I tried checking out a new trunk just to make sure that this error was not something I introduced with my changes, and indeed it occurs as soon as you refresh UmpleToPhp in Eclipse. I believe that this problem goes back to the changes that were made just in the Java templates, then overwritten from UmpleToTemplate, and then moved over to UmpleToTemplate. So far the Java code in UmpleToTemplate had not propgated to PhpClassGenerator, but it does as soon as you need to make a change to PHP.
Since these lines seem specific to Java (e.g. baseJavaLine), I am not sure if they should just be removed from the general UmpleToTemplate and reintroduced specifically into the Java templates in a safe way, or whether they should be rewritten in UmpleToTemplate to be more general. I've written to Tim about this, and in the meantime I'll keep working on the JET templates for PHP and Ruby so that when this is sorted out I'll be able to finish up the unique keyword quickly.
So I started running tests today and making the fixes needed to make them all pass. I edited ClassTemplateTest_Attributes.ump to include a unique attribute, and then edited the expected output for Java and the other languages to reflect this change. At the moment Java is the only language for which unique is implemented, so at first I only edited the expected Java output, but then I realized that I still had to update C++, PHP, etc. to reflect the automatic getter and setter for an additional attribute. This was straightforward with PHP, but then with C++ I ran into some annoying whitespace problems where the tests where failing because my expected output had two spaces where the actual output had a tab. This surprised me because Tim had informed me that the Umple standard was supposed to be two spaces, and so I had set up my editor to automatically replace tabs with two spaces, but it turns out that there are still some whitespace-only lines which contain tabs instead of spaces, so this threw me off. I ended up having to regenerate the expected output and edit it (replace the version number with @UMPLE_VERSION@ using nano, since Eclipse and gedit were obliterating the delicate tabs. Finally ClassTemplateTest_Attributes.ump passed for all languages.
I then ran into another issue with 003_multipleExtraCode.ump, which was failing because # line was popping up where the test expected blah blah. This looked similar to the // line comments which I had deleted from my expected Java output, since the tests ignore line number comments, but in this case the tester clearly wasn't ignoring them. This was because of a recent change that JC made for Ruby, where comments are introduced by # rather than by //, and so to fix it I updated the test parser to ignore both // line <whatever> and # line <whatever>.
All tests are passing now. After sending an issue to Tim last night, which was quickly resolved, I've also been able to compile and test the Java code to ensure proper runtime behaviour, so I think that the unique keyword patch for Java is ready to go. I'll be sending it to Tim tonight.
So I got back on my Umple work tonight. I started by running svn update only to find that my build was irreperably broekn. I tried reverting the generated files with no success, and so finally I decided to just check out a new trunk and redo the changes I had made for the unique keyword. Luckily I had kept a log summarizes what I had changed and where I had changed it, so it wasn't too bad, and now the build is working again :) Back to testing now!
Issue 87 (on Google Code), the unique keyword, is almost finished now, at least for Java, and looks much like the outline in my post for September 21, below. One issue to address before submitting a patch for the issue is that primitive values are not handled correctly, since class Student {unique int id;}, Umple will try to generate Map<int, Student> which is incorrect and should be Map<Integer, Student>. I need to figure out how to do this autoboxing.
Update I've sorted out the primitive types issue. Turns out that calling
gen.getType(av)
will return the primitive type, e.g. int, while
av.getType()
returns the boxed class, e.g. Integer. So now the unique keyword is essentially fully implemented, but since its late and I'm tired I'm going to wait until I've tested it properly before sending in the patch. That said, I have quite a slew of assignments in the next few days and so will probably not be working on Umple until the weekend. Look for an update on September 28.
Back in Edmonton! This evening I spent a few hours working on the unique keyword. It's taking some time for me to understand the best place to edit code, between the JET templates and Generator_CodeJava.ump, to get the results that I want, but I'm slowly starting to understand how code generation and, in particular, code injection, works in Umple. So far, I've got the static map that will track the unique values and code injection working for setters. Tomorrow I'll figure out the best way to insert the hasXWithUniqueY and getXWithUniqueY methods, as well as the code injection for constructors and destructors.
Today I started working on issue 87 (on Google Code), which deals with implementing the unique keyword. In the morning I mostly focused on the planning stages of tackling the issue, where I looked at what work has already been done with unique and what I would need to edit to have the keyword behave as desired. At the moment, the metamodel as a UniqueIdentifier property in UmpleClass, which takes on a single attribute preceded by the unique keyword. This suggests a design where classes can only have one unique value; however, I felt that this is at odds with the behaviour suggested in issue 87 (on Google Code), where unique merely ensures that no two objects of the class can have the same value for its target field; this should in no way preclude a class from having multiple unique fields. After talking this over with Tim, we agreed that I should remove the current UniqueIdentifier and design unique to be more in line with this paradigm.
My plan for unique is as follows. This Umple code
Student {
unique id;
}
will generate the following Java
public class Student {
// STATIC FIELDS
private static final Map<String, Student> studentsById = new HashMap<>();
// MEMBER FIELDS
private String id;
// CONSTRUCTORS
public Student(String id) {
boolean wasSet = setId(id);
if (!wasSet) {
throw new RuntimeException("Cannot create due to duplicate id.");
}
}
// UNIQUE ID
private static Map<String, Student> getStudentsById() {
return studentsById;
}
public static getStudentWithId(String id) {
return getStudentsById().get(id);
}
public static boolean hasStudentWithId(String id) {
return getStudentsById().get(id) != null;
}
public String getId() {
return id;
}
public boolean hasId() {
return getId() != null;
}
public boolean setId(String aId) {
boolean wasSet;
if (hasStudentWithId(aId)) {
wasSet = false;
} else {
if (hasId()) {
getStudentsById().remove(getId());
}
getStudentsById().put(aId, this);
id = aId;
wasSet = true;
} return wasSet;
}
public void delete() {
getStudentsById().remove(getId());
}
Due to the confusion with JET templates, my build broke when I starting making changes to Java code generation, but this has been cleared up so I should be able to implement this tomorrow.
Today was the first day of the Code Sprint. After following the update instructions for working with Umple in Eclipse, and figuring out that I had to actually '''install''' php5 and rake, for PHP and Ruby tests, I managed to get my Eclipse devlopment environment working perfectly, for both compiling and testing. Hurrah!
Next, I decided to tackle issue 399 (on Google Code). This issue is a whitespace anomaly in state machines, where Umple fails to parse empty states (states without transitions) unless there is whitespace between the state name and the opening brace of the state body. Since whitespace should make no difference, this needed to be fixed.
In order to get going on this issue, I started by reviewing the Umple user manual and grammar for state machines. In order to make sense of the state machine grammar, I read through the explanation of the Umple grammar notation (http://cruise.eecs.uottawa.ca/umple/GrammarNotation.html). Since I don't have much previous experience with EBNF, this page was very helpful and allowed me to understand how state machines are being parsed.
The next useful step was setting up debugging in Eclipse. I used UmpleConsoleMain, in src-gen-umple, as my main class, and used Eclipse's Run Configuration dialog to pass an Umple test file to the program. Then I could insert break points in the generated Umple code with ease, which made it easy to see how the parser was treating the input files. This was the key to discovering what was wrong: in the state machine grammar, state machines can be simple enumerations, which are defined as
enum : [name] { } | [name] { [stateName] (, [stateName])* }
That is, an enumeration is a name followed by a comma-seperated list of state names between braces. Consider the buggy scenario where the have this state machine:
state {
first{}
}
Why does this fail? The parser treats it using the formula on the right side of the enumeration definition above, and because there is no restriction on the scope of stateName, other than that it must be a single token, the parser treats first{, with an opening brace at the end, as the stateName, and treats the following closing brace as the end of the enumeration. The closing brace at the very end, which should end the enumeration, is instead unrecognized, causing the parsing failure.
This hypothesis is all thanks to the Eclipse debugger, where the parser reports [stateName:first{] and gives its folly away. My solution is to correct the grammar to force stateName to be alphanumeric. The correction to the grammar is below, where the ~ operator ensures alphanumericity.
enum : [name] { } | [name] { [~stateName] (, [~stateName])* }
And preliminary tests show that all systems are go! One thing I'm not sure about is whether I should change all the other occurences of stateName in umple_state_machines.grammar to ~stateName. The enumeration line above is, as far as the tests show, the only offending line, but consistency might be preferable.
Today I started working on getting the Eclipse environment up and running. First I tried with Eclipse Kepler, but after having issues I downgraded to Indigo. Then I had to manually change the src files layout to get past the nested files issue. After following the steps in Development Setup, I went to Congifure Build Files > Sources and removed the source going directly to cruise.umple.compiler so that I could remove that folder from the exclude list for cruise. This removed all the errors in the main project, but there are still errors in the test files.
Last week I was going through the examples on Umple Online, seeing how Umple code works and how it converts to Java, and writing up a few simple systems on Umple Online while a read through the user manual, in order to understand the syntax of the language. This week I started going through the development setup. I still haven't got Umple working in Eclipse yet, but I've checked out and built my working copy from the command line and so far I've been using umple.jar to generate java from .ump files.
- Wiki Home
- FAQ Frequently asked questions
- Examples
- Presentations
- PhilosophyAndVision
- Best practices for using Umple
- Publications and theses
- Tutorials
- Installing Eclipse plugin