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.com<mailto: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<mailto: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<mailto: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 https://groups.google.com/d/optout.
