Understanding and maintenance of complex information spaces is often supported through visual interfaces. These interfaces must be highly flexible in order to adapt to both the user's role and their current task. Program comprehension tools are one class of tools that make heavy use of information visualization techniques, and Software Engineers use these tools to help understand and maintain software systems. This paper presents a model-driven approach to address the customization requirements of visual user interfaces, and does so in the domain of program comprehension.
The software industry requires visualization tools that can be adapted
to (1) many different sources of information such as source code,
configuration management data, documentation, user requirements,
(2) various kinds of visualizations, including source code views,
tables, trees, tree maps, graphs, nested-graphs, pie-charts,
kiviatdiagrams, and so on, and (3) many different user roles including
not only developers but also architects, software testers, members
of the quality assurance teams, managers, business architects and
so on. Moreover, experience has shown that in order to increase the
likelyhood of adoption among visualization tools, the tools should
not be standalone monolithic applications, but instead they should
integrated in the developer’s preferred development environment.
Few visualization tools support the level of customization required
to create tailored interfaces, and the tools that do support a high
level of customization, do so at the cost of complexity, or like Hy+
[
The rest of the paper is structured as follows. Section 2 introduces the notion of model-driven visualization. A simple example is presented in Section 3 to illustrate the approach. Section 4 outlines our future work and finally, Section 5 presents some concluding remarks. 2.
Model driven engineering is based on the systematic use of metamodels and transformations. In the context of software visualization, both the information extracted from the software, and information about visualization should be formally defined. While most tools in software engineering are based on implicit metamodels, it has been recognized recently that information metamodels (also called schemas) should be expressed formally. Figure 1 describes a metamodel for a subset of the Java language.
When building visualization tools, the “visualization metamodel” should also be explicitly defined. If tool is formally defined, then software visualization simply becomes a matter of describing the transformation from one model to another. In the remainder of this section, we present some examples of metamodels and then discusses formal transformations.
GUI components designed for visualizing data sets, such as Tree
and Table controls, have an implicit metamodel. A metamodel
formally describes the structure of the information the component can
visualize. For example, SHriMP Views [
Visualization tools are commonly built by researchers as monolithic applications, complete with a parser, application windows, menu system and tool bars. Tools such as these usually have a predefined XML schema for the data they can parse. While this provides a formal metamodel, these tools are hard to re-use in existing applications. Since these tools defined their own menu system, tool bars and set of actions, it is difficult to incorporate these visualizations into existing environments. In order to provide a set of reusable components, we advocate that visualization components should adhere to the API specification of the widget toolkit they were implemented with, and provider a similar set of interfaces as the other views in the toolkit. For example, the views should expose item selection, notifications, view instantion, etc, in the same manner as existing views. For each view, a formal metamodel should also be defined.
Often there are multiple ways to define a data model. In a table view, the table can be defined as several rows, each row containing a fixed number of cells. An equally valid definition would be to define the table as a set of columns, each column containing a fixed number of cells. In order to keep our approach generalizable, several data models have been designed for each component. The implementation of each view will read any model that conforms to one of the pre-defined metamodels. By defining several metamodels for single components, those who use the component can choose the most appropriate metamodel for their data.
The Tree View is widely used to present hierarchical data by listing children below their parents. Sub-trees can often be expanded and collapsed. The wide spread adoption of the tree control can partially be attributed to the fact that many widget toolkits include the control as a standard component. Figure 2 shows an example of a Tree View’s metamodel.
Graph Views display information as a set of nodes connected with
edges to show dependencies among the nodes. Despite the positive
feedback researchers have received from several implementation
of graph based views [
Graph Views can be defined in terms of their nodes and edges or simply defined in terms of their nodes. Using the later approach, the edges can be determined implicitly based on how the nodes are related to one another. An example of each structure is presented in Figure 3.
Metamodels for several other views have also been defined formally. Most notably, metamodels have been defined for Nested Graph Views, Table Views, Matrix Views and Table-Tree Views.
In order to visualize a partial dataset using one the structures described above, application programmers must develop data traversal algorithms and apply them to their data model. The traversal algorithms are used to walk the data structure, extracting the “interesting” information and using this information to populate the views. While traversing the data structures, some information is discarded and new information is deduced. For example, a common Java model will include interactions between Methods. However, when attempting to understand a section of source code, a developer may wish to see how the classes relate to one another. In order to do this, the method nodes must be discarded and the relationships between them lifted to the Class level. Using a declarative language for these transformations is often more concise, and easier to maintain, then writing the traversal algorithms in source code.
A framework for Model Driven Visualization has been implemented
within Eclipse [
The Atlas Transformation Language (ATL) [
In order to demonstrate our approach, we have built a small class browser for Eclipse. Two views were created, one to show the class hierarchy, and the other to show method invocation between classes. A Java metamodel was first defined using EMF, and then using ATL, transformations were written to translate the Java model to a view model. Finally, using our interactive visualization toolkit, the view models were rendered. 1 2 3 4 5 6 7 The Java metamodel presented earlier (Figure 1) defines the JSys- 8 tem, JClass and JMethod elements. JMethods are related to one an- 9 ther through the calls reference and JClasses reference each other 10 through the extendedBy dependency. The left side of Figure 4 11 shows a Java model which conforms to the Java metamodel de- 12 scribed in Figure 1. The two horizontal arrows represent the model 1134 transformations. The two views on the right of Figure 4 show two 15 translated models. The one on top conforms to the TreeView meta- 16 model (Section 2.2.1) and the one below conforms to the GraphView metamodel (Section 2.2.2).
The transformation from the Java Model to the view models is pero u t : g r a p h v i e w ! GraphView ( e n t i t i e s <− j a v a ! J C l a s s . a l l I n s t a n c e s ( ) , e d g e s<− j a v a ! J C l a s s . a l l I n s t a n c e s ()− >
c o l l e c t ( e | t h i s M o d u l e . r e s o l v e T e m p ( e , ’ e ’ ) ) n : g r a p h v i e w ! Node (
l a b e l <− c . name ) ) , e : d i s t i n c t g r a p h v i e w ! Edge f o r e a c h ( s i n g l e C a l l i n c . m e t h o d s − > c o l l e c t ( m|m. c a l l s )− > f l a t t e n ( ) ) ( s o u r c e <− n , d e s t i n a t i o n <− s i n g l e C a l l . p a r e n t
Listing 2: Java to Graph Translation formed using ATL. Listing 1 shows the ATL transformation responsible for translating the Java model to a Tree View model (Section 2.2.1). The main rule matches the Java System and creates the TreeView’s Root Node. All the classes with no superclass are listed as roots. The other rule matches the JClass elements. Each of these elements are translated to TreeView’s Node and the Label for each node is simply the Class name. Finally, the children of a given element are determined by extendedBy relationship in the model.
The second transformation (Listing 2) shows a translation from the Java model to a Graph Model (Section 2.2.2). The Graph Model shows dependencies among classes if there is a call relationship between them. The JSystem2GraphView rule matches the Java System and creates a GraphView Root Node. The edges and entities of the graph are attached to the GraphView. The second rule creates all the Nodes and Edges. Each node directly maps to a JClass element in the Java model. For each method call an edge is created. The edge is lifted to the JClass level such the source of the edge is the JClass that contains the JMethod, and the destination is the JClass of the JMethod being invoked.
Once the transformations is completed, our Visualization Toolkit is used to read the view models and present the user with the Class dependencies. Figure 5 shows the output of this tool.
In the interest in saving space, only simple examples have been presented here. Model-based visualization components are commonly more sophisticated. Our approach has been used to generate views using charts, interactive graphs, interactive nested graphs, time-lines, spectrographs, interactive tree-maps and others. We are currently continuing our work by creating a complete library of visualization metamodels and model-driven visualization components. The metamodels will be included in Zooomm, the International Zoo of Metamodels, Schemas and Grammars. Model-based visualization components are also to being developed for integration within Eclipse using the EMF framework.
In this paper, Model Driven Engineering techniques have been applied in the context of softare visualization tools. The techniques presented here are not only applicable to software, but can be generalized to any information space. While GUI components found in traditional widget toolkits are well suited for visualizing small to medium, rather “flat” information, visualization tools are very good at exploring large datasets with complex structures. This paper shows how metamodels can be used for describing the structure of the visualization tool. Designing these metamodels is a difficult task, but once these models have been created, the explicit mappings between datasets and the model-based visualization components can be easily described. The work in this paper focusses on single visualization components, although we realize that software exploration requires combining and synchronizing multiple views. Clearly, sophisticated exploration environments in the future will only be achieved by integrating know-how from Software Exploration community, Model Driven Engineering community and the User Interface community.