Disclaimer, and Some Links

I work for Gorilla Logic (http://www.gorillalogic.com).  I joined the company back in August 2008 because I wanted to work on and with the company's "Gorilla Execution Engine", recently open-sourced at http://code.google.com/p/opengxe.  It executes state processes, static class diagrams, and use cases, and is the best example of what I'm trying for as I have seen to date. I think I'm objective about the GXE; feel free to call me on it.

I started the Exec Design project on sourceforge (http://execdesign.sourceforge.net) some time ago to work on the same set of problems the GXE solves.  Some work is still going on there, as we have a lot of ideas to try out, and that seems like as good a place as any.

The obvious starting place for executable designs in UML are the behavioral models: interaction diagrams (sequence, collaboration), activity diagrams, and state charts.  Oddly, I've not seen anything which executes interactions or activity diagrams.  There are, however, lots of state machines available in open source.  All the ones I’ve played with merely execute user code, which is exactly how executable design should work: the designer provides the framework, but coders still write the detailed code.  This approach (especially if your state machine can execute the UML state process diagram directly) is exactly what I mean by executable design.  Coders still code; we don’t create a new language and expect designers to use it to fully specify the final system, but we do fully leverage designers’ work in UML.

My first state machine (http://execdesign.sourceforge.org) implementation requires developers to implement specific interfaces to specify guards, actions, triggers, etc.  This approach is too restrictive.  We want the tools to be able to do this, yes, but it should be part of the design, not a limitation of the state machine itself.  I implemented it that way to force developers to separate these things in code, but I hadn't thought through the problems it introduces, and I wouldn't do it that way now.

There’s a state machine which runs Argo UML state diagrams directly (http://unimod.sourceforge.net); I haven’t had time to look into the tool yet, but a cursory look at their web site indicates it may be an interesting project.

The GXE state machine is quite powerful, but I haven't worked with it enough to provide a good review, so I'm going to postpone that for the weekend update.

Given what I said last Sunday about executable designs, here are some characteristics I think an "executable design" engine or suite should have:

• Developers can extend the model in a natural way.  For example, if the design specifies a method on a class, the developer just creates the appropriate class file and codes the method.  The execution engine melds the class in the model and the class as coded according to appropriate rules.
• The model constrains the design.
• The engine supports a widely-understood modeling language.
• Code generation is an invisible part of using the engine, if it must be done at all.
• The execution engine should be "invisible"--that is, it shouldn't take a whole lot of scaffolding in every modeled object to use it. Both the GXE and most state machines I've used are great examples of this; you start up the execution engine, and it "just runs" your model.

Well, that's a starting point, anyway. I haven't tried hard to boil these down or determine completeness yet, but I will over the next couple of weeks.

On code generation: I have seen some very powerful code generation systems.  There are two problems with code generation, though: 1) the generated code is usually pretty ugly, and 2) the design is distorted by the need for developers implementing the design to work "with" the code generator.  This is an example of a highly-visible execution engine, so perhaps my last wo bullets are really saying the same thing.

Several people have pointed me at some niche products in this space as well; I'll look at some of those tools over the next few weeks as well.