| Author |
Message |
|
| tonyp at terminus.ericsso |
 Posted: Wed Mar 03, 1999 1:45 pm |
 |
|
|
Guest
|
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.
All the best
Tony
P.S After a week of using Erlang, I'm impressed. Now I have to convince
everyone else:)[C++ looks better on CV's]
--
______________________________________________________________________
Tony Pedley mailto:tonyp_at_terminus.ericsson.se
Ericsson Intracom Ltd. Intranet : http://intracom.ericsson.se
1 Bede Island Internet : http://www.ericsson.co.uk/datacom/index.htm
Leicester memoID : ECOM.CBERAM
England Tel : +44 (0)116 2 542 400
LE2 7EU Fax : +44 (0)116 2 046 111
______________________________________________________________________
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| ulf.wiger at etxb.ericsso |
| Posted: Wed Mar 03, 1999 2:18 pm |
|
|
|
Guest
|
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 |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
