Two Opportunities and Challenges of Automatic Layout in Visual Languages Christoph Daniel Schulze Kiel University cds@informatik.uni-kiel.de Abstract ing to understand things or to explain them to others. If this Diagram-based visual languages are an established means serves us well, why then should computer-based visual lan- for describing and developing software systems, but have an guages be any different? For the purposes of this paper, we important drawback: users need to place diagram elements shall look at two approaches to answer that question. properly for a diagram to be properly readable, which can First, there is the sheer size of diagrams. In contrast to take a significant amount of time (Klauske and Dziobek diagrams scribbled on a sheet of paper, diagrams used to de- 2010). Automatic layout algorithms aim to automate that velop software systems can quickly grow so large that they task to improve user productivity. These algorithms enable cannot be displayed on a single screen without losing legi- new ways for working with visual languages, but present bility. This forces developers to only look at small excerpts new challenges as well. of the diagram at a time, which causes the mental overview In this paper, I suggest to think about automatic layout to suffer and thereby decreases the diagram’s usability. Of- algorithms in terms of challenges and opportunities. Chal- ten enough, the problem is not just the number of diagram lenges are problems that need to be solved for layout al- elements. Most visual languages contain text labels to iden- gorithms to yield good results. Opportunities are problems tify elements and to specify behavior. Depending on the lan- inherent in visual languages or new user interaction scenar- guage, these labels can grow very large and force the dia- ios that can be tackled with automatic layout. To illustrate gram to grow very large as well. To make matters worse, these terms, I summarize previous research on one example long text labels do not simply enlarge a diagram; they do so of each. by making it wider, causing the aspect ratio to grow less and less favorable for displaying the diagram on today’s common Categories and Subject Descriptors D.1.7 [Programming computer screens. Techniques]: Visual Programming Second, a diagram is not easy to understand just because Keywords Automatic layout, comment attachment, label it is visual in nature (Petre 1995). In fact, a diagram whose management elements are all stacked atop each other at the same posi- tion is visual in nature indeed, but not readable at all. Of 1. Introduction course, this is an artificial example, but it does serve to high- light the fact that element placement hugely influences how Visual languages are popular among developers, both for de- quickly one can grasp what the diagram should express. Get- scribing existing software systems (UML being an example) ting the placement right includes ensuring that a visual lan- and to develop new ones (languages such as LabVIEW,1 a guage’s formatting guidelines are met. In class diagrams, for system design and development platform). Visual languages instance, people expect superclasses to be placed somewhere have a reputation for being easy to understand and use, a nat- above their subclasses, while data flow languages require the ural way to communicate. After all, we quickly start scrib- majority of edges to point in the same direction to visually bling diagrams on whiteboards or pieces of paper when try- highlight the flow of data. Good placement also includes tak- 1 http://www.ni.com/labview ing care that the diagram does not exhibit visual clues that contradict its content. For example, placing two unrelated elements neatly aligned in close proximity makes them look related, whether or not this is in fact the case (Wertheimer 1923). This is called secondary notation: information that through placement transcend what is contained in the dia- gram’s pure structure. Getting the placement right is a lot of work. Based on observing developers in the automotive in- dustry, Klauske et al. (Klauske and Dziobek 2010) estimate for improvement. This mainly affects two areas: the tooling, that placement accounts for up to 30% of a developer’s time. and the visual languages themselves. While editing environ- Reducing that hit on developer productivity is what auto- ments for textual languages have matured to provide very matic layout algorithms aim to do. Instead of having to place advanced and effective editing features, editors for visual all diagram elements manually, that task is delegated to the languages still leave something to be desired (Pietriga 2005; computer. While this solves the problem of too much time Klauske and Dziobek 2010). The languages themselves re- spent moving diagram elements around, it gives rise to new quire a certain expertise when it comes to using secondary problems when it comes to secondary notation. Consider a notation well (Petre 1995), which is a skill that must be diagram with two closely spaced elements. A human viewer learned. will immediately assume the two to be related in some way It has been recognized that comments can relate to dia- and, when asked to modify the diagram, will probably try gram elements differently (Eichelberger 2005). However, to to keep this visual clue intact. What a given automatic lay- the best of our knowledge we are the first to tackle the prob- out algorithm will do in this situation depends strongly on lem of inferring those relations to support automatic layout the particular algorithm. Misue et al. (Misue et al. 1995) dis- algorithms (Schulze and von Hanxleden 2014; Schulze et al. tinguish layout adjustment and layout creation algorithms. 2016b). The results of this line of research may be combined The former will try to keep the general topology of a draw- with research done on comments in textual languages. For ing intact, and may in fact succeed in not destroying the im- example, checking the consistency between comments and plicit relation between the two elements. A layout creation the code they relate to (Tan et al. 2012) requires knowledge algorithm, on the other hand, computes a new layout from about that relation. Comment attachment may ultimately scratch. Since it does not know about the relationship be- make such techniques applicable to visual languages. tween the two elements, this can lead to them being placed The term label management and basic label shortening far apart in the final layout, thereby destroying a potentially techniques were introduced by Fuhrmann as part of his dis- important visual clue. sertation (Fuhrmann 2011). We have since implemented and Through the fast computation of layouts, automatic lay- added to the techniques, have started to evaluate them, and out algorithms can serve as enablers for ways to improve have developed more advanced concepts as to how they can the usability of visual languages. Let us come back to the be integrated with automatic layout. problem of large text labels. Depending on what the user is Label management aims to do something about the prob- trying to do at a given moment, the full content of one label lem of too little screen space and can be used to reduce the may be important while not all the details of another label amount of unnecessary information visible at a given time. are of interest. Yet another label may not need to be shown There are other techniques that focus on similar problems. at all, allowing the diagram to become smaller. However, Fisheye views (Leung and Apperley 1994; Sarkar and Brown what is and what is not interesting to a user changes dynam- 1992) emphasize a region of focus over its surroundings by ically as they concentrate on different parts of a diagram. scaling diagram elements up and down, but suffer from legi- This dynamic makes it impossible to exploit size changes bility problems either due to optical distortion or due to very with manual placement, but automatic layout is fast enough small font sizes. Other approaches show or hide elements to quickly rearrange diagram elements to fit more of them on depending on the zoom level (Been et al. 2006), but cannot the screen. reduce the amount of information shown by an element. Os- man et al. (Osman et al. 2014) take the approach of ranking 1.1 Contributions elements in class diagrams by importance and allow the user In this paper, we take a step back from the details of how to hide less important elements. In contrast to our methods, automatic layout algorithms work and think about them in- they do not take spatial considerations into account and can stead in terms of what keeps them from being used and what only show and hide elements, not modify them. Similarly, new usage scenarios they enable. In this spirit, the main con- Musial and Jacobs progressively hide details of classes in tribution is the motivation and introduction of the notion UML class diagrams as the classes are further away from of challenges and opportunities of automatic layout algo- what the user is currently focusing on (Musial and Jacobs rithms. This helps us bring together two formerly separate 2003). They rely purely on the concept of focus and con- lines of research we reported on previously: comment attach- text (Card et al. 1999), which our methods are compatible ment (Schulze et al. 2016b) and label management (Schulze with, but not limited to. et al. 2016a). In doing so, we summarize results obtained so far in each of these areas. 1.3 Outline We start by properly introducing what we mean by opportu- 1.2 Related Work nities and challenges. This is followed by a discussion of two The ultimate goal of our research is to improve the usabil- examples of opportunities and challenges, along with a sum- ity of visual languages. It is thus worth recognizing that mary of results obtained so far in these areas. We conclude other researchers have also found that there is, in fact, room with a discussion of the presented material. 2. Challenges and Opportunities The problem of placing diagram elements and routing edges is a very complex one. Consider the three main phases of the layered layout approach (Sugiyama et al. 1981): layer assignment, crossing minimization, and horizontal coordi- nate assignment. Depending on the optimization criteria, the first two must solve NP-complete problems (Di Battista et al. 1999): finding an order of nodes that minimizes the number of edge crossings, for example. This leads us to the follow- ing definition: A challenge is a problem inherent in a layout ap- proach that needs to be solved in order for the ap- proach to work or to improve the layout results it pro- Figure 1: A small node-link diagram as laid out manually us- duces. ing the Ptolemy II block diagram language. The developer in this case took care to make the relation between comments Research on layout algorithms usually focuses on effi- and diagram elements clear through placement. This partic- cient methods to tackle the complex and hard algorithmic ular diagram is part of the example models that ship with problems, which of course are big challenges for algorithm Ptolemy II. developers. In the process, seemingly smaller and perhaps less theoretically interesting problems often seem to be over- 3. Comment Attachment looked and regarded as trivial implementation details. It is the experience at our research group, however, that if left Similar to textual languages, comments in visual languages unsolved these problems can be the reason why users fail to help explain what is expressed through a diagram (see Fig- use automatic layout more than once. The experience that ure 1). In textual languages it is usually very apparent what a the layout algorithm has produced an unfortunate and obvi- comment refers to. Languages such as Java even make rules ous placement problem which is easily spotted and which “I part of the language definition. There are usually no such could have easily done better” can lead users to never hit a rules in visual languages. If the comment is not explicitly layout button again. What’s more, many small and simple connected to the diagram element it refers to (which not all problems turn out to be not as small and simple once prop- languages support, and not all developers use), their relation erly investigated. If layout algorithm developers want their is defined through more implicit and ill-defined means, such algorithms to be widely adopted, both the obviously hard as how the comment is placed relative to other diagram ele- and the seemingly smaller challenges have to be addressed. ments, or the comment’s text. Problems are not to be found only in layout algorithms, If an automatic layout algorithm encounters a comment but also in the design of visual languages. One example are with no explicit connection to the diagram element it relates long labels: if a visual language tends to make developers to, it may end up placing the two far apart. After all, it has no use long labels, the diagrams they produce will often grow idea that they should be placed in close proximity. We thus too wide to be properly displayed on standard computer need to make these relations available to layout algorithms. screens. This leads us to the following definition: This requires developing methods that recognize implicit clues in order to turn them into explicit attachments between An opportunity is a usability problem in the design comments and diagram elements that layout algorithms can of a visual language which can be mitigated through process. Computing these attachments is called the comment the use of automatic layout, or a new user interaction attachment problem (Schulze and von Hanxleden 2014). scenario enabled by automatic layout. Note that we would classify this as a challenge. Relating comments and diagram elements through placement in man- In the case of long labels, automatic layout algorithms ual layouts works just fine, so this is not a problem of the can be used to shorten them and then modify the layout to visual language itself. The problem much rather lies in the take advantage of the saved space. Of course, taking advan- layout algorithms that do not recognize these relations and tage of such opportunities does pose additional problems to may consequently fail to preserve them. be solved on the layout algorithm side. In contrast to chal- It is obvious that all comment attachment methods are lenges, however, these problems are not inherent to the lay- limited to be heuristics: there simply are no universal rules out algorithms, but arise from problems with the languages people follow when writing and placing comments. Still, we that are to be laid out. wanted to find out whether a number of obvious and easy- Starting with the next section, we will look at a challenge to-implement heuristics might be enough to infer the rela- and an opportunity and summarize results obtained so far. tions between comments and diagram elements. In the past, we have evaluated the performance of several such heuris- tics are configured. The distance heuristic, for example, is tics (Schulze et al. 2016b) with a set of example diagrams very sensitive to the maximum distance that comments and taken from Ptolemy II (Ptolemaeus 2014), a set of visual diagram elements may be apart to still be considered related. languages developed at UC Berkeley focusing on the design Finding good settings can be challenging, especially since and interplay of heterogeneous systems. every team of developers can have different coding conven- tions. The second observation directly follows from this dif- Font Size Text documents usually start with a heading set ficulty: inferring relations between comments and other dia- in a font size larger than the rest of the text. Similarly, if gram elements will always be prone to some margin of error. a diagram contains a comment whose font size is larger It therefore seems sensible for language designers to make than that of all other comments, we might hypothesize explicit relations part of the language’s design, and to make that it contains the diagram’s title. Such a comment of it as easy as possible to define them through the tooling. course does not relate to any specific diagram element and should thus be left alone. This heuristic works well 4. Label Management in that if it flags a comment as containing the diagram’s title, this is correct in 98% of all cases. Few visual languages can get away without incorporating at least a bit of text. Languages based on state machines Text Prefix We found that comments that describe the di- usually use text labels to specify the conditions upon which agram as a whole as opposed to a single element often a transition can be taken as well as the actions executed start with a similar prefix, such as “This model. . . ”, or when it is. SCCharts (von Hanxleden et al. 2014) is such “Authors: . . . ”. Such comments do not relate to any sin- a language. Even for small diagrams, transition labels can gle diagram element. How successful this heuristic is de- grow rather long, which in turn forces the diagrams into pends on how developers use a given visual language. It awkward aspect ratios (see Figure 2. Such diagrams cannot works well for the surveyed example diagrams in that if be shown completely without sacrificing readability, even if the heuristics flags a comment it is always correct, but it they could be drawn perfectly well if the labels were shorter. may fail for other languages. Label management aims to improve this situation by Text References It seems obvious that if a comment actu- changing the content of labels and computing a new layout ally mentions a diagram element by name, the two will that takes advantage of the label size changes. The actual probably be related. In practice, though, the comment motivation to do so can vary: may mention other elements as well, or the named ele- • Increase the zoom level. If the diagram should fit on the ment may just serve to distinguish it from the element screen, a smaller diagram results in a larger zoom level, the comment actually relates to. thereby increasing legibility. If the zoom level is fixed, Distance The distance between a comment and other dia- smaller labels allow for more diagram elements to fit on gram elements is probably the most obvious heuristic. the screen, thereby increasing the user’s overview. However, the distance between a comment and the ele- • Reduce visual clutter. Whether the information a label ment it relates to is rather fuzzy in practice. Worse, often contributes is of interest to the user or not depends on that element is not even the one closest to the comment. the task they are working on and what they are currently There is also the question of how far a comment and a focusing on. Reducing the detail of or even removing diagram element may be apart for them to still be consid- unnecessary labels reduces visual clutter and allows more ered to be related. interesting elements to fit on the screen, Alignment Graphic designers use alignment as one of the main tools to establish relations between graphical ele- As mentioned in Section 2 this is an example of an oppor- ments. To our surprise, we found that developers work- tunity. The problem to be solved—labels quickly becoming ing with visual languages care a lot less about alignment, too large and increasing the size of diagrams—is inherent in thus rendering this heuristic almost useless. the visual language. Automatic layout is used as an enabler for label management. After all, simply changing the size of In our evaluations, the best combination of heuristics labels does not accomplish much if we do not change the was able to make correct decisions in about 90% of all diagram’s size as well. cases. The heuristics that fared best were those based on When reducing the size of labels two questions need to established conventions for the given visual language, such be answered: how do we shorten labels, and when do we do as the font size and text prefix heuristic. Heuristics that rely it? more on developers having a grasp on graphic design are Let us begin with the how. Fuhrmann (Fuhrmann 2011) more problematic or even useless. proposed a number of basic shortening strategies shown in These results have yet to be verified with other visual lan- Table 1. Syntactical abbreviation simply cuts off a label’s guages. Still, they already allow for two observations. First, text once a given target length is reached. Semantical ab- a good attachment result largely depends on how the heuris- breviation tries to cut out unnecessary details, only leav- DudeSwitching input bool firstDude_switch_impendingDoom input bool firstDude_switch_apocalypse input bool secondDude_switch_impendingDoom input bool secondDude_switch_apocalypse input bool thirdDude_switch_impendingDoom input bool thirdDude_switch_apocalypse output int indicatorReady = 0 output int indicatorImpendingDoom = 0 output int indicatorApocalypse = 0 bool firstDude_request_ready bool firstDude_request_impendingDoom bool firstDude_request_apocalypse bool secondDude_request_ready bool secondDude_request_impendingDoom bool secondDude_request_apocalypse bool thirdDude_request_ready bool thirdDude_request_impendingDoom bool thirdDude_request_apocalypse [-] FirstDude [-] ThirdDude [-] SecondDude firstDudeLogic @ OneDudeLogic thirdDudeLogic @ OneDudeLogic secondDudeLogic @ OneDudeLogic [+] [+] [+] DudeSwitching input bool firstDude_switch_impendingDoom [-] Controller input bool firstDude_switch_apocalypse input bool secondDude_switch_impendingDoom input bool secondDude_switch_apocalypse readyState input bool thirdDude_switch_impendingDoom input bool thirdDude_switch_apocalypse output int indicatorReady = 0 int entryTime = output int indicatorImpendingDoom = 0 int currentTime = entryTime output int indicatorApocalypse = 0 bool firstDude_request_ready entry / indicatorReady = 255 bool firstDude_request_impendingDoom bool firstDude_request_apocalypse exit / indicatorReady = 0 firstDude_request_ready == false || bool secondDude_request_ready secondDude_request_ready == false bool secondDude_request_impendingDoom [-] || thirdDude_request_ready == false bool secondDude_request_apocalypse 2: / bool thirdDude_request_ready bool thirdDude_request_impendingDoom currentTime = bool thirdDude_request_apocalypse 1: currentTime - 2: firstDude_request_ready == true [-] FirstDude [-] ThirdDude [-] SecondDude entryTime >= && secondDude_request_ready == firstDudeLogic @ OneDudeLogic thirdDudeLogic @ OneDudeLogic secondDudeLogic @ OneDudeLogic 300000 / true && thirdDude_request_ready == indicatorReady = true [+] [+] [+] 0 impendingDoomState [-] Controller notQuiteBoringYetWeAreWorkingOnIt itsBoringThankYouVeryMuch firstDude_request_apocalypse == entry / indicatorImpendingDoom = 255 readyState false && exit / indicatorImpendingDoom = 0 int entryTime = secondDude_request_apocalypse == int currentTime = entryTime false && entry / indicatorReady = 255 exit / indicatorReady = 0 thirdDude_request_apocalypse == [-] firstDude_request_ready == false || secondDude_request_ready == false || thirdDude_request_ready == false false 2: / currentTime = 2: firstDude_request_ready == true && secondDude_request_ready == true && thirdDude_request_ready == true apocalypseState impendingDoomState entry / indicatorApocalypse = 255 1: currentTime - entryTime >= 300000 / indicatorReady = 0 entry / indicatorImpendingDoom = 255 exit / indicatorApocalypse = 0 1: firstDude_request_apocalypse == notQuiteBoringYetWeAreWorkingOnIt itsBoringThankYouVeryMuch exit / indicatorImpendingDoom = 0 true || secondDude_request_apocalypse == apocalypseState true || thirdDude_request_apocalypse firstDude_request_apocalypse == false && secondDude_request_apocalypse == false && thirdDude_request_apocalypse == false entry / indicatorApocalypse = 255 == true exit / indicatorApocalypse = 0 1: firstDude_request_apocalypse == true || secondDude_request_apocalypse == true || thirdDude_request_apocalypse == true (a) Without label management. (b) With label management. Figure 2: The same diagram (a) with all labels displayed without modification, and (b) with label size managed by wrapping the label’s text appropriately. Assuming that the space available to draw both diagrams has a typical aspect ratio (such as 4:3), or alternatively assuming a fixed width (as in this figure), the diagram in (b) can be drawn with a larger zoom factor. Type Example Inactive Abbreviate syntactical (not SignalA) xor (... Syntactical Abbreviation semantical SignalA, SignalB / SignalC Semantical Abbreviation Wrap syntactical (hard) (not SignalA) xor (not Semantical Wrapping SignalB) / SignalC(cou nter) 0 1 2 syntactical (soft) (not SignalA) xor (not SignalB) / SignalC( Figure 3: Increase of the zoom factor we achieved for our counter) set of evaluation models with different label management semantical (not SignalA) xor strategies as compared to without label management. (not SignalB) / SignalC(counter) Table 1: Basic label shortening strategies (Fuhrmann 2011). get length. The most obvious way to decide which labels to shorten is to use a preprocessing approach before the auto- matic layout algorithm is triggered. The preprocessing can ing in what is required to get an idea of the original text. make decisions based on information such as what parts of a The three wrapping strategies are based in the observation diagram are active while a simulation or debugging session that the width of labels is often more problematic than their is running, or which diagram elements are selected. It is here height. Syntactical hard and soft wrapping work just like that the preprocessing approach can easily be integrated with they do in text editors. Semantical wrapping makes sense focus and context concepts (Card et al. 1999). in cases where labels follow a strict syntax: it restricts the The preprocessing approach has the potential drawback points where line breaks can be inserted in an attempt to vi- that labels are shortened regardless of whether this actually sually reflect the text structure. has any impact on the diagram’s size. This is because the We applied some of these heuristics to a set of 93 SCCha- necessary information are not available until automatic lay- rts containing a total of 6230 transition labels and measured out is triggered. This is why we developed the feedback loop the zoom level required to fit a whole diagram on the screen, approach. Here, a preprocessing still configures how each with and without shortened labels. The results, shown in Fig- label can be shortened, but the decision of whether or not it ure 3, indicate that significant zoom level increases are pos- will be shortened is then left to the layout algorithm. sible. It does not come as a surprise that syntactical abbrevi- The two approaches also differ in how the target length ation is most effective in that regard: it always achieves the for labels is determined. The preprocessing approach needs target length and does not increase a label’s height. Other to set a target length more or less arbitrarily, perhaps based strategies may be better, though, in terms of usability. on user input. The feedback loop approach can allow labels Let us now turn to the when of shortening labels, which to be as long as possible before having too much of an impact will also answer the question of how to determine the tar- on their diagram’s size. 5. Discussion Australia, 2003. Australian Computer Society, Inc. ISBN 1- 920682-03-1. We have introduced the notions of opportunities and chal- lenges in the context of automatic layout algorithms. To pro- M. H. Osman, M. R. V. Chaudron, and P. van der Put- vide an example for each, we have summarized our find- ten. Interactive scalable abstraction of reverse engineered UML class diagrams. In 21st Asia-Pacific Software En- ings regarding two lines of research: comment attachment gineering Conference, APSEC 2014, Jeju, South Korea, (a challenge) and label management (an opportunity). The December 1-4, 2014. Volume 1: Research Papers, pages former served to illustrate how automatic layout algorithms 159–166, 2014. doi: 10.1109/APSEC.2014.34. URL are still posing challenges for algorithm designers when it http://dx.doi.org/10.1109/APSEC.2014.34. comes to secondary notation. The latter served to illustrate, M. Petre. Why looking isn’t always seeing: Readership skills and however, that automatic layout algorithms can also open up graphical programming. Communications of the ACM, 38(6): opportunities for new ways to help users accomplish their 33–44, June 1995. tasks, for example by auto-generating synthesized views that E. Pietriga. A toolkit for addressing HCI issues in visual language dynamically adapt to changing requirements. environments. In IEEE Symposium on Visual Languages and We believe that algorithm designers often neglect the Human-Centric Computing (VL/HCC’05), pages 145–152, Sept (seemingly) small challenges. In practice, however, we 2005. doi: 10.1109/VLHCC.2005.11. found that it is these details that keep users from embrac- C. Ptolemaeus, editor. System Design, Modeling, and Sim- ing automatic layout. We also believe that we are just start- ulation using Ptolemy II. Ptolemy.org, 2014. URL ing to realize the opportunities enabled by automatic layout http://ptolemy.org/books/Systems. algorithms. M. Sarkar and M. H. Brown. Graphical fisheye views of graphs. There is much potential for future work. Regarding com- In Proceedings of the SIGCHI Conference on Human Factors in ment attachment, the methods need to be tested with more Computing Systems, pages 83–91. ACM, 1992. ISBN 0-89791- visual languages. Also, more complex heuristics could im- 513-5. doi: http://doi.acm.org/10.1145/142750.142763. prove the quality of computed attachments. Regarding la- C. D. Schulze and R. von Hanxleden. Automatic layout in the bel management, a study will be required to show how label face of unattached comments. In Proceedings of the IEEE Sym- management impacts usability. posium on Visual Languages and Human-Centric Computing (VL/HCC’14), Melbourne, Australia, July 2014. References C. D. Schulze, Y. Lasch, and R. von Hanxleden. Label manage- K. Been, E. Daiches, and C. Yap. Dynamic map labeling. IEEE ment: Keeping complex diagrams usable. In Proceedings of Transactions on Visualization and Computer Graphics, 12(5): the IEEE Symposium on Visual Languages and Human-Centric 773–780, Sept 2006. doi: 10.1109/TVCG.2006.136. Computing (VL/HCC’16), 2016a. C. D. Schulze, C. Plöger, and R. von Hanxleden. On comments S. K. Card, J. Mackinlay, and B. Shneiderman. Readings in Infor- in visual languages. In Proceedings of the 9th International mation Visualization: Using Vision to Think. Morgan Kaufmann, Conference on the Theory and Application of Diagrams (DIA- Jan. 1999. ISBN 1558605339. GRAMS’16), 2016b. G. Di Battista, P. Eades, R. Tamassia, and I. G. Tollis. Graph K. Sugiyama, S. Tagawa, and M. Toda. Methods for visual under- Drawing: Algorithms for the Visualization of Graphs. Prentice standing of hierarchical system structures. IEEE Transactions Hall, 1999. ISBN 0-13-301615-3. on Systems, Man and Cybernetics, 11(2):109–125, Feb. 1981. H. Eichelberger. Aesthetics and Automatic Layout of UML S. H. Tan, D. Marinov, L. Tan, and G. T. Leavens. @tComment: Class Diagrams. PhD thesis, Bayerische Julius-Maximilians- Testing Javadoc comments to detect comment-code inconsisten- Universität Würzburg, 2005. cies. In Fifth IEEE International Conference on Software Test- H. Fuhrmann. On the Pragmatics of Graphical Modeling. Disser- ing, Verification and Validation, pages 260–269, April 2012. doi: tation, Christian-Albrechts-Universität zu Kiel, Faculty of Engi- 10.1109/ICST.2012.106. neering, Kiel, 2011. R. von Hanxleden, B. Duderstadt, C. Motika, S. Smyth, L. K. Klauske and C. Dziobek. Improving modeling usability: M. Mendler, J. Aguado, S. Mercer, and O. O’Brien. SCCharts: Automated layout generation for Simulink. In Proceedings of Sequentially Constructive Statecharts for safety-critical applica- the MathWorks Automotive Conference (MAC’10), 2010. tions. In Proc. ACM SIGPLAN Conference on Programming Y. K. Leung and M. D. Apperley. A review and taxonomy of Language Design and Implementation (PLDI’14), Edinburgh, distortion-oriented presentation techniques. ACM Transactions UK, June 2014. ACM. on Computer-Human Interaction, 1(2):126–160, June 1994. M. Wertheimer. Untersuchungen zur Lehre von der Gestalt. II. K. Misue, P. Eades, W. Lai, and K. Sugiyama. Layout adjustment Psychologische Forschung, 4(1):301–350, 1923. and the mental map. Journal of Visual Languages & Computing, 6(2):183–210, June 1995. B. Musial and T. Jacobs. Application of focus + context to UML. In APVis ’03: Proceedings of the Asia-Pacific symposium on Information visualisation, pages 75–80, Darlinghurst, Australia,