MSC-News: Gate semantics in MSC'96


Subject: MSC-News: Gate semantics in MSC'96
From: Dmitry Zhukov (dmjr#ispras.ru)
Date: Tue Aug 18 1998 - 13:53:45 GMT


The originator of this message is responsible for its content.
-----From Dmitry Zhukov <dmjr#ispras.ru> to mscnews -----

Dear MSC community,

I am working on syntax and semantic analyser for MSC'96 and
I have some problems in understanding the semantics of
gates in the Z.120. I will be glad to know any opinion
of the problems in this letter (it is quite long ...).

1. Implicit gates

According to the Z.120, paragraph 4.4,

  a message gate always has a name. The name can be
  defined explicitly by a name associated with the gate on
  the frame. Otherwise the name is given implicitly by
  the direction of the message through the gate and the
  message name, e.g. "in_X" for a gate receiving a message
  X from its environment.

This rule works good in the most cases. In the following
example however its application results in two gates
with equal (implicit) names:

  msc m_twice;
    instance a;
      out m to env comment via in_m;
      out m to env comment via in_m;
    endinstance;
  endmsc;

In my opinion the possibility of having several gates
with the same name makes the language difficult to analyse.
Note also that the example above a correct as MSC'92
specification. Can somebody clarify this problem ?

The Z.120 allows also all types of inline expressions to have
message and order gates. However, their semantics is clear
to me only in the case of ALT and PAR expressions.

2. ALT expressions

ALT expression have several sections and only one of them
may be "executed". If a message is sent from an ALT expression
via gate X to an instance or an gate then natural requirements
are

(ALT-ALL) the gate X should be present in *all* expression sections

   and

(ALT-EQ) the message name and parameters should be equal
            for gates with name X in all sections.

If we write a MSC without the requirement (ALT-EQ), for example

  a : alt begin altref;
        gate g in m from a
        external out m to b;
        a : out m to env via g;
      alt;
        a : action 'do nothing';
      alt end;
  b : in m from inline altref via g;

then if we select the second alternative the message source
becomes undefined.

For order gates the requirements (ALT-ALL) and (ALT-EQ) don't seem
to be necessary. For example,

  a : alt begin altref;
        gate g before label external;
        a : lab action 'first';
      alt;
        a : action 'second';
      alt end;
  b : action 'third' before inline altref via g;

In this example we may assume an ordering relation
between 'first' and 'third' actions if the first
alternative is selected.

3. PAR expressions

As all sections of PAR expression are always "executed"
all message gates in PAR expression should refer to
separate messages. This leads to a requirement

(PAR-UNIQ) all message gates in PAR expression (i.e. in
             *all* its sections together) must have
             unique names

4. OPT and LOOP expressions

The body of OPT or LOOP expression is normally "executed"
several times. I don't see any reasonable semantics for
message gates in OPT and LOOP expressions. Consider, for example

  a : loop <0,2> begin loopref;
        gate g in m from a
        external out m to b;
        a : out m to env via g;
      loop end;
  b : in m from inline loopref via g;

If the loop body is executed 0 times then message m is received
1 time but send 0 times. If the loop body is executed 2 times then
message m is received 1 time but sent 2 times.

One may still invent some semantics for order gates in LOOP and
OPT expressions. In the following example

  b : lab1 action 'first' before inline loopref via g1;
  a : loop <0,2> begin loopref;
        gate g1 before lab2 external;
        gate g2 external before lab3;
        a : lab2 action 'second' before env via g2;
      loop end;
  b : lab3 action 'third';

we may assume that the 'second' actions in *all* loop iterations
are after 'first' action and before 'second' action.

5. EXC expressions

As the body of an EXC expression is *never* "executed"
I don't see any reasonable semantics for message and
order gates in EXC expressions.

6. Communication between the MSC environment
   and inline expressions

For each message exchange between the inline expression
and the MSC environment either the sending or the receiving
point is specified. Therefore for communications with the
environment there is no need for some restrictions like (ALT-ALL).

7. The final suggestions

The above restrictions may be written as the following
table:

---------------

expr message gates message gates order gates
type (not from/to env) (from/to env)

ALT ALT-ALL + ALT-EQ ALT-EQ no restrictions

PAR PAR-UNIQ PAR-UNIQ no restrictions

LOOP not allowed no restrictions no restrictions

OPT not allowed no restrictions no restrictions

EXC not allowed no restrictions not allowed

---------------

Please, let me know if there are some
another interpretations of gates in inline expressions
and if there are some another restrictions on them.

Best regards,
Dmitry.

-----End text from Dmitry Zhukov <dmjr#ispras.ru> to mscnews -----
For help, email "majordomo#sdl-forum.org" with the body of your email as:
    help
or (iff this does not answer your question) email: owner-mscnews#sdl-forum.org



This archive was generated by hypermail 2a23 : Wed Jun 19 2013 - 13:16:38 GMT