9.3 Specifying Arrows

Arrows are probably the most important elements in a message sequence chart. They represent the actual messages. Arrows can be specified using the following syntax.

entityname arrowsymbol entityname [attr = value | style, ...];

arrowsymbol can be any of ‘->’, ‘<-’ or ‘<->’, the latter for bidirectional arrows. a->b is equivalent to b<-a. This produces an arrow between the two entities specified using a solid line. Using ‘>’/‘<>’, ‘>>’/‘<<>>’ or ‘=>’/‘<=>’, will result in dotted, dashed or double line arrows, respectively. These settings can be redefined using styles, see Defining Styles. There are two more arrow symbols for you to re-define: ‘==>’ and ‘=>>’ (with reverse and bi-directional variants, too: ‘<==>’ and ‘<<=>>’). These default to double lines, with the latter having sharp arrowheads, as well.

It is possible to omit one of the entity names, e.g., a->;. In this case the arrow will expand to/from the chart edge, as if going to/coming from an external entity. Using the pipe symbol ‘|’ as start or endpoint instead will still make the arrow go to (or come from) no specific entity, but not at the very end of the chart, but immediately after the last entity (or before the first one).

exB5_cshexB5

You can also use the start before and end after keywords after the arrow specification to precisely indicate where the arrow should start and/or end. You need to specify an entity afterwards and optionally an offset. The terms ‘before’ and ‘after’ should be understood in the direction of the arrow, so if an arrow is right-to-left, then start before X makes the arrow start right of entity X. A positive offset moves the arrow endpoint even further from the entity specified. (In the example above start before X +10 would move the start of the arrow even more to the right. The offset is specified in pixels. The default distance from the entity (to which offset is added) is 30 pixels times the value of the hscale (and exactly 30 for hscale=auto).

It is possible to specify multi-segment arrows, such as a->b->c in which case the the arrow will expand from ‘a’ to ‘c’, but an arrow head will be drawn at ‘b’, as well. This is used to indicate that ‘b’ also processes the message indicated by the arrow. The arrow may contain any number of segments, and may also start and end without an entity, e.g., ->a->b->c->d->;. As a syntax relaxation, additional line segments can be abbreviated with a dash (‘-’), such as a<=>b-c-d;. Subsequent segments inherit the line type and direction of the first one. This enables quick changes to these attributes with minimal typing, as only the first arrow symbol needs to be changed. As a further possibility, different arrow symbols can also be used for different segments, such as a->b=>c>>d-e;, but all the arrow symbols must be of the same direction. It is therefore not possible to mix arrows of different directions, such as a->b<-c; or a->b<->c;. Note that specifying different arrow symbols affect only the line attributes of the segments by default, but they can also impact the arrowhead, text or other attributes, see Arrow Appearance below.

If the entities in a multi-segment arrow are not listed in the same (or exact reverse) order as in the chart, Msc-generator gives an error and ignores the arrow. This is to protect against unwanted output after rearranging entity order.

Arrows can also be defined starting and ending at the same entity, e.g., a->a;. In this case the arrow will start at the vertical line of the entity and curve back to the very same line. Such arrows cannot be multi-segmented.

Only non-grouped entities can be used in an arrow definition. If an entity used to define an arrow is not shown due to the collapse of its group entity, Msc-generator will automatically use the collapsed group entity when drawing the arrow, instead. If the arrow becomes degenerate (spanning between only a single collapsed group entity) or disappears entirely, an indicator will be shown instead, if the ‘indicator’ attribute of the collapsed group entity was set to yes (default).