@Martin,

While I do find UML to be useful under certain circumstances (Use Case diagram on a whiteboard was VERY helpful in a business process discussion recently, etc), I think calling a UML diagram an executable spec is far too stretched to be anywhere near reality.

A UML diagram is no more executable than an MS-Word document or code written on a white board with a marker. Yes, they are useful tools. No, you can’t execute them to verify that the actual code you wrote meets that specification. A human reading a diagram or document is not execution – it’s communication of the specification, or intent of the specification, into a human’s mind for the purpose of education and understanding.

That doesn’t mean you shouldn’t use those tools to write human readable specifications, though. It only means that they are not executable specifications that can be used to define, measure, and test your working code.

My personal experience with UML is it’s difficult to specify behavior at a level low enough to generate useful code, and using a UML tool to specify properties and data types (string firstName, string lastName) is usually slower than coding them by hand.

High level design tools abstracting code has been a “holy grail” of sorts in the fact it promises a lot of time savings, but I haven’t seen anything introduced that’s really delivered a measurable increase in productivity. I’d love to hear more about the certain circumstances when you’ve found UML tools useful for creating code.

I think the idea of Tests as Specs is dead on. Unfortunately, I don’t think that message comes across well when the subject is unit tests in general. I’ve worked with lots of devs who see unit tests as back-end testing, not front-end QA. And they find back-end testing tedious, and would rather leave it to the testers.

Of course, I wouldn’t be The UML Guy if I didn’t mention the role of UML and other design notations in specifications. Good unit tests are automated validation of the soluition; but with a good UML tool and some expertise, you can automate the creation of the solution, or at least parts of it. I know many people think this doesn’t work; but my experience is that it can and does work in certain circumstances. And with tools like Windows Workflow and others, this approach is spreading. When you define the validation as tests, when you’re done defining, you can immediately validate without any translation. In a similar sense, when you define your functionality through diagrams with direct participation of non-dev stakeholders, you get a very precise definition; and then that definition automatically executes without any translation. The design notation is comprehensible across teams, so you get a much wider set of eyes looking for problems.

Of course, the executable designs commonly have lower boundaries, beneath which you have to create detail code to do specific functions found within the larger design. Over time, though, you can build up libraries of reusable lower level functions. (Windows Workflow excels at this.) And conveniently enough, those lower-level functions are VERY well suited to validation via unit tests. So there’s a good complement there between implementation by design and validation by test.