State Machines and Ace
State Machines part four
A couple weeks ago John mentioned that Craig Larman is one of his favorite authors. A link on Larman's site caught my eye: James Gosling has been working on the Ace project. No particular reason for that to get my attention, but it did. Trusting intuition I followed the link. After lots of effusive hype about how Ace is going to make programming easier (and maybe wash your dishes too :), the page briefly explains the how of it:
The key to the Ace technology is its mechanism for application specification. This Ace specification has been formulated to capture the precise and complete intent of the desired application while simultaneously excluding or hiding all of the possible implementation details.
I quote that paragraph mostly because it highlights that this is "the key to the Ace technology" and because hiding implementation details sounds remarkably similar to my description of Bob Martin's state machine compiler. The quote goes on:
The first half of an Ace specification is a description of the data which the application will manipulate, that is, its set of business objects. These business objects and their relationships are represented visually in a diagram. ...
The second half of an Ace specification is a description of how the application will manipulate that data, that is, its business process tasks. These business process tasks and their sequencing are represented visually in another diagram.
The business process diagram for the PurchaseOrder application is an unmistakable state transition diagram.
Given all the state machines on my brain I had to take a closer look. Sun Labs Ace Project has a more technical spin. Have a look at this Ace example code for an Application Usage Specification and compare that with Bob Martin's state machine compiler configuration.