[erlang-questions] UML or other modeling tools

[Robert Raschke]

Hi Allessandro,

On Sun, Jan 9, 2011 at 7:56 AM, Alessandro Sivieri <
alessandro.sivieri@REDACTED> wrote:

> has anyone of you ever used any modeling tool for describing a system
> written in Erlang (or any other functional language)?
> I have to describe the architecture of an application, in terms of
> processes
> structure/tree and/or modules, and I was wondering if there is some UML
> diagram that could be used, or any "standard" format for doing it; I have
> already created several sequence diagrams, and usually in my other projects
> I have used (more or less detailed) diagram classes, but for functional
> languages I don't know precisely what tools there exist...
>
>
I write business level applications that bridge between an ITSM (IT Service
Management) tool and other ITSM tools and system monitoring tools. For this
we use an Erlang/RabbitMQ framework that runs Lua business logic snippets
based on the state of the linkage between the two systems.

So, for a bridged "thing" (which exists in two different guises on either
side of the bridge), we manage its state and what kind of
interactions/messages in each direction are allowed, how those messages get
transformed (i.e., what effect they have on the other system) and what state
changes they trigger.

For this, I personally, use UML state charts. And that works very well so
far. The trick is to keep the level of detail at an acceptable level. I am
not interested in implementing the logic in a state diagram. All I want is
to capture the salient points and manage the overall complexity of the
logic.

While I ship these diagrams as part of the ongoing (requirements)
documentation, I don't think they've added enormously to a customers
understanding. But they do help me rather a lot when discussing details with
them.

I find it is important to realise that modelling tools are there to model
your proposed solution, not implement it. They are very valuable during
design of a complex system. They make mistakes in your design a bit cheaper
to handle, because you may not have gone and implemented all of it yet. This
makes changing your design a little bit less risky.

Robby