From: Scott Woods (scottw_at_[hidden])
Date: 2003-06-08 21:30:33
> I don't know what part in the UML specs you're referring to (I don't
> know UML apart from class diagrams and state charts). A quick search did
> reveal much apart from protocol state machines which AFAICT don't have
> anything to do with FSM interaction.
Confusion is (again ;-) my fault. I will try to do better this time round.
I was back-predaling on the different capabilities of SDL and UML with
to their potential to deal with the issue of "free-protocols" (in the manner
functions). After reading;
I felt it was unreasonable to make the broad statements I had made
about UML's (or SDL's) inability to treat protocols as substantive. While
document above is not part of the UML specification it is obviously quality
work that applies UML to the modeling of protocols.
It isnt a built-in facility of UML and their model for protocols (and
ports and connectors) was not what I had envisaged. But it seemed to be a
successful modeling and I had to concede; why should a "niche" concept such
as "protocols" foul the "global namespace" of a generic modeling language?
> SDL defines channels, gates and connections which sort of define a
> To me, these primitives are only necessary to *document* which FSM is
> talking to which other FSM. There's little semantics behind them. Maybe
> seeing this too easy but I think in C++ all you need for inter-FSM
> communication is:
Yes. Agree with significance/usefulness of channels, gates and connections.
this is part of why I consider SDL (& UML) "weak" in their "out-of-the-box"
to specify FSM interaction (i.e. protocols).
> 1. Events that can carry parameters
> 2. A call-back mechanism a la boost::function, so that an FSM that is
> answering a request does not have to know who it is answering to.
> boost::intrusive_ptr< Request > pRequest = new Request();
> // set params
> A & machine = context< A >();
> pRequest->callback = boost::bind( &A::queue_event, machine, _1 );
> B::instance().queue_event( pRequest );
> So, IMO there's no need for boost::fsm to provide communication protocol
> primitives, because their functionality is pretty orthogonal to what my
> library does. Users would want to use what they're accustomed to. Most
> presumably use boost::function.
Yes. Think with 1, 2 and putting distance between boost::fsm and comms
you have nailed something for me. Maybe there will eventually be a
thats somewhat overused) or boost::eventing (sounds like a horse race) that
complement your current targets?
Of course, this does not directly meet the requirements I have (so badly)
articulated but it does not preclude related work in the future (I'm
decades). I suspect that some of my inability to define a "protocol" (a
of events) is related to different apparent areas of work; i.e. real-time
distributed message processing, e.g. FTP or IMAP4. A significant difference
that the former is less likely to involve well-defined sets of messages that
re-used from one project to the next (or even surfacing in several parts of
I feel responsible for something of a detour into the subject of SDL and the
comparison of UML with SDL. I hope that this detour has uncovered something
use for you (certainly has for me) but really exactly where these languages
are going and their relative advantages are secondary to getting your
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk