<div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Perhaps the way to proceed is to create a library that<br> produces the necessary metadata for later visualization?</blockquote>
<div><br class="webkit-block-placeholder"></div><div>Yes, I think so. </div><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"> My experiments with DOT/SVG indicated that having the<br>
raw data as Erlang sets is often more useful than watching<br> an overloaded graph.</blockquote><div><br class="webkit-block-placeholder"></div><div>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.</div>
<br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"> I'd like to take a swing at using xref and syntax tools<br> for extracting useful metadata about applications. The<br>
question is of course: what is useful?</blockquote><div><br class="webkit-block-placeholder"></div><div>Something like this, I think.</div><div><a href="http://pics.livejournal.com/gaperton/pic/00001eq1">00001eq1</a></div>
<div><br> </div><div>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:</div><div><br class="webkit-block-placeholder">
</div><div>function/responsibility (list of collaborators, required to perform the function)</div><div><br class="webkit-block-placeholder"></div><div>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.</div>
<div><br class="webkit-block-placeholder"></div><div>knows Ballance (UserAccounts)</div><div><br class="webkit-block-placeholder"></div><div>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.</div>
<div>2) Also, this is great format for _comments in code_, which is truely hard to beat.</div><div><br class="webkit-block-placeholder"></div><div>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...</div>
<div><br class="webkit-block-placeholder"></div><div>...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.</div>
<div><br class="webkit-block-placeholder"></div><div>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.</div>
<div><br class="webkit-block-placeholder"></div><div>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.</div>
<div><br class="webkit-block-placeholder"></div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">My first example counted modules in application A which had<br>
any dependency (called any function) to application B.<br> <br> More suggestions are welcome.<br> <br> BR,<br> Ulf W<br> _______________________________________________<br> erlang-questions mailing list<br> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br> </blockquote></div><br>