Subject: Re: MSC-News: Gate semantics in MSC'96
From: Ekkart Rudolph (rudolphe#informatik.tu-muenchen.de)
Date: Wed Aug 19 1998 - 17:34:19 GMT
The originator of this message is responsible for its content.
-----From Ekkart Rudolph <rudolphe#informatik.tu-muenchen.de> to mscnews -----
Dear Dmitry,
in general (without going into details) I appreciate your suggestions
concerning restrictions for gates in operator expressions. They reflect somehow
my original ideas. However, only practical experience can show whether these restrictions
are too narrow. E.g. it may be advantageous to have different gate interfaces for
different alternatives in ALT expressions so that e.g. alternatives on
instance 'a' can be combined only with certain alternatives on instance 'b'.
(ALT-ALL would disallow this possibility). Thus, more general rules may make the MSC language more
powerfull but at the same time, it may loose transparency and simplicity. In any case, I feel
that your research is a good basis for further discussions and hopefully will contribute to more
"Glasnost" in the gate semantics. However, it should be mentioned that it is also possible to assign
a semantics to cases which you exclude. This is possible by means of a deadlock interpretation
(or alternatively interpreting these cases by means of incomplete messages). It is a different question
whether this situation is satisfactory.
Concerning your first problem, the implicit gate nanes should of course be made unique by means
of an identifier.
Best regards!
Ekkart
=================================================================================
Dr. Ekkart Rudolph phone: +49 89 289 25361
Technische Universitaet Muenchen fax: +49 89 289 28183
Institut fuer Informatik, email: rudolphe#informatik.tu-muenchen.de
c/o Lehrstuhl Prof. Broy
Arcisstrasse 21
D - 80290 Muenchen
=================================================================================
> 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
>
-----End text from Ekkart Rudolph <rudolphe#informatik.tu-muenchen.de> 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