Object Lifecycles as State Machines in Heron
One of my favourite features of the upcoming Heron 2.0 is the introduction of “states”. A state refers to a stage in an object’s lifecycle (perhaps stage or step would be a better name to avoid confusion). Whenever a signal (i.e. message)Â is recieved by an object (not to be confused with operations which correspond to plain old member functions) the object transitions to a new state. Each state has an entry procedure which is executed upon receipt of the signal, and a transition table which shows what signals map to what states.Â
All of this happens asynchronously, and makes it easier for software to be executed on concurrent systems, without exposing the nasty details of multi-threaded programming to the programmer. Thank god, because I suck at writing multi-threaded code. Don’t laugh, most people suck at multi-threaded code more than they realize. Almost all non-trivial multi-threaded code falls into at least one of the following categories:
- doesn’t scale
- is broken (try a true multi-processor machine)
- is inefficient
- is unmaintainable
To realize the truth of this, consider how much of the progress on C++ in the last 10 years has been discovering new ways that multi-threaded code doesn’t play well with it. Anyway, I’m ranting now.
The state machine approach in Heron is basically a direct implementation of the idea of using state machines to model an object’s lifecycle as described in Executable UML: A Foundation for Model Driven Architecture by Mellor and Balcer. Heron is motivated by my desire to represent the concepts of xUML in a programming language, so that we can move back and forth freely between UML diagrams and source code. I feel this is key for gaining widespread support for MDA.
On the subject of state-charts and state-machines, my friend Frank Krueger pointed me to the following links:
Tim Sweeney’s implementation of States in his language “UnrealScript”:
http://unreal.epicgames.com/UnrealScript.htm#States
David Harel’s Statechart work:
http://citeseer.ist.psu.edu/harel87statecharts.html
–Â
To this I’ll add:
[169] Yuri Gurevich, Benjamin Rossman and Wolfram Schulte
Semantic Essence of AsmL
Theoretical Computer Science
Volume 343, issue 3, 17 October 2005, pages 370-412
Originally published as Microsoft Research TR-2004-27, March 2004
The Abstract State Machine Language, AsmL, is a novel executable specification language based on the theory of Abstract State Machines. AsmL is object-oriented, provides high-level mathematical data-structures, and is built around the notion of synchronous updates and finite choice. AsmL is fully integrated into the .NET framework and Microsoft development tools. In this paper, we explain the design rationale of AsmL and provide static and dynamic semantics for a kernel of the language.