ObjectTime/UML/Erlang

[Ulf Wiger]

Tony Pedley wrote:
> 
> Hi
> 
> We are currently investigating Erlang projects and at the same time
> looking at our development tools. One tool we are currently interested
> in
> is ObjectTime, which from the demonstration's we have seen is a very
> sophisticated
> analysis and design tool. However the UML diagrams are converted down to
> C/C++.
> >From our discussions it is said to be feasible to use other languages,
> although a
> lot of work would be required, and were wondering if anyone had looked
> in to it or indeed
> any work at all in UML-Erlang conversion.

Yes, there has (or at least partially).
We looked into using Rational Rose for Erlang development. At the time,
Rose supported only the Booch notation, but we did at least discuss UML
and decided that our conclusions would hold for UML as well.

I might add that a study was presented at the latest Erlang User
Conference, which used TeleLogic's SDT to develop an Erlang program. It
didn't look too shabby, since SDL and Erlang are similar in many
respects. But at least for now, generating Erlang from SDL/PR requires
more work than it would take to write the Erlang programs from scratch.
Having said that, though, it wouldn't be fair not to also count the time
it takes to document your program design. Using SDT, much of the
documentation is done as an integral part of the design work, and SDT
*is* capable of generating working Erlang programs from a complete
specification.

I've included some quotes from the study of Booch/Rational Rose. Some of
the conclusions are based on what Rational Rose actually supports (e.g.
it doesn't support code generation from sequence charts). ObjectTime
might be better in some regards -- I don't know:

"Conclusion
----------
We do not recommend adapting Rational tools to Erlang at this time. It
is not yet clear whether it will be feasible to go both back and forth
between Booch/OMT analysis models and Erlang code, and it is not obvious
that the design model used in Rational tools would promote good Erlang
program design. Furthermore, Rational offers little support for the
primary specification standards in the telecommunications field.

"We propose a pilot project aimed at improving existing Erlang design
and analysis tools, and suggest consideration of a few other design and
analysis products, such as TeleLogic's SDL Design Tool and Verilog's
ObjectGeode. Both tools support SDL (ObjectGeode also supports OMT),
which is widely used in the telecom industry, and for which there is
already an experimental link to Erlang."

"The most common issues raised to Erlang consultants at large Ericsson
projects concern support for the standard description methods and
verification tools used in the telecom world. While some low-level
support has been developed in the form of programming support for ASN.1,
SNMP and yacc-style grammars, little support exists for the use of
verifiable high-level design models.
Whether the Booch and OMT design models are verifiable is outside the
scope of this paper, but there exists no support for model verification
in Rose. Furthermore, there is no built-in support for the standards
mentioned above, nor does Rose allow designers to specify detailed
functional behavior in the graphical model.

"This point is not unimportant. One of the primary strengths of
functional programming languages is that they are (at least
theoretically) verifiable. No doubt this quality contributes to the ease
with which one can write robust applications in Erlang. When designing
complex systems, it is essential that powerful methods exist to verify
that the product will actually behave as intended. This can be
accomplished in various ways, for example by comparing run-time behavior
with the model specification, or by processing the model with some
verification algorithm (e.g. automatic normalization of an E-R schema).
While it is dangerous to rely too much on the promise of "software which
writes itself", it would be foolish to revert back to a modeling and
implementation style which is provably unverifiable. It is thus
reasonable to strive for this property at all levels of the development
process.

"The remaining discussion focuses mainly on the link between Rose
diagrams and Erlang programs.
It appears as if it would be possible to make Rational Rose generate
Erlang "code" from a design document, provided the designer adheres to
certain guidelines. Whether it is practically feasible to
reverse-engineer diagrams from Erlang code requires more study. It is
essential that the design tools fully support a rapid prototyping
process without imposing unnecessary restrictions on the programmer. We
believe that the adaptation of Rational Rose for Erlang development
would most likely be imperfect, forcing the individual
designer/programmer to remember which models and programming constructs
do not translate well between the two environments.

"Currently, Rational Rose generates code for class and type
declarations, method interfaces and function heads. While the graphical
model supports MSCs and state diagrams, no code is generated for these
entities. Since their description is stored in a parsable ASCII format,
it might be possible to work around this limitation. In general, we
observe that:

- class and type declarations are of little use in Erlang, 
  since it requires little in that regard.

- method interfaces are useful, but can easily be written 
  by hand (a typical Erlang module might have 1 - 5 lines 
  of export declarations).

- generated function heads are useful only as placeholders. 
  Erlang uses alternative function declarations where patterns 
  in the function arguments determine the function's behavior. 
  Since Rose does not support specification of functional 
  behavior, these patterns cannot be generated by Rose and 
  must be written by hand.

- message sequence charts and state diagrams could be used to 
  generate a significant volume of Erlang code, which is tedious 
  to write by hand. Unfortunately, Rose generates no such code 
  today. Furthermore, Rose supports very little detail in these 
  models, so generated code would still be very spartan."

"When inspecting the actual design model upon which Rational Rose is
based, some key areas of concern are identified:

- Impact on Productivitiy and Code Quality ­
  The design model must promote good Erlang programming style;

- Differences in Design Philosophy ­
  it is imperative that the engineering tools used are capable of 
  generating good Erlang code, as well as reverse-engineer design 
  models from good Erlang code;

- Differences in the Problem Domain ­
  It is easy to write Erlang code based on a good problem definition; 
  thus, automatically generating skeleton code does not necessarily 
  reduce the work effort, but could potentially promote good programming 
  conventions;

- Different relationship between static and dynamic properties ­
  Rational tools were designed primarily for storngly typed languages. 
  Erlang is dynamically typed, which shifts the balance between static 
  and dynamic behavior;

- Conflicting terminology and symbology which cannot be used as intended 
  can be confusing to developers."


> P.S After a week of using Erlang, I'm impressed. Now I have to convince
> everyone else:)[C++ looks better on CV's]

Well, but I always though that the best CV is the one that focuses on
accomplishments. With Erlang, you can accomplish more.  ;)


/Uffe
-- 
Ulf Wiger, Chief Designer AXD 301     <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuvägen 9, Älvsjö                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44