Big state machines

[Ulf Wiger]

Den 2005-04-19 11:29:55 skrev Thomas Lindgren <thomasl_erlang@REDACTED>:

>
> --- "Ulf Wiger (AL/EAB)" <ulf.wiger@REDACTED>
> wrote:
>
>>
>> I have another version, as a matter of fact, which
>> is much
>> closer to gen_fsm. It solves the dreaded complexity
>> explosion
>> problem, /.../
>
> Interesting. Do you have any opinions on Harel's
> statecharts? (A precursor of UML, I believe, though I
> haven't studied UML very deeply.)

A quick look gave me the impression that Harel's statecharts
were the precursor of concurrent sub-states in UML.

Interestingly, UML offers both "deferrable events" and
concurrent states, but the specification notes that they
do not fit very well together. Even though it is possible
to reason about what happens when an event that is marked
deferrable matches some triggers while failing others in
a set of concurrent sub-states, it is by no means obvious.

I will not take the time to look up the section in the UML
spec that mentions this. It is simply too cumbersome.

I believe the recommendation is: use one or the other, but
not both at the same time. My guess is: if your state machine
has any notion of time, and the ordering of messages in the
central message queue can pose a problem - stay away from
concurrent sub-states.

This also seems to be the general gist of
http://www.benmeadowcroft.com/reports/statechart/
It describes Harel statecharts as directed towards what
goes on inside a state machine, while CSP is a better
model for dealing with real-time systems, since it has
a notion of time, and deals with the external interface of
a process.

Now, with Erlang, if you need Harel statecharts to describe
the inner workings of a process, you should rather split
it into several processes, and use CSP-like modeling
instead. Think 2-port and 4-port equivalents, if you
happen to be an EE major. Black boxes - specify what
goes in and out of the box.

My two cents after five minutes of googling on Harel.
Please correct me if I got it all backwards.

/Uffe