UML in Practice talk at ICSE: And How Umple Could Help

I just  finished attending the ICSE talk by Marian Petre of Open University, entitled "UML in Practice"

She conducted an excellent interview-based study of 50 software developers in a wide variety of industries and geographical locations. Her key question was, "Do you use UML".

She found that only 15 out of 50 use it in some way, and none use it wholeheartedly.

A total of 11 use it selectively, adapting it as necessary depending on the audience. Of this group use of diagram types was: Class diagrams: 7, sequence diagrams: 6, activity diagrams: 6, state diagrams: 2 and use case diagrams: 1.

Only 3 used it for code generation; these were generally in the context of product lines and embedded software. Such users, however, tended not to use it for early phases of design, only for generation.

One used it in what she called 'retrofit' mode, i.e. "Not unless the client demands it for some reason".

That leaves the 35 software developers who do not use it (70%). Some reported historical use, and some of these did in fact model using their own notation.

The main complaints were that it is unnecessarily complex, lacks and ability to represent the whole system, and has difficulties when it comes to synchronization of artifacts. There were also comments about certain diagram types, such as state machines being only used as an aid to thinking. In general, diagram types were seen as not working well together.

She did comment on the fact that UML is widely taught in educational programs.

My overall response to this paper is, 'bingo'. The paper backs up research results we have previously published, which served as a motivation for the development of Umple.

Features of Umple that are explicitly designed to help improve UML adoption include:

• Umple can be used to sketch (using UmpleOnline) and the sketch can become the core of high quality generated code later on.
• It is a simplified subset of UML, combatting the complexity complained about in the Petre's research.
• It explicitly addresses synchronization of artifacts by merging code and UML in one textual form: UML, expressed textually is just embedded in code, with the ability to generate diagrams 'on the fly', and edit the code by editing either the code or those diagrams.
• It integrates diagram types: State machines work smoothly with class diagrams, for example.
• Diagrams like state machines finally become useful in a wide variety of systems, not just embedded systems.

I hope that if Umple can become popular, then in a few years, we could do a study like this and report quite different results.

Scaling up Software Engineering to Ultra-Large Systems: Thoughts on an ICSE Keynote by Linda Northrup

Linda Northrup just gave an interesting talk at ICSE 2013 about ultra-large scale systems (ULS).

My takeaway from this talk are the following points:

• ULS refers to systems with large volumes of most of the following factors all combined together synergistically to increase complexity: source code in multiple languages and architectures, data, device types and devices, connections, processes, stakeholders, interactions, domains (including policy domains) and emergent behaviors.
• ULS systems run in a federated manner; they are on all the time, with inevitable failures handled and recovered locally, so as not to effect the system as a whole. The analogy to the functioning of a city (where fires occur every day) was very apt.
• Build-time and run-time are one-and-the-same: Pieces of a system need to be replaced on the fly, and dynamic updating and reconfiguration needs to be possible.
• They inevitably involve 'wicked' problems with inconsistent, unknowable requirements that change as a result of their solution.
• Development can neither be entirely agile (due to the need to co-ordinate some aspects of the system on a vast scale), nor follow traditional 'requirements-first' engineering. On the other hand, parts of a system can be developed in an agile manner.
• All areas of software engineering and computer science research can be used to help solve issues in ULS. Examples include HCI studies of how diverse groups of users use diverse parts of such systems, or computational intelligence applications to such systems.

She gave some examples including the smart grid, climate modelling, intelligent transportation and healthcare analytics. Actually It is not clear to me that climate modelling necessarily fits the definition. It may have large volumes of code, and run in a distributed manner, with federated models, and quite a few stakeholders and policy domains, but do a majority of the other factors above apply? Perhaps.

From my perspective, key to ensuring that ULS systems can be build and work properly are to apply the following techniques and technologies. However, in order to do this we need to properly educating computer scientists and software engineers with knowledge about these items that we know today, but which is not universally taught, and hence not applied:

1. Model driven development (with tools that generate good quality code in multiple languages and for multiple device types)
2. Distributed software architecture and development
3. Rugged service interfaces so subsystems can be independent of each other, and have failsafe fallbacks
4. Test-driven development: Where requirements are unknowable, it is still possible to specify those parts of systems that can be understood with rigorous tests. Subsystems so-specified can then be confidently plugged together as requirements evolve.
5. Spot-formality: Formal specification of parts of a federated ULS system that are critical to safety, the economy, or the environment. 
6. Usability and HCI to ensure that the human parts of the system interacts with the non-human parts effectively.

