This is the first blog post from the UCOSP Umple Team for Winter 2012. We are working on Umple project, which is a modeling tool and programming language which allows one to perform model-oriented programming.

My fellow USCOP colleagues have been working on some interesting projects. Adam Dzialoszynski has been working on SQL statement generation, which allows Umple to generate an SQL database schema. Sonya Adams has been working on adding a new feature to the Umple language which allows a class to be declared as immutable. Jordan Johns has been working on improving how code comments written in Umple code are saved and transferred to the compiled destination programming language code. Luna Lu is currently working on issue 142 which deals with a bug in the language where deletion on a object that has a 1-to-many association is not working. Song Bae Choi is working on issue 21, where Umple in a certain circumstance generates uncompilable Java code.

What I have been working on is to make the Umple compiler appear more like the gcc compiler. I have started by adding command line options to the Umple compiler, implementing some of the simpler command line options, such as printing the current compiler version number. I am currently working on a command line option feature, which can control the programming language Umple will output.

After having started working on Umple for three weeks, I have learned how to look at large projects with multiple components. Also now understand the use of ant build scripts, which will be very useful in the future. A challenge now is juggling time between my other busy courses and Umple work. I expect this to be a very important skill to have since I would like to participate in more OpenSouce projects in the future.

The UCOSP code sprint for the winter 2012 semester was held at UBC, Vancouver between January 20th and 22nd. The MarkUs Canadian team for this semester is made up of 3 students from UBC, 4 students from University of Toronto, 1 from York, and 1 from SFU. MarkUs is an online marking tool that provides instructors with the ability to hand out assignments online, students with the ability to submit the assignments and graders with the ability to grade and give feedback to students.

Most of Friday was spent at getting MarkUs development environments set up. There was also a Distributed Version Control System tutorial focusing more on the general use of Git which was followed by a MarkUs specific Git tutorial. Due to numerous architecture and operating systems issues, we also had to spend part of Saturday setting up some environments while students already set up fixed some bugs. Sunday was spent working on bugs and saying good byes. By the end of the code sprint, we got to fix three bugs and start working on many more.

The code sprint this semester was great. We got to visit Vancouver and meet other UCOSP students.

The sprint began with a short group session, and shortly afterwards we split up into our individual teams and began what would be a solid weekend of productivity. We set up our development environments and workflows, and although it wasn’t without hardware and software issues, we more or less got straight to work fixing bugs, picking up long-term projects, and doing peer code reviews using Review Board itself. The code sprint had many good lessons, both explicitly in the form of a git tutorial (a version control system that is crucial in sharing and backing up work between distributed team members), and implicitly as we got comfortable working with the other members of our group and got our code reviewed.

I have picked up a long-term project in the form of a helper script that will generate the scaffolding for Review Board extensions. Essentially, this will fill out a bare-bones skeleton for a working extension based on a simplified configuration scheme that will be provided by a user. Currently, documentation on extensions is scarce, but I hope to be able to flesh out documentation on the wiki page with fellow team member Steven.

I am posting this as I wait for my flight home from an exciting and productive code sprint. I am confident that working on the project will continue to be as enjoyable and enlightening as this code sprint has been.

UCOSP students are have tackled some smaller features and bugs, and are now working on a couple of long-standing major issues: Generating comprehensive and useful error messages, and getting rid of certain syntax oddities.

Dr. Lethbridge, the project mentor, just posted a blog post that covers the recent work in technical detail:

We asked each of the three UCOSP students to highlight what they have been learning and doing, what they have liked about the project so far, and what improvements they think they would like to see to how Umple is developed or the how UCOSP program is run.

From Joshua Horacsek:

Basically, I’ve been working on making Umple more user-friendly. I’ve been reworking the way Umple handles lexical and semantic errors, hopefully making it more robust, and ultimately more useable.

My favourite part of Umple isn’t necessarily what the project aims to accomplish, but rather how the different components of Umple are built, what they’re built with, and how they interact. That’s not to say the idea of a model based language isn’t interesting, it’s just that Umple’s a fairly large project, and it’s pretty fun to navigate.

I’ve learned how to look at a fairly large project with multiple different components, and break it down into components that I understand. I’ve also learned the benefit of test driven development, and the headaches and time it saves.

As of right now, I have two primary goals. The first is to get Umple to a point where it produces concise error feedback for a wide variety of input. The second goal is tied to code generation from an Umple model. Currently, Umple can generate code for various languages such as Java, PHP and Ruby. If I have time I’d like to extend it to generate SQL models, and if not, at least there’ll be some partial code for a future UCOSP project.

From my perspective, I can’t really see what either UCOSP or Umple could be doing better for UCOSP students.

From Alvina Lee:

I am working on a feature which allows umple to generate comments before classes. I made patches for issues regarding lazy keywords for attributes in generating singleton classes as well as automatically changing associations from 1 to 0..1 (issue 26).

I like that I get to learn new things and make use of computer science related stuff I’ve used before.

What I am learning:

• Using JUnit on larger projects
• Learning to work with other people who do not live in the same area on the same project
• Learning to use new technology that I am not familiar with
• Learning about UML

By the end of this term, I will have some involvement with error parsing and have commenting for attributes and other objects implemented.

What the project could be doing better: Umple has included some video tutorials. While I appreciate the fact that they are offering help in setting up the developing environment, I do not like video tutorials because I have to wait to download them, and I dislike the format because it is harder to skip around to relevant sections if I am already familiar with what is being explained in some parts of the tutorial.

From Joel Hobson:

My name is Joel Hobson, and this is my first blog post for the UCOSP project and Umple. I’m currently working on two main tasks for Umple – First, I’m working on adding a debug mode for developers that shows which JET templates generate specific code, in order to make it easier to add new languages to Umple. My other main task is fixing the various bugs regarding whitespace. Umple is currently finicky about whitespace, and code that programmers would expect to be valid, such as class X { attributeName=”"; } causes problems.

I’ve never had the opportunity to work on a large software project before, and I’ve greatly enjoyed the experience. Umple is a very interesting project, and I feel it could be extremely useful for large software projects when it becomes a little more mature.

Working on Umple, I’ve learned a great deal about test-driven development. I had a vague understanding of the concept before, but now that I’ve actually used it I can see just how useful it is. I’ve also gained experience working with Apache Ant and Subversion, and have a much better idea of how contribution to open source projects works. The biggest challenge so far was getting it to build correctly on my system. Even now, I have some difficulty with errors in the build process, but overall things are going fairly smoothly.

My goals for the project include finishing the debug mode and fixing the whitespace bugs, as well as writing Umple extensions for various text editors and fixing random bugs, time permitting.

I’m glad to hear that the code sprint was worthwhile!