Software visualizations can provide a concise overview of a complex software system. Unfortunately, since software has no physical shape, there is no natural'' mapping of software to a two-dimensional space. As a consequence most visualizations tend to use a layout in which position and distance have no meaning, and consequently layout typical diverges from one visualization to another. We propose a consistent layout for software maps in which the position of a software artifact reflects its vocabulary, and distance corresponds to similarity of vocabulary. We use latent semantic indexing (LSI) to map software artifacts to a vector space, and then use multidimensional scaling (MDS) to map this vector space down to two dimensions.The resulting consistent layout allows us to develop a variety of thematic software maps that express very different aspects of software while making it easy to compare them. The approach is especially suitable for comparing views of evolving software, since the vocabulary of software artifacts tends to be stable over time.
UML diagrams generally employ arbitrary layout. Gudenberg al have proposed an evolutionary approach to layout UML diagrams in which a fitness function is used to optimize various metrics (such as number of edge crossings) @cite_13 . Although the resulting layout does not reflect a distance metric, in principle the technique could be adapted to do so. Achieving a consistent layout is not a goal in this work.
@cite_13
2087841383 2079365974 2011584781 2045414386
An evolutionary algorithm that layouts UML class diagrams is developed and described. It evolves the layout by mutating the positions of class symbols, inheritance relations, and associations. The process is controled by a fitness function that is computed from several well-known and some new layout metrics. UML diagrams have become increasingly important in the engineering and reengineering processes for software systems. Of particular interest are UML class diagrams whose purpose is to display class hierarchies (generalizations), associations, aggregations, and compositions in one picture. The combination of hierarchical and non-hierarchical relations poses a special challenge to a graph layout tool. Existing layout tools treat hierarchical and non-hierarchical relations either alike or as separate tasks in a two-phase process as in, e.g., [Seemann 1997]. We suggest a new approach for visualizing UML class diagrams leading to a balanced mixture of the following aesthetic criteria: Crossing minimization, bend minimization, uniform direction within each class hierarchy, no nesting of one class hierarchy within another, orthogonal layout, merging of multiple inheritance edges, and good edge labelling. We have realized our approach within the graph drawing library GoVisual. Experiments show the superiority to state-of-the-art and industrial standard layouts. The paper presents and assesses a layout scheme for UML class diagrams that takes into account the architectural importance of a class in terms of its stereotype (e.g., boundary, control, entity). The design and running of a user study is described. The results of the study supports the hypothesis that layout based on architectural importance is more helpful in class diagram comprehension compared to layouts focusing primarily on aesthetics and or abstract graph guidelines Most models are expressed and visualized with UML nowadays and most UML diagrams are based on graphs. Such graphs can get quite large if a project contains more than 600 class files, which is not uncommon. But changes are hard to recognize in a graph with 600 nodes. Therefore, the user has to find a way to build his own mental map based on the original graph. This mental map should give an overview of the original graph size, structure and it should point to changed areas.We present in this paper an approach, which gives the user a smaller graph as a mental map. This smaller graph uses packages as foundations for nodes and displays the package's content as the node icon. This had be done beforehand to visualize the evolution of developer dependencies over time, where the node icon presented the package's developer information as a pie chart. A suitable icon to present a package's class diagram can be a smaller version of the class diagram itself, if the layout respects its predecessors to allow the user an overview of its evolution.