My Umple research helps address item 1, and is moving towards addressing items 2, 3 and 5. We deploy item 4 and 6 in the development of Umple.

Some lessons from MiSE at ICSE

I just finished attending the two-day Modeling in Software Engineering workshop at the International Conference on Software Engineering in San Francisco.

Here are some of the take-away lessons for me (these do not necessarily reflect the ideas of the speakers, but my interpretations and/or extensions of their ideas)

Industrial use of modeling: There was very interesting discussion about the use of modeling in industry, but there seem to be two key and related directions for such use: Michael Whalen on Saturday gave lots of examples of the use of Matlab and SImulink in various critical systems (and particularly the use of StateFlow). Lionel Briand, on the other hand talked about using UML and its profiles to solve various engineering problems, again, however, he mostly focused on critical systems. In a panel he pointed out that most of the Simulink models he had worked with are just graphical representations of what could just as well be written in code (i.e. with little or nothing in the way of additional abstraction).

What struck me was that both presenters, and others, seemed to embrace what I might call 'scruffy' modelling: Briand talked about users adapting UML to their needs, and others talking about SImulink as  a tool that does not have the formal basis of competing tools, but nonetheless serves its users well.

Many people in the workshop pointed out that we need to boost the uptake of modelling. Various ways to achieve this were emphasized:

• Improve education of modelling
• Build libraries of examples, including exciting real-world ones, and ones that show scaling up
• Make tools that are simpler and/or better so more 'ordinary' developers will consider taking up modelling
• Allow modeling notations to work with each other and other languages and tools

It turns out that all four of these have long been objectives of my Umple project. So it seems to me that if the Umple project pushes on at its present pace, we stand to have a big impact.

Speaking of Umple, I gave a short presentation that seemed to be well received, although my personal demonstrations to a number of participants seemed much more effective with people appearing to be quite impressed. The lessons from this is that people really can see the advantages of our approach, but a hands-on and personal approach may work best, as a way to help people see the light.

Context: Another theme of the MiSE workshop that repeatedly appeared was 'context'. Briand pointed out that understanding the problem and its context is critical before working on a model-based solution; the modelling technique to be used will depend deeply on this context. Context can be requirements vs. design, or the specifics of the domain, the fact that space systems must be radiation hardened, or some aspect of the particular problem.

In my opinion, they are certainly right: Understanding the context is critical, and the tool, notation or technique needs to be selected to fit the context, However I also believe that we need to work on generalities that can apply to multiple contexts, in the same manner that general-purpose programming languages can be used in multiple contexts. For example the general notion of concept/class generalization hierarchies can be applied in almost every context, whether it be modeling the domain, specifying requirements for the types of data to be handled, or designing a system for code generation. I think state machines can also be applied in a wider variety of contexts, where people currently do not apply them: They are applied in many real-time systems, and they have been applied for specifying the navigation in user interfaces. But in my experience they can be applied in systems such as in this Umple example.

Testing: An interesting theme that came up several times related to testing: It was pointed out that it is worthwhile to generate tests from a model, but it also must be respected that in the context of a model used to generate code, these tests serve only to verify that the code generator is working properly! Such tests do not validate the model. Additional testing of the system is always essential.

Semantics and analysis: There was a lot of agreement that the power of modeling abstractions can be leveraged to enable analysis of the properties of systems. To do this however, it seems to me that semantics needs to be pinned down and better defined. 'Scruffy' use of UML and simulink seem to detract from these possibilities. Again, one of the objectives of Umple is to select a well-defined subset of UML, to define the semantics of this very well, and and to be able to analyse system designs in addition to generating systems from the models.

Steady progress developing Umple

I would like to end 2012 by highlighting how the Umple model-oriented programming technology is progressing.

Numerous people have worked on Umple during 2012 including my graduate students Hamoud Aljamaan, Sultan Eid and Miguel Garzon as well as several former graduate students. Twelve UCOSP students fixed bugs and added many small features. UCOSP arranges for fourth-year students at many Canadian universities to work on open-source projects as their capstone course project. They have all been logging their progress.

Over 68 issues were closed in 2012, and many more have been moved into the 'Mostly done' status. Some of the key changes include:

