Why Models Shouldn’t Be Programs

Here's a great post on "why models shouldn't replace programs":

http://thedailywtf.com/Articles/The_Customer-Friendly_System.aspx

Look–Model Driven Architecture is pretty much ignored by practitioners.  In practice, really interesting problems modeled in detail result in models which are as daunting as those in the link above’s example.  The problem is, modeling is to clarify, not to replace, programming. Models must leave out lots of detail to be useful. This is almost the first thing Booch, Rumbaugh, and Jacobson say in "The Unified Modeling Language User Guide"--in my copy, page 6, in italics, in the center of the page: "A model is a simplification of reality", followed by (again, centered and in italics): "We build models so that we can better understand the system we are developing".  If the model becomes so large and complex that it doesn't meet that goal, I submit it has failed.

So: I believe executable design tools must (a) execute the model faithfully, but (b) integrate nicely with existing languages for the detailed work.  Nobody wants to maintain a set of generated classes in synch with a model, and the model should be the application’s core.  It must not try to be the application!

More Exec Design tools

I'm a fan of even partial solutions to the executable design problem. Here is are a couple I find particularly interesting.

DataXtend

http://www.progress.com/dataxtend/index.ssp

I had the opportunity to run a 1-week in-house live test of DataXtend. We took a bit of design from a set of web services we had delivered using Apache Axis and a lot of back-end Java code, and gave a design spec and the original interface specs to the DataXtend team. They showed up in our office on Monday and we did a little work on reviewing their capabilities. On Tuesday, we started working on the project, which had taken our offshore development team 6 weeks to develop (admittedly, that's way longer than it should have taken, partly due to continuous changes in the requirements, and partly due to just poor development management). By late Tuesday afternoon, we had a working web service. I load tested it; I threw bad input data at it, and I deployed it in several different environments, and it just worked.

We ended the 1-week demo in 3 days.

This tool is a slick as it gets. You import your interface design, expressed in XMI or as a schema or whatever (there are lots of options), you map it to your data sources, again specified as XMI or schema or whatever, and push the button. You get a working web service in a nicely packaged deployable file, with very little, if any, coding.

This isn't executable design--but it leverages the design very directly and very easily. You simply import the interface, and import the source services and/or data, and map one to the other. It's state-based implementation at its slickest. It's expensive, but it's a whole lot less expensive than a fleet of Java coders. We figured we could replace 6 developers and 2 leads with 1 lead and this tool. Nice.

MQArchitect

http://www.mqsystems.com/MQS-Solutions.html#mqarchitect

I haven't actually had a chance to use this tool, because I no longer have access to a large MQ installation. I have, however, been tasked with architecture in a large, fast MQ environment, and boy, oh boy, do I wish I'd had a chance to play with it. I did download the demo and tried it, and as far as I can tell without actually pushing 100k transactions/hour through it, it really works.

The basic idea is that you design your queue environment using some templates in Visio, and then you generate your whole system from that drawing. MQ is a pretty simple tool at the core, but there is a lot of connection and configuration data, and you have to get it right, or your nice fault-tolerant system fails badly, and worse, quietly. Fortunately for me, I had a couple of MQ wizards configuring my back end for me, but if you don't (and most of us don't), this may well be the right tool for a designer trying to keep track of a complex MQ system. Check it out.

If you have a tool I should look at, please drop me a line. I'm jdandrews on Twitter, and you can email me at jerry.andrews at gorillalogic dot com.

Abstraction

A design must an abstraction. A design constrains and informs an implementation. It allows developers to focus their creativity on a smaller set of problems. In fact, the whole point of the architecture/design/coding division of labor is to allow creativity and problem-solving to be applied on a small set of problems--problems which one individual can get their head around and thereby have a reasonable chance of solving. If you lose the ability to abstract by forcing the whole application into a single model, you have lost something important--you have, essentially, "jumped to code" before you understood the problem.

The problem with abstraction is that, without at least one working example, it's hard to tell if the abstraction makes sense. (Two good friends of mine are fond of saying "all abstraction is good, as long as it's your abstraction.) In new development, then, the ideas behind an executable design clearly have a place; they're a way to validate the abstraction actually does what it says it does.

