RE: MSC-News: Conditions in HMSC


Subject: RE: MSC-News: Conditions in HMSC
From: Jan Docekal (jan.docekal#telelogic.se)
Date: Fri Jan 23 1998 - 12:44:04 GMT


The originator of this message is responsible for its content.
-----From Jan Docekal <jan.docekal#telelogic.se> to mscnews -----

> ----------
> From: Oystein Haugen[SMTP:etooha#eto.ericsson.se]
> Reply To: Oystein Haugen
> Sent: den 23 januari 1998 12:56
> To: Dagbjorn Nogva
> Cc: mscnews#sdl-forum.org
> Subject: Re: MSC-news: Conditions in HMSC
>
> The originator of this message is responsible for its content.
> -----From Oystein Haugen <etooha#eto.ericsson.se> to mscnews -----
>
> Dagbjorn Nogva wrote:
>
> > The originator of this message is responsible for its content.
> > -----From telox1#fs.siemens.no (Dagbjorn Nogva) to mscnews -----
> >
> > Dear (H)MSC community,
> >
> > I have a question concerning use of conditions in HMSCs.
> >
> > In an HMSC, is it allowed to let the same condition appear more than
> > once (like "multiple appearence of state" in SDL)?
> >
> > A typical situation where this is useful is an MSC which is
> > valid in many conditions, for instance an MSC describing
> > some kind of common error handling or a shutdown procedure.
> >
> > In this case I would like to draw a condition symbol containing
> > a condition list, then a reference symbol with the name of the MSC
> > and finally a condition symbol defining "nextstate". This graph
> > will then be detached from the rest of the HMSC. Is this allowed?
> >
> > Best regards
> > Dagbjoern Nogva
> > Telox AS
> >
> > -----End text from telox1#fs.siemens.no (Dagbjorn Nogva) 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
>
> Dear Dagbjorn and the (H)MSC community
>
> Your question is very interesting, and I belive that the question has
> not been discussed explicitly in the process of standardization of
> Z.120. On the other hand the language definition should of course give
> answers to your question.
>
> My interpretation is the following:
>
> Multiple occurrences of the same condition is legal in graphical HMSC.
> (In textual HMSC there is no problem since the condition name is the
> only significant identification of the condition).
> The semantics of the multiple occurrence is that it is seen as a
> shorthand for superimposing graph fragments upon each other. The
> reason
> for multiple occurrences is solely to avoid cluttering of the
> graphical
> diagram and it is not disallowed.
>
> As far as I can see the graphical grammar does allow fragmented HMSC,
> where the fragments may be without start area. Up until now, however,
> we
> have thought about graphs which are all connected, with the exception
> of
> parallel expressions.
>
Unfortunately I must disagree with the statement in the paragraph above.
The chapter that treats HMSC starts like this:

5.5 High-level MSC (HMSC)

High-level MSCs provide a means to graphically define how a set of MSCs
can be combined. An HMSC is a directed graph where each node is either :

- a start symbol (there is only one start symbol in each HMSC),
- an end symbol,
- an MSC reference,
- a condition,
- a connection point, or
- a parallel frame.

Both the Concrete Textual and Graphical grammar then states that the
graph must start with an start symbol (if I interpret the {...} set
operator correctly).

Concrete textual grammar

<msc expression> ::=
                <start> <node expression> *
.....

Concrete graphical grammar

<mscexpr area> ::=
                { <start area> <node expression area>* <hmsc end area>*
} set

<start area> ::=
                <hmsc start symbol> is followed by { <alt op area>+ }
set
...

The proposed interpretation of fragmented HMSC's above would indeed give
HMSC's the possibility to express (C++ styled) exceptions and a
discussion in this direction should be encouraged (there have earlier
been discussions of conditions in HMSC's as continuation points from
referenced MSC's which have different exit conditions, and this would be
a natural extension of this discussion). In my opinion the current
version of Z.120 does not support your interpretation of HMSC
fragmentation.

Your interpretation of the semantic use of conditions fits (into my
interpretation of) what Z.120 states

Best regards
- Jan Docekal

> Yours
> Oystein Haugen
> (rapporteur ITU SG 10 / MSC)
>
> --
> ------------------------
> Oystein Haugen, Ericsson as. , P.O. box 34, N-1361 Billingstad, Norway
> Tel: +47 66 84 23 46 Fax: +47 66 84 19 15 E-mail:
> etooha#eto.ericsson.se
>
>
>
>
> -----End text from Oystein Haugen <etooha#eto.ericsson.se> 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 Jan Docekal <jan.docekal#telelogic.se> 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:37 GMT