• Many more error and warning messages (such as this) to help users create correct Umple code (e.g. detecting duplicate attribute names).
• Greater stability and functionality for UmpleOnline: It works better between browsers and looks much nicer, with syntax highlighting.
• Arguments to transition events on state machines, and various other state machine improvements, such as automatic transitions upon completion of a do activity.
• Immutable attributes and associations.
• Automatically sorted associations.
• Generated code that indicates the line number in the original Umple files where it came from, allowing editing and compiling of Umple, with error messages in Java pointing back to Umple line numbers.
• Improved documentation, including an API reference, and a generated grammar document that is nicely coloured.
• Passing through comments from the Umple source to the generated Java.
• Command line arguments, such as controlling the language generated, and ordering Umple to compile the generated code.
• Ability to embed an UmpleOnline diagram, or textual Umple, in a web page.
• Numerous bug fixes.

Work well underway includes:

• Adding constraints to Umple. Simple constraints where you specify and attribute, a comparator and a value are working, e.g. [age > 18]. These will prevent setters from violating the constraint.
• Adding C++ code generation. Most of the pieces are in place, although it is not compete yet.
• Adding a comprehensive tracing capability (Model-Oriented Tracing Language) to allow injection of trace directives at an abstract level.
• Adding basic SQL generation.
• Adding a capability to reverse engineer code into umple (umplification).
• Generation of state machine diagrams using the -g GvStateDiagram option.
• The UIGU tool for generating user interfaces from models (this is essentially complete, but has been found to be too inefficient for widespread use, so it needs refactoring or rewriting).

In addition to making progress on the above, work planned for the near future includes:

• Adding Autosar, multi-threading and real-time concepts to Umple.
• Adding generation of formal specifications, as well as formal specification of umple semantics.
• Research into comparing umple to regular code using metrics.
• Further research into usability of Umple
• Ability to debug code in Umple without relying on looking at generated code
• Many more example systems
• Automatic layout in UmpleOnline, using GraphViz.

Ongoing news about Umple can be found on Facebook and Google Plus. An up to date analysis of Umple can be found on Ohloh.

Video series: Creating a class diagram in Umple of a simple manufacturing plant controller system

Since I am at the Models Conference in Austria, I had to cancel my SEG2105 class. I decided to present my lecture through a series of YoutTube videos.

The video series, which can be seen here, starts with analysing a simple description of a manufacturing plant by highlighting parts of the text that may represent classes, associations and attributes. Then I use Umple Online to create the class diagram step-by-step.

The original description of the manufacturing plant comes from my book, and is reproduced below


This system will be used to manage and control the production processes at Use Case Industries’ manufacturing plant. The plant makes several types of mechanical devices. It has 10 assembly lines, each of which can be used in the manufacturing of any of its products. An assembly line is allocated to a product for a fixed period of time (anywhere from a few hours to a few days) – this is called a product run. During a product run, the assembly line makes a specified number of units of the product.

Each product is assembled in several steps. As the product-under- construction moves down the assembly line, it will be worked on in turn by a series of robots. Each robot completes one step before the product moves on to the next step (and a different robot). Each robot is dedicated to just one manufacturing step.

Each product is composed of parts. Parts may be bought from suppliers, or they may in fact be smaller products that are built by this company (in earlier product runs). In each manufacturing step, a given subset of these parts is put together. Parts waiting for assembly are kept in numbered bins; the robots know which bins to go to in order to get the required parts.

Each completed assembly is given a serial number. When orders for products are filled, the serial numbers of the products sold are recorded with the order.

In fear of the great Google Shutdown train: What could be next?

Google has been in a frenzy of 'cleanup' activity over the last few months. It is beginning to make me feel positively uncomfortable.

Google's latest blog post announces the shutdown of a number of services that are not doing well, notably Google Wave and Knol.

I think it is the latter that alarms me the most. They point out that the proposed replacement for Knol is WordPress based. Yet they have their own Blogger service (which you are using right now to read this) that competes against WordPress. Does that mean that the writing will be on the wall some time in the future for Blogger? It certainly makes me think about moving this blog elsewhere.

In addition to Blogger, I am heavily invested in Google Code for the Umple project. Will Google Code be on the chopping block too at some point? After all, like Blogger it is a service that Google provides on a largely public-service basis. Google is already shutting down 'Code search' with no announced replacement, and has severely limited the usability of Google Groups, as I have previously commented.

I think that if I had read all these announcements a year ago when I was first starting blogging and open-source development, I would likely have chosen different platforms. I imagine many people just setting out to use such online services will think the same thing. I chose Google because it is a large company with a reputation for stability, innovation and beneficence. Two of my factors in choosing Blogger and Google Code over WordPress and GitHub were the integration with Google accounts and Google search. However long-term stability trumps all. Using Google services puts me at the mercy of Google Shutdown.

