New arrow support

  • Israel Herrera
    Israel Herrera


    First of all, thank you again for this wonderful software. It is the best MSC generation tool there is as far as I am concerned. =D

    I would like to suggest something that has been missing so far, and that is the "-x" arrow type which stands for a lost message, as there was on old mscgen (It is not mentioned on the documentation, and I was not able to produce it by essay in as much as I have tried). I think it would be very useful to have it on the software.

    I also wonder if it is possible to create some "broadcast/multicast" message-syntax. I am aware that by using the syntax: A->B-C-D-E-... it is possible to deliver a message to different recipients. But only if the arrow connecting them follows the same direction. This fails when the station broadcasting/multicasting is on the middle of the sequence diagram. Maybe a workaround is to use the {}{} parallel environment, but then again there could maybe be an easier and more generic syntax.

    Thank you in advance for your attention.

    Best Regards,

    Last edit: Israel Herrera 2013-10-08
  • Hi,

    Thanks for the ideas. Lost messages are on my TODO for a long time. I just never could figure out the exact syntax to use. My problem was that I thought perhaps users somehow want to express where a message is lost. I mean if we have 4 entities, A, B, C and D and a message is sent from A to D but is lost between C and D, how would I express this? I thought the user may want to control, if the message is lost between A and B, B and C or C and D. Also, perhaps the remainder of the message (the path it eventually did not travel) would be nice to show perhaps greyed out, to indicate the intended destination. How would the user express this? I could not get a good answer, so I focused on other things.

    I am not sure what do you mean by the broadcast/mcast idea. The syntax a->b->c; was originally intended to show that a single message passes (and gets processed at) multiple hops in sequence. A kind of a shorthand for a->b; b->c; (And a->b-c-d-e; is a syntactic equivalent of a->b->c->d->e;.) Of course anyone can use it to express anything they feel it is useful for. But can you draw a figure and attach an accompanying text to show how do you envisioned this broadcast idea?


  • Israel Herrera
    Israel Herrera

    Hello Z,

    Thank you for the fast reply.

    I am glad you have considered on adding this useful "lost message" before. As for the syntax, I would suggest to make use of the % symbol or / symbol just as you use the > symbol for different arrow styles. And in order to use % or / as common text they could be preceded by the \ symbol as escape character.

    I also think that it is a good idea to show the intended path for the message, but just a part of it. We share the same idea. I illustrated it on a example vaguely resembling the one you exposed:

    Different Lost Messages

    As you can see it could be a combination of the [weak] property along with a normally colored arrow, divided by a cross mark. And for determining where is this cross placed, I suggest to use a similar approach to that of Entity positioning by using a modifier like [posX+=0.75] to indicate the cross mark should appear at 75% the length, being 50% the default value. So the syntax could be something like:

    A-%D [posX+=0.70]: lost message;
    A-/D [posX+=0.70]: lost message;

    Regarding the Broadcast/Multicast messages, they are used to send a message to all the available stations in a network (or environment), or a subset of it. I drew a couple of representations to illustrate the concepts.

    When the message is to be delivered to every available station a broadcast message is used.

    Broadcast Messages

    The syntax for this kind of message could be something like:

    C->@: Broadcast Message;

    Or something like that...

    When a message is to be delivered to only a given subset of all the available stations, a multicast message is used. It is a little bit different than the a->b-c-d syntax, as it is intended to arrive (virtually) to all destinations at the same time rather than one after the other. The chart however, is very similar.

    Multicast Messages

    I think the syntax for this could have the same format as in the multiple delivery message, differentiating it by adding a property modifier.

    The syntax for this kind of message could be something like:

    D->A-C-E: Broadcast Message [mcast];

    So as to direct the arrows towards the right directions. Or just modifying the way the multiple-target message is parsed. What do you think?

    Well, thank you very much for your attention towards this suggestions.



    Last edit: Israel Herrera 2013-10-09
  • Hi,

    Sorry for the delay in replying. Thanks for the suggestions, this is good.

    I would put the broadcast/mcast idea somewhat lower priority, due to the following reasons.
    - Most people consider a->b->c not to be two separate message reaching b and c from a, but rather one message travelling first from a to b and then on from b to c. Of course anyone is free to interpret this construct differently, but encoding such a different interpretation into the language is something I do not want.
    - Using [XXX] now means "apply style XXX". And a style has a well defined set of attributes neither of them affecting the schemantic of the arrow (where it starts and ends), merely its visual appearance (color, arrowhead, etc.) Using [mcast] the way you propose would be a departure and I am not ready to do so now. :-)

    But for the lost arrow, here is what I plan to do.
    - Use the asterisk instead of the %. I find it is closer to the X symbol that will be drawn.
    - I will require a syntax like this: a->->b indicating the loss between a and b. The two type of arrows at the two sides of the asterisk must match. of course you can always write a->-b. This would make parsing easier for me.
    - Block arrows will not be able to get lost.
    - I will define new attributes for arrows "lost.line" and "lost.arrow" and "lost.text" that will be used (instead of weak). This is to be able to retain a blue arrow as blue even at the lost part.
    - I will also define an attribute "x.line" which will define the line attributes of the X symbol and also "x.size" which will define how large it is.
    - I will also add "x.pos" to take a number between 0 and 1 or 0 and 100, to set where the loss happens between the two sides. Default will be 50, in the middle.

    What do you think?


    • marco.m

      Hello Zoltán, Israel,

      I like and would use both the lost message and the broadcast message. Here are my comments:

      I will require a syntax like this: a->->b indicating the loss
      between a and b. The two type of arrows at the two sides of the
      asterisk must match. of course you can always write a->-b.

      As Israel, I don't understand where the asterisks you mention would fit in the syntax: a->->b ...

      Why not go for the simpler: a-*d ?

      Regarding the position of the X, I would like to propose a different approach as follows:

      By default, the X should be in the middle of the space between a and the first entity after a, not in the middle between a and d. For example, if from left to right there are a, b, c, d then a-*d should position the X between a and b. Rationale: in general one doesn't care or cannot know where the message is lost, one cares only to say that the message is lost. By putting the X close to the source, the observer doesn't make assumptions about where the message has been lost.

      On the other hand, if one wants to specify where the message is lost, or where the X must be drawn, she can use the "x.pos" attribute as you mention. But, instead of specifying a number from 0 to 100, I would specify an entity.

      For example, if the entities are a,b,c,d

      a*d [x.pos=c] foo;

      would put the X in the middle between b and c.

      Regarding the broadcast or multicast, I would use a symbol that is more explicit, for example the notation in figure 13 of

      And while we are talking about new features :-), what about adding a notation for "timing constraints", also used in the same figure 13 ?

      Thanks for the very good msc-generator :-)


      • Hi,

        Sorry, the asterisk was swallowed by the forum engine. What I meant was
        a-> * -> b (without the spaces, but those are needed it seems). But you have convinced me it is illogical to have two arrow symbols, whereas there will be just one arrow displayed. So I will use the below syntax:

        Either a * -> b
        Or a -> * b

        They will be equivalent, except for the position of the X symbol.

        I will take marco.m's advice on the default position, with the exception that if the asterisk is closer to b, then the loss symbol will be between the last entity before b and b. As for custom positions, there is a way in Msc-generator to specify a vertical location using the 'at' keyword. It can be 'at c' or 'at c++' which is a bit right of c; or 'at c-d' which is in between c and d; you can also add an offset such as 'at c+50' or 'at c-d +50' which is 50 pixels to the left. So I will allow using this clause, not as an attribute, but as a clause after the arrow, like

        a->b * ->c at b++ [attrs];

        which will place the X symbol just after b.

        As for broadcast the figure that marco.m quotes is closer to how I think broadcast messages shall be displayed. I will introduce an 'overlap' or similar keyword, which would be similar to 'parallel', but would explicitly allow one arrow to be drawn on top of another (e.g., for crossing arrows). This would be easy to use for the figure marco.m has cited.

        I will come back on timers, braces etc. in a separate topic (we already have one on timers, btw).

  • Israel Herrera
    Israel Herrera

    Hello Z,

    Nevermind the answer time.

    I think the broadcast/multicast messages might not be a high priority, but they would make a good addition in the future, as they are very common in computer networking. So, low-priority is fine :).

    As for the lost message, I find that the syntax a->-b is quite neat, but I didn't got very clear where does the * appears... Maybe something like a-*>-b? Let me know.

    I find that defining new attributes is an excellent solution and that it would adapt more naturally to the current program features, specially styles.

    Thank you very much for your time, and let me know if I can help you any further.


  • Hi Guys,

    I have uploaded 3.6.3, which now contains the lost message feature. It is documented in the accompanying PDF (on Linux, just 'make mypdf' in the doc directory). Please let me know if you need anything.


  • Israel Herrera
    Israel Herrera

    Hello Zoltan!

    I have just downloaded and checked into the new 3.7 release, and I think it is awesome! Thank you very much for this features. Keep it going! :)