Sequence diagrams and Multicast

[frankk]

Is there a standard method of indicating a multicast message in a sequence diagram?

[sargasso]

I think you'd better explain what you mean by multicast.

Every lifeline in a seq diagram is an instance.  Ergo(?) multicast is a difficult concept to grasp.

hth
bruce

[MrDX]

I think, he mean messages to more than one lifeline at once (send message A to B, C, E (not to D) ).
I have also searched for somethink like this, but (as far as I know) there is no feature in the UML specification for this :-(

[frankk]

Multicast is basically a broadcast, but to specific, multiple instances. I was wondering if there's a more concise way to indicate this than just drawing a bunch of separate messages.

[bonzo5]

Event Studio v4 (www.eventhelix.com) does a marvelous job of showing multi-casting.  I use it all of the time to show network-type messaging, such as tactical data links, where broadcast mode is the appropriate paradigm, rather than the "simultaneous" point-to-point representation that is normally presented.  Another plus is that EventStudio automatically generates the diagrams (Sequence and Communication) from a structured text file (Feature Description Language or FDL).  We create this file from CSV exports from systems engineering tools, convert them into FDL with a python script, then open the FDL file with EventStudio.  Outstanding tool and outstanding support from EventHelix.  Hope this helps you out--no one tool does everything, so we always try to at least get them working together in an architecture development environment.  So, EA is used where it fits and EventStudio is used, along with other SE tools, where it fits (great for showing system behavior to stakeholders).

[sargasso]

Every time I have become stuck in this situation I have to look at what it is I am trying to solve.  It always has come down to two different scenarios, I'm either trying to model what an undefined or semi defined set of instances will do when the braodcast is transmitted, or trying to model what the "infrastructure" is going to do to successfully broadcast the message.

In other words, in the first case "hey here's a situation where (according to my resposibilities) all I have to do is send a message to a bunch of objects that I don't necessarily know or care about.  It's their job to accept or ignore the message.  In those cases I just model each of those objects in a separate diagram using a "found message" and describe how they will handle the incoming.  I hae not yet found a way of describing, in a single diagram what all of them are going to do or not do.

In the second case, again, I don't necessarily care about what or how the recievers are going to do about the message.  Just that their is a way to "get it out there".  Here, I am more concerned about the sender and from the point of view of the recipients, ... it just doesn't matter.  Or at least it doesn't matter to this aspect of the model.

You may argue about the cases where the sender is expecting or needs one or more responses to the broadcast.  It's a bit  like sending a bulletin board message " Hey, its my birthday, you can send my presents to ..."  Yet again these always break down to modelling what each instance of the reciver types are going to do or to modelling the mechanism of telling them all in the first place.

ymmv
bruce


Edit and addendum:

Consider this.  A sequence diagram with more than three "levels" of objects is at best unintellingeable and at worst either incomplete or incorrect. Given the entire idea of OO design, resposibilities, hiding etc etc, draw a single diagram based around one and only one "object of interest" to the diagram (and the people involved in that object).  Model any and everything that is a stimulus to that object, and model how that object will react.  Then start breaking up that unintelligible diagram into understandable chunks.