> --------------------------- > event <-> signal > reaction <-> input > guard(ed reaction) <-> constrained input > junction point/choice point <-> decision > entry action <-> initialisation > exit action <-> finalisation > state with two or more orthogonal regions <-> state aggregation > inner state <-> composite state > terminator <-> stop state
awesome. > > The remaining concepts (transition, deferral) have the same names in both > languages. > Interestingly, SDL also defines exception handlers (supported by > boost::fsm), which UML lacks completely. yes. not sure whether thats a plus for SDL or UML ;-) > > Moreover, SDL specifies block and process agents, which are not supported by > UML and my library but could be implemented on top of it. > > I therefore think that boost::fsm could be useful for domains where behavior > is specified with SDL. absolutely! reading your summary (of UML/SDL comparison) has been interesting. for me it has exposed the fact that some concepts are "missing" from both UML and SDL (hope those folks aren't listening to this ;-). to some extent i have fooled myself that SDL is "better directed" at specification of communities of FSMs. at a language level you have shown that they are in fact very similar (not totally). to some degree its probably historical that SDL has been adopted by telecoms (large distributed communities of FSMs) and UML has been adopted by the "desktop-software" community (i use an extreme term to make a point only). so maybe my misconception is related to the typical application of SDL and the tools that have been developed around the standard. check out; http://www.telelogic.com/products/additional/objectgeode/index.cfm this is a product i used a few years ago. its a pretty complete "implementation" of SDL - you draw SDL, push a button and it generates the target system in C (that's what the brochures say ;-). it is very much targeted at large communities of FSMs. the sort of thing that i queried a while ago (and i think related to what chris was asking) was; "where is the [separate] definition of the protocols"? right or wrong i believe that FSMs interact through sending of signals (presentation of events?). this interaction is a protocol and a protocol has its own "existence" - it is not owned by the FSMs. neither UML or SDL highlights this. using SDL i was certainly able to implement protocols but it would have been a royal pain to uplift that "protocol" and reuse it in another project. understand your current targets and look forward to review (and acceptance ;-). if you still have some energy left over after all of that, i might mention the protocol thing again. but only if your begging for more punishment. > How is that code usually implemented? Are there SDL code generators and/or > widely used libraries or do people normally handcraft such systems? usually? i would say using "handcrafted" state-machine code. there are a bunch of SDL tools but only a few generators and none of these were cheap (think 10s of thousands) around the time i knew about such things. telcos have large budgets for implementation of signaling systems and the vendors price accordingly ;-) hope that was lucid and thanks, scott _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
