Model-oriented programming (MOP) and the Umple language

My own current research focuses on a concept I call model-oriented programming (MOP), and a technology called Umple for developing software using the MOP approach. I think that adoption of MOP could lead to considerable improvement in software engineering productivity and quality.

Model-oriented programming encompasses the following:

• Adding new abstractions to programming languages: Modeling concepts, taken from UML and perhaps other modeling languages, are added, in as seamless a manner as possible, to extend object-oriented programming languages. These modeling concepts raise the level of abstraction. Example modeling concepts include UML associations and state machines.
• Choice of workflow when adopting the new abstractions: To develop software using a MOP language, a programmer can take a model-first approach or can incrementally re-engineer an existing program to add modeling concepts. The model-first approach means that you write a program in a MOP language using just the modeling abstractions initially, adding other parts of the program, such as algorithmic methods, later. The incremental re-engineering approach means taking an existing program and iteratively 1) identifying code that represents a modeling concept, and 2) replacing that code with equivalent model code. This in general reduces code volume while increasing abstraction, and hopefully increasing understandability.
• Enabling of text-diagram duality: A MOP program is inherently in a human-readable textual form, like any of the other programming languages we are familiar with, but since it also contains modeling abstractions, the code can be directly viewed as a  diagram. Furthermore, with appropriate tool support, MOP code can be edited equally well using a textual editor or a diagram editor. Changes to the diagram should appear as you edit the text, and vice-versa.
• Continuing the trend in evolution of programming languages: In MOP a model is a program and a program is a model. There is no distinction. Within the model/program there are elements of higher and lower abstraction. But this has always been the case in programming languages. Classes are a higher-level abstraction added to procedural programming languages to create object-oriented programming languages. MOP just continues this trend by adding additional modeling concepts.
• Elimination of 'round-tripping': A compiler for an MOP language acts just like a compiler for any other language. Programmers don't need to look at or edit the generated code.

With MOP, barriers to adoption of modeling should be eliminated. A programmer can use just enough MOP to get a taste for it and gain confidence before plunging into the modeling world.

My research group has spent the last few years exploring MOP and creating the Umple technology. Umple adds UML concepts such as associations and state machines to Java, Ruby and PHP. In future, we plan to also tackle C++. We call the process of reverse engineering from any of these to Umple, umplification.

Umple is a triple play on words. It can mean UML programming language, or it can mean a language with ample capability for creating programs with UML concepts. It doesn't incorporate all UML concepts, in order to keep it ultimately simple.

To demonstrate that Umple works, we rewrote the Umple compiler in Umple, hence 'eating our own dogfood'. I wonder how many modeling tool developers have used modeling to help design their own tool, let alone have generated their own tool entirely from their model.

Several professors have used Umple in the classroom, and it seems to be a useful tool to help students really understand the benefits of modeling. It has also been used in some industrial projects and student projects in several countries.

Umple is not the only language that has the MOP characteristics. The OMG's Alf language also has most of the capabilities of the MOP vision. The only exception, I think, is that instead of building UML abstractions on top of existing languages, the Alf developers are creating their own language from scratch. The ability to incrementally re-engineer will therefore be much diminished.

We plan to make Umple open source using Google Code by the end of 2010, but it is available today in two forms. You can try the UmpleOnline tool at http://cruise.site.uottawa.ca/umpleonline/ . This allows you to create Umple programs consisting of a single file both textually and graphically. There are also many examples of Umple to browse. If you want to do more serious development, then download the Eclipse plug-in; there is a link to this on the UmpleOnline page.

I will have a lot more to say about Umple in future posts. I will use the label 'Umple' so you can separate the Umple posts from posts on unrelated topics.

Credit for help with development of Umple and MOP concepts needs to go to many sources. These include IBM which have been our big sponsor, and have said they will continue to sponsor us. NSERC, the Canadian government funding agency, has also supported the work. Credit also goes to the graduate and undergraduate students who have worked, and are continuing to work on Umple. These include Andrew Forward, Dusan Brestovansky, Julian Solano, Jenya Levin, Omar Badreddin and Julie Filion.  Completed theses about Umple can be found here.