|
|
| Author |
Message |
< Erlang ~ Diagram notations for Erlang (Sequence Diagrams / DFDs ???) |
| fikre |
 Posted: Wed Apr 29, 2009 12:57 pm |
 |
|
|
Joined: 07 Nov 2008
Posts: 5
|
Hi
I'm looking for some tutorial on diagramming tools for Erlang.
I've been reading that UML might not be the best thing for Erlang, but that the sequence diagram (in UML) might be somewhat applicable.
I'm looking for something similar to the Class Diagram in UML. I was looking into the use of DFDs but cannot find many examples of its use.
I came across this paper www.erlang.se/euc/99/Event.ps which outlines what's wrong with DFDs and sequence diagrams, but states that they are a good way to start given finding an adequate tool isn't easy (it then goes on proposing a new diagramming format).
I cannot seem to find any work or any examples explaining how DFDs can be applied to Erlang design.
My main concern is that the unit of decomposition can be the function, as well as the process. How are we going to distinguish between a function call, and a message being sent to process? And how are we going to express that a given component is a process or that it is function?
What are the views on this?
And are there any examples i missed or any tutorials out there?
Thanks |
|
|
| Back to top |
 
|
| klaar |
| Posted: Sat May 16, 2009 10:01 pm |
|
|
|
User
Joined: 06 Oct 2008
Posts: 11
Location: Göteborg/Sweden
|
You can model both synchronous and asynchronous calls in sequence diagrams.
If it helps, think of a process as an object, and modules as classes with static methods. You should not implement your system twice, it just have to be good enough, UML is capable of good enough.  |
|
|
| Back to top |
|
| Mazen |
| Posted: Sun May 17, 2009 9:04 am |
|
|
|
User
Joined: 20 Jul 2006
Posts: 164
Location: London
|
One should be careful about publicly admitting that one can see processes as objects and modules as classes with static "methods"... Ive been slapped on the fingers a few times before from many "hardline" erlangers/fps but I think this way of thinking is reasonable and one will soon grow out of this way of thinking. So even if people will frown upon this way of thinking, I am more then 100% convinced that it works, howver it must be said that there is a thin line not to cross over to OOP which is NOT the same thing. Think objects, but don't think OOP... I hope that makes sense
From my experience the following diagrams can be useful:
Activity diagram - Case scenario, High level, Abstracted from design (Tells behaviour)
Sequence diagram - Case scenario from a design and implementation point of view (function calls, parameters etc)
State diagrams - Well... you know why probably
Class diagrams - These are only useful when you want to describe interfaces to a module. |
|
|
| 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