I will persist with Google for now, hoping their 'Do no evil' mantra wins out in the end. However, I am continuing to take steps to protect myself. These include making all links to the Umple project go through the umple.org domain, so I can relocate them if I had to, and regularly backing up my subversion repository and blog. I will be looking into mirroring my blog on a domain and server I have full control over.

I also hereby ask Google:

• To make formal 10-year service guarantees for its services in which people invest huge amounts of personal time, like Google Code, Blogger and  Google Groups.
• To extend these guarantees each year, so any potential shutdown would always be 10 years out
• To publish usage statistics trends of its services so we can be confident that we are using services that are not dwindling in numbers of users.
• To keep data in shut-down services visible in a read-only manner without limit  (e.g. keeping Knol URLs active for reading indefinitely, so links that point to them never go stale). There would be very little cost in doing this.

I think that unless Google does this, more and more people will migrate away, and fewer and fewer new users will adopt these services, resulting in a self-fulfilling prophesy of shutdown due to low usage.

And lest people think I am being unfair to Google, or risking having Google push me personally off its services for criticizing it, I have been just as critical of Apple, and have not even ventured near Microsoft's online services since they have historically been too closed. Google is still an excellent online service provider for blogging, open-source code hosting, and mailing lists, and is still probably a lower risk than smaller companies regarding potential shutdown. But overall, I now do not consider it a low risk in this regard.

Also in defense of Google, they do make their announcements in a reasonably friendly way and try to suggest alternatives. I do wish in their announcements they would tell us the number of users they estimate to be affected (both content providers and readers).

Umple: status and recent progress

Here's a recap of what's going on in the development of Umple, as of mid-October 2011. This covers the most significant news from the last few months.

People on the Project:

We have had several fourth-year students from universities across Canada working on our project through the UCOSP program. Collectively they have banished several long-standing bugs in the compiler and are now working on some of the changes discussed below. The current three participants are Joshua Horacsek, Joel Hobson and Alvina Lee. We anticipate additional groups of students each semester.

Four graduate students are also very active in improving Umple: Omar Baddredin (state machines), Hamoud Aljamaan (tracing), Miguel Garzon (umplification), and Sultan Eid (C++). Andrew Forward, one of the long-term system architects, remains active and will be working on patterns and empirical studies with Umple.


User Manual and Wiki:

The user manual has been upgraded so most mature Umple features are now described, with examples. The examples can be made 'live' in UmpleOnline. Effort has also been put into improving the organization of the wiki, particularly pages to help people installing Umple and who want to develop Umple itself.


UmpleOnline:

UmpleOnline has seen several important improvements. There are now a variety of ways to open Umple models directly as part of URL. You can open any .ump file on the Internet using the 'filename' argument. You can also open the built-in examples using the 'example' argument, or models you are collaboratively evolving with the 'model' argument. UmpleOnline now also allows you to generate zip files and JavaDoc documentation.

Taken together with the enhancements to the user manual, these features have significantly improved the ability to use Umple to teach UML in the classroom.

Future: UmpleOnline's graphics for drawing class diagrams have some glitches related largely to cross-browser compatibility. We are therefore planning to move towards using a toolkit that will render diagrams using html5. We hope to achieve this within a year, maybe sooner.


Outreach and publicity:

One of our key needs is to have more developers using Umple. This will result in improved quality (through detection and correction of bugs, and discovery of new features) and will hopefully result in more people understanding and adopting our overall philosophy and vision. Hopefully this will in turn improve software engineering more generally.

The Umple Facebook page has received a lot of traffic. We frequently post small news items here. Facebook says that many of these get 100 or more views. Please 'Like' this page. We currently have 21 likes; when we get 25 likes we will be eligible for a much nicer URL in Facebook.

Umple is listed on all the important open-source directories, specifically

• Ohloh: We have 4 people who indicate they use Umple. Interestingly, they calculate that our code base must have resulted from over $4million of work, when in fact total funds paid have been on the order of $200k, since this has been largely developed by PhD and masters students. We are listed on the second page of their UML tools directory; if 7 more people indicate they use Umple, then we would be listed on the first page.
• The Open Source Directory: We are currently rated as 4.5 stars.
• Freshmeat: This is the standard place to post release notifications.

We encourage everybody to +1, 'Like', and indicate they 'use' Umple on all these sites.


Compiler:

We are going to make a new formal release of the compiler soon (1.15). This will incorporate a lot of bug fixes and enhancements that have been recently made. UmpleOnline always uses the 'bleeding edge' of the compiler, so is ahead of the formal release cycle; you can try out the forthcoming 1.15 there. With the formal 1.15 release, we will change Umple to compile itself using 1.15.

Recent changes to the compiler (available in UmpleOnline and will be available in 1.15):

Issue 221: isX methods now are generated by the compiler from Boolean attributes. This is consistent with Java conventions. Note that getX methods are also still generated for compatibility.

Issue 26: Singleton classes no longer generate constructors that require arguments. The 'lazy' keyword can now be applied to any attribute, if you don't want it to appear in the constructor; the fix to issue 229 is to default all attributes to lazy. In addition associations to other classes with a '1' end will instead be interpreted as 0..1.

Issue 229: The generate clause can now take an argument specifying a directory where the code will be output. This is useful for build scripts. You can have different generate clauses for each language (e.g. java and PhP). You can use the 'override' keyword to ignore any subsequent generate clauses.

Issue 146 and issue 227: Comments placed immediately before a class in Umple now appear in the generated code. In Java these are generated in such a manner that they will appear in generated JavaDoc documentation.

Issue 137: Use of depend after the isA keyword no longer fails.

Issue 172: Tracing: You can now use the 'trace' keyword followed by an attribute name to output a record of changes. You can also do this conditionally. This is the first phase of large tracing capability being added to Umple. Tracing of associations will be added soon.

Issue 223: Developer debug mode: This will allow developers of Umple to determine the Jet template where generated code originated (this is actually not active yet, but when completed, it will be a key part of 1.15).

Plans for the compiler for the next few months:

1. Issues 238, 239 and 240: History and final states: These enhancements to state machines are under development. Both are part of UML. They may make it into 1.15, or may be released later. Entering a final state would result in deletion of the object. If there are several concurrent regions in a state machine, the deletion would only occur when all regions reach the final state.

2. Issue 66: Useful error messages. The biggest weakness in Umple currently is that its error messages just point to the point of failure of a parse. In UmpleOnline, even that is missing. UCOSP students are working now on building the infrastructure for comprehensive error reporting. This would include reporting parser errors as well as semantic errors in Umple (e.g. making a class a subclass of itself) and errors from the base-language compiler that is used to compile methods. Once this is all done, Umple should appear to any programmer just like any other compiler.

3. Issues 154, 155, 236 and others: Spacing issues in the parser. The parser is overly sensitive to the location of spaces. This is being addressed.

4. Issue 19: C++ generated from Umple. We have enabled 'generate cpp'; initially this is a clone of Java. Over the next few months we will adapt the code so it is proper C++.

In addition, further work on tracing will be accomplished, and the first public release of the umplificator tool might become available


Known bugs:

Several bugs have recently surfaced that warrant note:

Windows 7: Although Umple can be used in Windows 7, Umple itself seemingly can't be developed in Windows 7 due to bugs that remain unresolved at this time. Development of Umple can be performed on Mac, Linux or earlier versions of Windows.

Issue 235: Compiler generated in Mac OS adds escape characters to quotes. Although the compiler should be identical no matter where it is built, there is currently an issue with a compiler built on Mac OS when the ="initial value" notation used. A compiler generated on another platform will work fine on Mac OS.

Steve Jobs: A Personal Inspiration

Here's are my personal thoughts about what Steve Jobs has meant to me, and how I hope many aspects of his like will continue to serve as an inspiration to me for many years to come.

I have been an Apple user since the earliest days, and have exclusively used Macs as my personal computers since 1984.

It was partly the stark simplicity of the early Macs, and of many later Apple products, that led me to focus my career on usability and simplicity in software engineering.

But perhaps, above all, it is Steve Job's rejection of many technology dogmas, and his advice to not be afraid of changing course, and even quitting a job that one doesn't like, that I think it is most important to take as an inspiration.

Steve Jobs quit college to pursue his dreams. While I don't recommend that people quit their studies or jobs on a whim, I certainly believe that if somebody doesn't feel they are following a life path or career path that leads to fulfilment, then changing course is critical, even if it is risky and frowned upon by others.

This encourages me to question the norms of my profession, and to try new approaches, even in the face of discouragement by others. My career passions are writing, software design and teaching. Yet a professor of computer science is boxed in by narrow criteria of how they should publish. A former Dean even told me that I should not be developing software since, that did not constitute research.

I have spent a lot of time on educational research, even though that is looked at by many others as a second-tier research topic.