As Bill Glover pointed out in his comment on an earlier post, applications get complex and crufty with time. He asks (with regard to reverse-engineering an existing implementation): "What will keep the design from being obscured by the kind of detail that starts showing up then? ... An example would be all of the methods and attributes that developers add to a class that aren't really relevant to the high level design, but are needed to make the class really do it's job."

What Bill's talking about, I think, is the very real and common case where you're trying to bring order to an existing application by describing its existing design. If, for example, you have a tool which can execute class diagrams (e.g. the GXE), how do you use that serve as an "armature" for the rest of the implementation?

If you just want to verify that the design and the implementation match, you're not in executable design space--you're in static code analysis space. There are tools for that (e.g. http://www.ndepend.com/). If you want an executable design to be an armature for the application to be built on, then you're really refactoring. The trick here is to allow the tool to replace some part of the application's existing functionality without a complete rewrite. Here are two example behaviors I think a tool might implement which would allow them to operate in an existing application, replacing part of that application.

I once introduced a state machine into an application which had significant business logic embedded in its screen navigation subsystem. I rewrote the navigation for just one screen, pulling out the business logic into separate classes for each business rule, and describing the screen-to-screen navigation in a state diagram. The state machine responded to user events (e.g. button clicks), queried the new business logic classes to get guard results, and handled transitions within and off of the one screen. Clearly, this approach can be extended to other screens without disrupting the application as a whole (and in fact, the development team for that product is doing just that).

I'm currently working on a project which is using an executable design tool (the Gorilla Execution Engine) to validate requirements. Classes representing domain concepts and relationships are executed in the GXE to see if the very complex calculations modeled by those classes give the "right results". In my ideal world, we'd then take that domain model, specialize it (that is, turn it into a design model), and it would enforce class behavior in the finished product. I might reverse engineer a dozen classes which participate in a given calculation, remove or hide the methods which aren't germaine to that calculation, then add new methods from the domain model to flesh things out. I might remove irrelevant methods from the model entirely. The execution tool would provide a class loader which would:

1. load the design model,
2. upon a class load request, it would search the model for a definition of the requested class,
3. look for any class implementations of the same class,
4. compare the two, merging them if the the implementation does not contradict the design model, and complaining loudly if it is not (this step could actually be done at build time rather than runtime), then
5. load the merged class for execution.

An approach like this would allow the designer and developer (sometimes the same person, right?) to work together to decide what portions of the existing application could be replaced with an executing design. This would address a problem I see a lot, where the code can't actually be traced back to any requirements or higher-level design. By forcing the code to match the design in order for it to run, the design gets updated because it's the best way to get the build to work.

Of course, developers could always decide they don't want to execute the design, but they always have that power. I'm assuming that designers and developers are working together to build something; if they're not, the organization has issues no tool can address.

The Role of the Executable Design

Stu Stern (http://stu-stern.blogspot.com) raised the question: "What would the executing design itself provide?" That's a big question, and I wanted to think about it in a longer context than "comments".

One role of an executing design is to verify the design.  Recalling the original motivating idea: an executable design which actually does what you say it does validates the design--it gives you a way to be sure that what you're handing to coders is actually going to be useful to them, and is going to work as envisioned.  I think this is hugely important--even if you can't ever use the executing design in the finished product, you get strong assurance that you're not going to start building something which won't work. Remember that mistakes in design cost a lot less to correct than mistakes in code--so spending a little on tools and time in design is quite likely to save money downstream--in coding, deployment, and operations.

In the design verification role, execution tools must then carry all kinds of simulation capabilities. In complex problem domains, they must be able to handle very complex class definitions and interactions.  In large systems, they must be able to simulate network latencies, distributed transaction failures, large loads, and similar system events. In short, in an executable design suite, this would be a different set of tools than those which might use the executing design as a framework for a finished product.

A second role is to constrain and inform the design.  Almost everywhere I work, designs are assembled in linear fashion as design documents (there's a good article, somewhat tangential to this discussion, in the January 2009 issue of Communications of the ACM: the "Ontology of Paper": http://mags.acm.org/communications/200901/?pg=26. The author argues that paper design documents are an idea whose time has passed.)  Design fragments expressed in UML are exported from the design tool as images and pasted into the document.  The whole thing is handed off to implementers for coding. These folks proceed to translate those diagrams and associated text into classes and subsystems and packaging.  When the design changes (as it inevitably must, when requirements become better understood and original design approaches don't pan out as expected), the loop is seldom closed by updating the design.  When the application moves to maintenance, the coupling between requirements and implementation quickly becomes hard or impossible to discern. Maintenance costs much more than it should, as new designers and developers spent far more time than necessary trying to understand what's there so they can update it intelligently.  The problem is exacerbated in agile projects, which are, effectively, in maintenance from the first day a new programmer joins the development team or a key one leaves.

If the design itself formed a key part of the finished deliverable--it's skeleton--then the design would always be in sync with the deliverable, and the extra step of translating what has already been built in design space into code space would be skipped.  What a boon for developers, designers, and maintainers!

A third role might be to constrain the implementation--to complain if the implementation diverges too far from the design.  I'm not sure how this would work, though I have some ideas, which I'll flesh out in future posts.

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.

Executable Design

When I first “noticed” architecture, I found it pretty much irrelevant.  At that time, designers generally talked rather than drew, or they drew flowcharts. Design documents were either 1000-page tomes or they didn’t exist at all. The architect with whom I worked generated block diagrams at such a high level they weren’t useful to me at all, or worse, they were misleading, because the actual system didn’t match the architecture in anything but name.

At some point, I finally started saying “architecture must be executable.” At the time, I meant that a designer/developer should be able to take an architectural description, code to it, and though it would be a skeleton, it should execute.  It should be possible to mock all the key system functions using nothing but the architectural description.

If feel the same way about design: if you can’t use the design as an actual blueprint, it isn’t a design–it’s a concept.  Concepts are good, but they must be refined into architecture and designs.  That’s what designers and architects get paid to do.  It’s hard work.  It’s boring sometimes. And it’s very very difficult to do well, which is why there are so few good designers, and even fewer architects.

I'm trained as a nuclear engineer, and I worked in power plants as such for 15 years before moving to software development full-time. Power engineers would laugh at what usually passes for a software design.  When you design a building, you aren’t done until you can predict the construction cost and schedule to within 5%.  Same thing goes for an engine, or a CD player, or chemical dye. In other industries, you’re working with real materials, which cost a lot, and whole teams of people, who also cost a lot.  You can’t do most of the work yourself, so you must explain exactly what you want done.

The same thing is true of large software projects (agile ones included--I'll get to that in future postings).

As software developers, designers, and architects, we have a huge advantage over engineers: our cost of implementation is very low. As a result, sometimes it really is cheaper just to throw code at the wall and see what sticks.  In medium and large projects, though, it is seldom the case that this approach will work more than occasionally. As a result, we build design documents.  Designers and architects make UML descriptions (hey!  we have our own design language!) and associated text, which we then hand to developers to turn into code.

Which is incredibly wasteful (and now I’m getting to the point).

UML is a succinct, precise way to specify a design.  Why do we have to translate it into code to get it to execute?  Wouldn’t it be a great test of a design if you could run it before you lobbed it at developers to flesh out?  I’m not talking about code generation here; I’m talking about directly executing the design components to see how they work together.

The model-driven architecture (MDA) folks are running down that idea.  I’m not sure I like where they’re going with it, though. I do not think it’s a good idea to turn designs into complete applications. Designs are abstractions, and the whole point of that abstraction, and the ability to separate architecture, design, and development, is to allow people to think at different levels of detail, so they have the capacity to grok the whole application.  Divide and conquer. I do think, though, that recoding the design from UML into some other language is wasteful. Wouldn’t it be a lot more productive to give developers an executing design and let them flesh out the details in their language of choice?

The rise of virtual machines–Java and .NET specifically, but I’m sure there are others–makes me think we can build executable designs, and code to them rather than recoding them. I’m currently working on “how”. I’d like to know what you think of the idea.