[erlang-questions] code dependency diagrams

[Vlad Balin]

>
> Perhaps the way to proceed is to create a library that
> produces the necessary metadata for later visualization?


Yes, I think so.

My experiments with DOT/SVG indicated that having the
> raw data as Erlang sets is often more useful than watching
> an overloaded graph.


Watching an overloaded graph is not useful. Optimal size of any diagram is
about 5-9 entities. Due to the size of human's operative memory.

I'd like to take a swing at using xref and syntax tools
> for extracting useful metadata about applications. The
> question is of course: what is useful?


Something like this, I think.
00001eq1 <http://pics.livejournal.com/gaperton/pic/00001eq1>


An idea behind this diagram is well-known CRC-cards techniqe. It's being
traditionally used as OO design technique for the team. CRC-card looks like
this:

function/responsibility (list of collaborators, required to perform the
function)

There are special responsibility called "knows". It means that you're able
to obtain specified information from the entity, but it doesn't necessary
mean that this info is the part of the entity. Example.

knows Ballance (UserAccounts)

1) Our experience with C++ shows that the set of CRC-card format is
excellent representation for OO design/architecture, which is much better
than "normal" OO models, like class diagrams, etc. Reason is that CRC-cards
lying somewhere in the middle between requirements/use-cases and OO models.
This fact make it an ideal tool for thinking on design.
2) Also, this is great format for _comments in code_, which is truely hard
to beat.

So, originally CRC-card is representation of the class and is a group
technique for doing OO design. BUT. You can notice, that CRC-cards format is
being focused on functions, rather than encapsulated state. Therefore...

...you can think on design in terms of CRC-cards in purely functional style.
You can use it on erlang modules. And it works perfectly. So, module is a
box, and arrows shows the collaborators/dependencies.

What we can do to make it even more precise - is to introduce "interfaces".
 I.e. we combine module interface functions into groups, and represent it as
some "connection point" connected with its module on the diagram. In this
case, arrows will point to "connection points" instead of modules.

This is really cool technique, but it's impossible to build such a diagram
automatically out of the code. However, you can build _some_ sort of it with
human assistance. For example, if you can ask user to provide subset of
modules to draw on the single diagram.

My first example counted modules in application A which had
> any dependency (called any function) to application B.
>
> More suggestions are welcome.
>
> BR,
> Ulf W
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080229/0f7a692b/attachment.htm>