<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On 30 June 2014 08:47, Torben Hoffmann <span dir="ltr"><<a href="mailto:torben.hoffmann@erlang-solutions.com" target="_blank">torben.hoffmann@erlang-solutions.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
</div>I think one of the issues is that structure is inherently a visual thing - at least<br>
to me - and that means that some sort of visualisation is necessary to get the full<br>
picture.<br>
<br></blockquote><div><br></div><div>The thing to remember is that different people "see it" differently. I find the visual clutter of diagrams tedious and very hard to read :-)<br><br></div><div>I think there must be both, textual and visual, in order to convey something to a wider audience, as some will prefer text, some diagrams, and some like both.<br>
<br></div><div>In a previous life, during the requirements gathering phase, I would capture business logic as a kind of textual "given-when-then" list of bullets, as well as draw a state chart diagram, in order to try my best at getting useful feedback from the client on the veracity of the designed logic.<br>
<br></div><div>The ideal system allows you to move back and forth between textual and visual notation, with neither missing anything from the other. This is hard to achieve, though :-( And my fear is that such a system would only capture the intersection of what the two methods provide. Leading to a useless system, as each (text or visualisation) would provide benefits not nicely expressible in the other. Is there research in this area that can be tapped into?<br>
<br></div><div>Regards,<br>Robby<br><br></div></div></div></div>