Great thanks
You should definitely read Miro Samek's Practical UML Statecharts in C/C++:
Event-Driven Programming for Embedded Systems
That sounds great, I’ll take a look.
while not really adhering to some aspects of Harel/UML semantics, I've found
Yakindu Statecharts to be quite usable,
but then you'll end up with code generation, which is apparently not what you
want.
I can live with code gen I guess. I’d just have preffered something more
dynamic. However given the complexity to implement I may have to start off with
what I can find.
If you are thinking of implementing a purely textual DSL for hierarchical
statecharts, I think it will not work.
As much as I love text-only specfications, for nested state charts it will
probably not be very nice
I think you may be right there. I originally just wanted simple FSM support but
I’m concerned about the state-explosion issues as we try to model more complex
processes hence looking at Harel state machines.
Thanks again. I’ll take a look for the book now.
From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On Behalf Of
pmf
Sent: 05 September 2014 10:34
To: clojure@googlegroups.com
Subject: Re: Clojure statechart / hierarchical FSM implementation
On Friday, September 5, 2014 9:13:43 AM UTC+2, Andre Van Der Merwe wrote:
Alternatively are there any papers or examples that you know of that discuss
implementing statecharts? Most of the ones I’ve seen are code-gen tools and
that does not really what I am after.
You should definitely read Miro Samek's Practical UML Statecharts in C/C++:
Event-Driven Programming for Embedded Systems (don't be put off by the fact
that this is for C and embedded systems; the book is a walk through through the
implementation details of the author's commercial statechart framework which
contains a lot of details that one would never think of beforehand).
It's the best resource on hierarchical statecharts (most of the others don't go
into detail of shallow/deep history and the intricate details of the order of
entry/exit actions when nesting is used).
As for tooling, while not really adhering to some aspects of Harel/UML
semantics, I've found Yakindu Statecharts to be quite usable, but then you'll
end up with code generation, which is apparently not what you want.
If you are thinking of implementing a purely textual DSL for hierarchical
statecharts, I think it will not work. As much as I love text-only
specfications, for nested state charts it will probably not be very nice.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
clojure@googlegroups.commailto:clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.commailto:clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
clojure+unsubscr...@googlegroups.commailto:clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Information contained in this e-mail, including attachments and any rights
hereto are the property of Portfolio Prospecting and Performance (Pty) Ltd
(unless the context clearly indicates otherwise). It is confidential, private
and intended for the addressee only and should you not be the addressee and
receive it by mistake, kindly notify the sender and delete this information
immediately without further disclosure to any other party. Save for bona fide
views of Portfolio Prospecting and Performance (Pty) Ltd, views and opinions
expressed in this e-mail are those of the sender only. Portfolio Prospecting
and Performance (Pty) Ltd accepts no liability whatsoever for any loss or
damages incurred, or suffered, arising from the use the information in this
e-mail. Portfolio Prospecting and Performance (Pty) Ltd does not warrant the
integrity of this e-mail nor that it is free of errors, viruses, interception
or interference
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
Clojure group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit
