UML <-> Erlang

WILLIAMS Dominic D.WILLIAMS@REDACTED
Tue Nov 18 10:04:26 CET 2003


Hello Eric,

> What are the odds of a number of Erlang supporters convincing the
> UML community that there is more work to do to truly have a
> "Unified" modeling language?  Does anyone know how one could
> accomplish this?  Maybe the first step is to list the problems?  But
> perhaps one should also list the things that might work well in
> UML's present form.

UML is now managed by the OMG (Object Management Group), so the only
way to influence UML's evolution is to become a member and participate
in work groups. They have various classes of membership: the more you
pay the more influence you have (simplifying a bit).

> I would like to investigate UML in its current state to design some 
> additions to a year-old architecture.  I think UML offers a number of 
> possibilities.

UML offers so many possibilities it makes me uneasy...

> 1. Since it is standardized, does it have clarity over ad-hoc
> diagramming approaches when many parties new to Erlang are involved
> in the design process?

In my opinion, no. Standardisation has not made UML clear, it has made
UML big and complicated and unsatisfying to almost everyone in an
attempt to please everyone.

> 2. Could a class be used to model a gen_server?  And if the Erlang 
> application has many gen_servers then wouldn't simple UML class 
> diagrams help illustrate the design better than other approaches?

Sure, it is possible map Erlang modules to classes (without member
data and without inheritance), behaviours to interfaces. However, UML
is /very/ tightly coupled to C++/Java programming constructs, and I
believe you will find this a bit frustrating, especially if you are
using tools. 

On the other hand, in its effort to embrace every existing modeling
notation on the planet, UML has some diagrams that are not strictly
object-oriented: sequence diagrams, state diagrams and deployment
diagrams may be more suitable to representing concurrent erlang
processes. But again: just use the high level notation. The details
are also tightly coupled to C++/Java.


Disclaimer: I no longer really believe in and use visual modeling,
other than drawing on a whiteboard during team design discussions, for
which an informal ad hoc notation is all we need. So my recommendation
may be biased...


I have heard that SDL and the MSC notation are a better fit with
Erlang... but I have not tried.

Regards,

Dominic Williams.



More information about the erlang-questions mailing list