Recently I have made a decision change the way I do research, even though this means fewer papers and may cost me future grants. I have a passion for what I believe is the future of software development – model-oriented programming. And I want to develop Umple as an example of this and a vehicle for exploring ideas in that domain. To do that I have to put personal effort into actually doing software engineering (including model-oriented programming itself), which takes time away from writing papers. I also have to require the same of my graduate students and have to be fastidious about software qualities such as usability, and other matters that many researchers would say should not be my concern.

So may Jobs rest in peace, and may he serve as an inspiration to help people like me who don't want to have to slavishly follow the norms of their profession and instead to follow their passions.

Umple tutorial 3: Mixins

This is the third series of Umple tutorial posts on my blog. The first two were about 1) basic attributes and associations, and 2) state machines. In this post I introduce the concept of Umple mixins.

A mixin, a concept popularized in the Ada language, but now available also in languages such as Ruby, allows bits of code to be incorporated into other programming elements.

Let us imagine the following Umple code that you put in file1.ump:

// Contents of file1.ump

class X {

  singleton;

  lazy name;

}

class Y {

  Integer id;

}

This could be a small self-contained system with two unconnected classes. However let us imagine that you also created the following Umple code in file2.ump:

// Contents of file2.ump

use file1.ump;

class X {

   Date dueDate;

}

association {1 X -- * Y;}

If you compile file1.ump and file2.ump together, the result is that class X now contains two attributes, name and id.  Furthermore there is also an association between classes X and Y. The second declaration is class X is not redefining the class, it is adding to the class.

It wasn't necessary to put the above code snippets in separate files. Any time Umple encounters class X { ... } it will incrementally add the contents of the curly brackets to class X.

This can be useful to allow you to keep the 'pure' class diagram part of the model separate from the methods that belong in each class. In Umple you always have a choice: keep these elements together, or keep them separate.

Another use of mixins is to create various versions of a product line that have different features. So for example if we have the following code:

// Contents of file3.ump

class X {

   Time dueTime;

}

association {0..1 X -- 1..* Y;}

One product could be built using file1.ump + file2.ump and another, slightly different product could be built using file1.ump + file3.ump.

Incidentally. This is not the only way to create variants in Umple. Another concept is VML4Umple. I will provide a tutorial for that at a later date. For the eager, you can look at Jenya Levin's masters thesis.

Note that class X is declared to be a singleton. This means that code will be generated following the standard "Gang of Four" singleton pattern. Umple has several features that help implement patterns, and more are planned as Umple is developed further.

Paper about teaching with Umple was very well received at CSEE&T

I presented Umple on two occasions during CSEE&T. The first was in ASEE&T, an academy for professors who would like to learn to teach software engineering. My slides are here (or in pdf).

The second was a paper session in which I presented the following paper:

Lethbridge, T., Mussbacher, G, Forward, A. and Badreddin, O, (2011) “Teaching UML Using Umple: Applying Model-Oriented Programming in the Classroom”, CSEE&T 2011, pp. 421-428. My slides for that paper presentation are here:

Here are some of my observations about teaching with Umple, taken verbatim from the paper:

• It proved faster than writing on the board to create diagrams, with its textual mode being subjectively at least twice as fast as writing on the board, and the mouse-and-icon diagram entry mode being about 25% faster than writing on the board.
• The ability to call up diagrams from a list of example files and then edit them was something that could not be accomplished readily in PowerPoint nor on the board.
• When designing interactively, the ability to rearrange a diagram was extremely helpful, and much faster than erasing part of a diagram drawn on the board.
• The ability to show several alternative designs for the same problem proved very useful. This ability just requires pasting Umple text or loading pre-defined Umple examples.
• The ability to take an existing Java program and convert it into a model live in front of students showed them that their programming skills can directly connect to their new modeling skills. This is also something that cannot be done with other UML tools.
• The ability to generate and run good-quality code instantly helped students see that modeling is not just about pretty pictures. Doing this helped show them in concrete terms what it means to, for example, change a multiplicity or add an event to a state machine.
• Since UmpleOnline requires only a browser, it can be instantly invoked in any lecture when needed. Furthermore, students can take the same examples and instantly use them on their own laptops, which many now have in the classroom.

Here are some of the results of a survey of students using Umple, The diagram should speak for itself: Students liked Umple.

In addition, the paper showed that final exam grades on UML modeling questions improved by 9.4% in the years since I introduced teaching with Umple. The results were highly statistically significant.

Many attendees at CSEE&T told me they would like to use Umple or a tool like it, and that I seemed to have made a significant advance in helping students understand UML.