UCOSPLogVictoriaLacroix

Victoria Lacroix edited this page Feb 29, 2016 · 10 revisions
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

Log Entries

Date

Feb 28, 2016

It's been a frustrating few days for me. As I write this, Orionhub is currently down. Foolishly thinking that a web development service would stay up as long as I needed it to, I did not archive a copy of the orion.js, which all orion plugins use. I've unfortunately been set back a few days as just trying to find it has been a total headache.

Feb 18, 2016

Working with large code bases is a very interesting process. More often than not, you'll have a solid core that is easy to understand (in this case - the Umple compiler), but a lot of the times there are minuscule pieces that need some dedicated understanding of their own. UmpleOnline, to me, represents that problem.

When it comes to implementing a compilation process in Orion, I had several options available to me. The most appealing to me was to connect the Orion plugin directly to the compiler that's already a part of UmpleOnline using GET requests on compiler.php, which is a script in the aforementioned app. This provides the advantages of being ready-made (as it's already existing and working), and a nice central source for code compilation. Plus, Orion was made to work with AJAX-like techniques for getting data around. The problem with understanding this effectively came to breaking down how UmpleOnline compiles Umple models, recreating it minimally in Telnet, and then implementing that in the plugin proper. Telnet might seem like a strange choice but at least it guarantees a sort of minimalism with my implementation, and I do enjoy the tinkering process.

While I'm still in the process of ironing out the kinks on the Orion side of things, I'm definitely well on the way to connecting the compiler to Orion. Soon, Orion will be a proper (if still very minimal) environment for developing Umple code.

Feb 7, 2016

Not much done of relevance for future work - most of the week was spent trying to understand textmate syntax and correctly implement it into Eclipse Orion.

While not strictly related to the Umple project itself, Orion's weirdness with loading plugins is just bad when you're developing said plugin. Essentially, any plugin needs to be hosted on an HTTP server to be loaded into Orion. It guarantees that plugins are loaded in a fashion where users can know where they come from, but really causes problems when it comes to developing in a low-power environment (i.e a laptop from 2011). Installing nginx and copying the plugin to the server's document root solved the issue, but developing the plugin on a laptop that gets stressed easily is not favorable - and this does not even factor the fact that Orion is also running it's own all-in-one server.

Gripes aside, I've now got a basic highlighter going for UmpleOrion. Keywords, brace matching, comments, numbers and strings are all syntactically highlighted in Orion. The next step is recognizing and highlighting extra code for Java, C++ and PHP, which will require some more advanced usage of the Javascript regular expression recognition.

Preliminary implementations provide some roadblocks with this. For instance

// start Java extra code
Java
{
    public void someMethod()
    {

        // some code

    } // This brace registers as the closing brace for Java syntax, which means...
    // This is only highlighted as umple code.
    public int someInt;
}

