Subject: Re: SDL-News: Algorithmics
From: Ranjit "Raj" Singh (singh#cig.mot.com)
Date: Tue Mar 17 1998 - 18:25:59 GMT
The originator of this message is responsible for its content.
-----From Ranjit "Raj" Singh <singh#cig.mot.com> to sdlnews -----
This is with regard to Philippe's request for comments on the
proposed upcoming extensions to SDL.
IMHO, not all of us in the user community have a copy of the
ITU Z.100 1994 version handy, so it was sometimes unclear as
to what exactly the proposed changes mentioned to it in Sect
3 of the proposal really changed.
Several of us here at Motorola CIG, in the Cellular Switching
Products group, discused the proposed extensions and this is
In short, we feel that the proposed extensions are not quite
providing any significant positive change to the functionality
Here's the long version ( ;^) ). There are several points here,
not necessarily in any order. Related points are (hopefully!)
1. We strongly feel that there SHOULD be graphical equivalents
to the proposed notation. We bascially agree with whoever stated
what Philippe had included re: comments on the GR/PR etc:
================ from Philippe's email =====================
2) Graphical loops
Another feedback we had is: "I use SDL because SDL is a
graphic modeling technique, and includes a complete
action language to describe transitions. This is not the
case with UML statecharts. With your proposal, I will be
able to express loop constructs in a clean way -- so
without joins and labels -- but this will not be possible
in a graphic way, which is the major advantage of SDL
compared to UML. So it is not satisfactory."
=============== end from Philippe's email ==================
2. Not allowing the mixture of PR with GR is not necessarily
an obstacle. It is, in fact, quite preferable to keep the GR
as graphical as is possible. Introducing the amounts of text
as given in the examples only serves to detract from / reduce
the at-a-glance readability. In fact, the amounts of the text
could be a lot larger than shown in the examples, which would
make this even more true. The visual and readability aspects
of the GR are of concern here.
3. It would be really nice if SDL stds and tools handled a
hierarchical decomposition of some sort to push down certain
details if they're not required to be visible. For instance,
a large decision could be replaced by a single symbol that
would be represented by only a comment being visible at first
which could then be completely viewed by performing some SDL
This would help hide unnecessary details, thus helping
readability and visual compactness, which is one of the issues
of concern mentioned in the proposal position paper.
4. The algorithmic extensions look like code anyways, which
should be against the strongly process-oriented organisations
in the first place.
5. How do we handle comments for the algorithmic extensions?
Uncommented C - which is what these extensions resemble - is a
poor design method. The examples shown do not illustrate how
comments could be inserted.
6. We definitely agree that "TASK" before all assignments is
very cumbersome, along with "CALL" before all procedure calls.
It would make us all very happy to see them optional along with
anything else that's unnecessary.
7. Should signals be included in the algorithmic extensions?
One would think that the inclusion of signals in this would
detract from the GR depiction of the FSM?
======== Wouldn't it be nice if... ====================
Here are some other things that it would be nice if the SDL
stds comittee considered. I apologise if any of these have
made it into the latest standards already - please ignore if
1. Arrays: wouldn't it be nice if declaration of arrays
are made simple? Currently, they're very cumbersome.
2. The biggest obstacle to using SDL, in our opinion, is
how to incorporte external entities. Perhaps the stds and
the tool vendors could work together to make this easier.
We're primarily concerned with data structures.
3. How about a mechanism for allowing type casting along
the lines of C? This "cast" operator would have to allow
overloading, and the true operator could be determined by
using the signature along with the name of the types.
There are issues here such as do we want bit-copy or
conversion. Personally, I prefer bit copy but this could
be debated, of course ;^) !
4. How about a mechanism for forwarding of messages? For
instance, as I understand it, if process P1 sends a msg
to P2, which sends it to P3, P2 becomes the originator of
the msg as far as P3 is concerned. The original sender
is unknown to P3.
5. How about differentiation of signals in a received
signal list using the signal names? This would greatly
help if different processing was required for different
signals which are logically grouped in a signal list. At
the moment this can't be depicted using the names of the
signals in the list. There are workarounds which are a
6. Is it possible to define time in SDL as a unit? This
would be quite helpful.
7. It would be nice if queues could be made bounded. In
reality they always are. This would help in simulation/
8. Exception handling needs to be allowed somehow. This
would help greatly, and also make the simulation and code
generation work out smoother
9. Wouldn't it be nice to have std libraries that came
with SDL for various functions? Then the tools vendors
would be free to implement these functions based off of
a defined and set interface. How they implement them
for simulation or for various RTOSs for code generation
or for simulation would be up to them. It is a painful
and laborious process to create numerous ADTs to do very
commonly used functions.
I apologise if some of these 9 "Wouldn't it be nice if..."
are already "fixed" or being worked on currently or if
others have brought them up before.
Thanks for your attention if you're still reading this... ;^) !
-- Regards, "Raj". ( Ranjit Singh ) ================================================================ The world is as we are. - Ancient Indian proverb. ================================================================
-----End text from Ranjit "Raj" Singh <singh#cig.mot.com> to sdlnews ----- 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-sdlnews#sdl-forum.org
This archive was generated by hypermail 2a23 : Sun Jun 16 2013 - 10:41:40 GMT