Real paper

Every now and then I get an urge to update a graphical editor I've had kicking around my drives for years, and sometimes start working on it again (actually most times I end up with a 99% re-write). Currently the working title is 'System Engineer's Sketch Pad', or 'SystemESP' for short.

Thing is, most of the notations I scribble in my sketch pad (A4 hardcover 150gsm acid free cartridge paper) aren't formal or semiformal things like Concept Graphs or UML, but are simple box-and-line graphs with locally defined semantics.

It's very hard to write a GUI that's as usable as paper, and very hard to find use cases that require machine capture of early design drafts. As I've got sketch pads going back over a decade (and occasionally refer to them), and the paper is acid free, but don't have any files that old, I'd also be worried about putting anything into a machine unless I had a very big gain that would outweigh the risk of information loss.

But it's fun tinkering with UML tools.

Hmm.

Maybe that explains a bit of the problems with the software industry. Everything seems to be going into two camps- the agile camp and the MDA camp.

The MDA have prettier tools, the Agile say make it work on paper.

So how about agile tools? The notation I was sketching with earlier was to do with the parser:

each box denotes a parser state.
if the box is to the right of another box, it means that box indicates the next state, which is chosen when the.
above or below indicate options. options shifted to the right are not chosen as often as those to the left

In the time it's taken to blog an example, I've almost written the CLCE specification for the notation, and I didn't even mean to.

That might be a better way to go than a 1200 page UML spec.


TME