[erlang-questions] CBSE anybody

[Dan Moniz]

On Wed, 9 Apr 2008 10:54:43 +0200, "Joe Armstrong" <erlang@REDACTED>
wrote:

>What I'm after is
>
>    1) a graphic notation showing component integration for the top
>level of design.
>    2) A formal notation for describing protocols for the middle level
>    3) A low level way of implementing the protocol
>
>I also want a *universal* messaging format for
>interprocess-communication. Any votes for Erlang external term
>format/JSON/UBF/list S expressions
>/whatever.
>
>Which bits should we invent for ourselves - and what should we
>borrow/adapt/steal?
>
>Comments please!

I just discovered TTCN-3[1] a little more than a month ago and I've been
looking more into it. This investigation was originally motivated after
seeing TTCN-3 mentioned in connection with some telecom protocols I was
doing preliminary reading on. Briefly, TTCN-3 is a ETSI standard
language for black box protocol conformance testing. It also adopts
ASN.1 for relevant needs.

Interestingly, previous versions of TTCN, notably TTCN-2 and TTCN-1
(from what I understand, TTCN-2 was the most popular version and is
still widely used, TTCN-3 is catching up), were used entirely inside
specialized graphical editors which were diagram based. I haven't seen
any of these editors myself, but there are descriptions of them, and the
book I ordered on TTCN-3[2] descibes them and gives an idealized picture
of what they user interface looked like (see footnote below; Amazon's
preview of the book shows most of the first chapter, I think the picture
representations are in there). The real sea change in TTCN-3 is that
graphical editors are no longer needed; TTCN-3 is now enitrely writeable
in a standard text editor, and usable along with a TTCN-3 compiler and
runtime tools. As far as I can tell right now, all the TTCN-3 compilers,
interpreters, runtimes, and bindings, etc. are commercial in nature.

What TTCN-3 gets you is #2, though from what I've read and understand so
far, while TTCN-3 is widely accepted (in certain communities, natch) as
being great at specifying protocol test suites for use in black box
testing, it's not widely seen as being good for software testing in
general[3]. To me this is fine, but this view may be colored by my
intended use of TTCN-3.

In theory it ought to be trivial to derive a graphical representation of
a TTCN-3 speficiation, though I've done no work on this myself yet. This
is still kind of the reverse of the order you want to go in though; from
#2 to #1, whereas you want #1 to #2. Still, using TTCN-3 as a base,
implementing a graphical UML-esque editor which emits or merely provides
a different rendering of a TTCN-3 specification sounds feasible.

Because I've only found commercial TTCN-3 implementations, I've been
trying to figure out how I'm going to get my hands on something useful
to understand the language in practice. One idea that came to me this
week was to hijack the TTCN-3 parser (implemented in ANTLR 2) that's in
TRex[4], which is an open source Eclipse-based TTCN-3 editor/IDE, and
maybe bolt it on to something.


Footnotes:

[1] http://www.ttcn-3.org/
[2] http://www.amazon.com/dp/0470012242
[3] http://wiki.openttcn.com/media/index.php/OpenTTCN/Language_reference
[4] http://www.trex.informatik.uni-goettingen.de/trac/wiki/WikiStart


-- 
Dan Moniz <dnm@REDACTED> [http://pobox.com/~dnm/]