The above example is really problematic when it comes to an easy solution to highlighting extra code properly. There is an implementation (like UmpleOnline's) that simply import's Orion's existing grammars for Java and C++ but that is less that ideal. If I cannot find a solution, then I'll leave the current result as-is for the plugin's development this term.

Next up though? Compiling and then eventually running Umple code in Orion.

Feb 1, 2016

Not much progress done in terms of getting something concrete put out. I've been assigned the task of writing a plugin for Eclipse Orion with the goal of eventually replacing UmpleOnline. I'm going to use the tentative name of UmpleOrion for the plugin (because it sounds like UmpleOnline, which it will replace). The Orion approach gives quite a few benefits, including:

  • Existing support for many highlighters (Java, C++, etc...) which can be used for extra code in Umple
  • Git support
  • Runs projects as web applications
  • Simple plugin API in Javascript

UmpleOrion would provide a full environment to develop software in Umple, supporting many languages. Ideally, (although this may not be possible on the Cruise server) UmpleOrion would also provide compilers for Java and C++ code, and interpreters for other code to allow the user to fully run their Umple code on the server directly. My goals for the term are:

  • Provide syntax highlight for textual Umple models and extra code of other languages.
  • Allow the user to compile Umple code to all the usual suspects (Java, etc)
  • Allow the user to generate a visual model from their Umple code (much like how Orion does by default with Markdown)

Syntax highlight (for Umple at least) should be trivial as Orion uses TextMate syntax, which is very well-documented. Compilation would require a local instance of the compiler, which again is no problem. As a nice side effect, compilation would add the resulting files to the users' project directories, allowing them to see the results and not have them disappear. Visual models will be a little trickier but emulating UmpleOnline's behaviour should get that done.

Jan 21-26, 2016

Would've been done sooner, if it wasn't for a pesky hackathon.

Issue 680

Summary

Injection of code before/after other methods in classes only injects into the first listed method.

class A
{
  Integer x;
  Integer y;
  before setX,setY
  {
    //this an injected code; 
  }
  after setX,setY
  {
    //this another injected code; 
  }
}

Only setX() has code injected before or after it.

Searching

My first clue was UmpleInternalParser_CodeClass.ump:2560. The method analyses injected code, but only injects the first method.

This method uses a StringBuilder to build the proper token, never passes it into the CodeInjection constructor. Easy fix!

Jan 15-16, 2016

Issue summary

Issue #608 is that Umple doesn't quite properly handle abstract classes.

If an abstract class implements an interface, then Umple will incorrectly create a default implementation of methods from the interface, even though it should only do so for non-abstract child classes.

Example Code

interface I {
    Integer I1();
}

class A {
    isA I;
}

class B {
    abstract;
    isA I;
}

class C {
    isA B;
}

Even though B is abstract, Umple will still create a default method for I1() in B. This should be fixed so that Umple only implements default methods for non-abstract, non-interface classes.

Observations

Points of interest are:

  • /cruise.umple/src/UmpleInternalParser_CodeClass.ump:1321
  • /cruise.umple/src/Umple_Code.ump:1286

Adding an abstract check to the third one prevented the method from being default implemented, but it does not properly implement in the C class. Progress!

After a night of rest, I've reexamined the code and realized that when generating methods for Interfaces, Umple does not recursively check the interfaces of the parent (extends) class. This is fine when you have no abstract class, but because we have classes explicitly not implementing methods from parent interfaces, a class needs to check for unimplemented methods from every interface in it's lineage. All one needs is a method to check all the parent class' interfaces.

Another problem that came up with this approach however was that Complex Inheritance and Cyclical Inheritance would completely fail, as the original method would not track how far down in a chain it was. All that's needed is to have a list of already traversed classes

Work Summary

This issue had problems in two places:

  • Methods from an interface would always implement into a class, even if was abstract. Now if a class is abstract, methods will not automatically implement.
  • Due to the previous assumption, classes would only auto-generate interface methods from direct parent interfaces, under the assumting that interfaces in parent classes always received their own default implementation. Now, interfaces are checked through the whole lineage, and end up only being implemented in the first non-abstract classes.

Jan 4, 2016

Day 1 of the UCOSP term. I've read up some of the Metamodel for the Umple project. Unsurprisingly, it is very extensive. I'll definitely continue reading it into the week.

Dec 31, 2015

I've locally cloned the Umple repository in anticipation of the upcoming UCOSP term. Using JDK8 and Ant, Umple built without a hitch and I've added the helper binaries (in the dev-tools directory) to my PATH. A small test compile of an .ump file returned some java code, which then successfully compiled to .class files. I've opted out of setting up an IDE for this project as I prefer to work with ViM and command-line tools for speed.

I tested some of what Umple could do by very slightly "Umplifying" a side project for fun that I've been working on. I'm really into the approach that Umple takes with code generation - it's designed as a sort-of replacement for code, as it is not recommended to edit the generated code even if it's not been compiled to a binary. I'm considering porting more of that side project to Umple in my spare time. A video game in UML would be a sight to behold indeed.