EvoSpaces: 3D Visualization of Software ... - Semantic Scholar
EvoSpaces: 3D Visualization of Software Architecture Sazzadul Alam, Philippe Dugerdil HEG - Univ. of Applied Sciences, Geneva, Switzerland [email protected], [email protected] Abstract This paper presents the Evospaces reverse-engineering tool that represents the architecture and metrics of complex software systems in a 3D virtual world. The main goal of our project is to exploit familiar metaphors (analogical representations borrowed from another domain) and sophisticated interactions modes to help the user understand complex systems. First, we present the general architecture of the Evospaces tool. Second, we show the metaphors we have implemented to help the user to quickly get an overview of a complex system. Then we present the interaction mode we designed to let the user explore such a complex system. Finally, we show an example of a virtual space we have designed to represent the architecture of Mozilla. We conclude with an account of our current research directions. The main contributions of this paper are the metaphors that we have used and the types of interaction modes we have implemented. They represent a real contribution to the set of tools that can help a maintenance engineer to understand a large system such as Mozilla.
1. Introduction Since software is a formal and abstract construct, there is no “natural” representation for it. On the other hand a visual representation is an appealing way to represent lots of information simultaneously. Today’s industrial software systems are tremendously complex, with size counting in millions of lines of code. One way to cope with complexity is to represent information hierarchically in several levels of abstraction [17]. Fortunately, software systems are often structured hierarchically as systems, subsystems and components located in packages and/or directories. However containment information does not tell us much about the complexity of the contained elements. Then, metrics can be used to attach measures to the software elements. But metrics are most useful if one can compare their values among several components located in different parts of the system. Then, we must find ways to represent structural and metrics information on the system in the same visual space [10]. Moreover these visual representations should be easily interpretable
by the user, to let him decide what components to investigate further. However, if the unsophisticated display of a few dozen of classes in a diagram can provide some insight to the structure and behavior of a system, we must find way to meaningfully represent hundreds of classes or components. This is a complexity one cannot avoid for industrial-size systems. Although it is clear that a good drawing can replace a thousand words, it all depends on the drawing. Then, the central research questions are, first: how can we exploit familiar visual metaphors (analogical representations borrowed from domain of which the user has direct sensible experience) to help the user grasp a myriad of information in a single view? Second, how can we provide the user with powerful navigation and interaction techniques to let him dig the system and discover information as needed while staying aware of the context? Third, how can we meaningfully represent relationship between software objects? Our system basically rests on the representation of a 3D landscape in which the user can navigate and investigate software objects. It is implemented in Java and JOGL (OpenGL) [13] under Eclipse. As a test bench, we investigated the source code of Mozilla that contains about eleven thousand of files in its latest release. This paper is organized as follow. Section 2 presents the general architecture of our platform called “Evospaces”. Section 3 presents the interaction mechanisms with the virtual landcape we have built. Section 4 presents an example where Mozilla is displayed in a virtual world. As a conclusion, section 5 presents an outlook of the future work.
2. Evospaces tool architecture 2.1 Introduction To allow our tool to display systems written in different programming paradigms and to be able to quickly integrate new visualization metaphors we have built it in five layers (fig 1). Because of the well-defined interfaces between modules, changes made inside a given layer have a limited impact on the other layers. For example, the rendering engine will not be affected when changing the programming language of the program to
analyze provided it follows the same paradigm (object oriented for example).
2.2 Source code layer
on the type of the entity or relationship considered. The classes in the Database layer implement a generic access to the tables. Basically they consists of “builders” [6], that instantiate the objects representing entities and relationships.
This layer represents the raw source code of the software under investigation, structured as files. Those files are parsed off-line to fill the database of code elements. Since we do not know at parsing time what information the users will look for, we have chosen to extract as much structural information as possible from the source code. In particular, a set of widely used metrics is computed on the target system while the database is loaded. This layer is also used when displaying the source code corresponding to some selected element in the views.
Abstraction level
Rendering
The 3D engine that displays the virtual environment and let the user interact with it.
ModelView
Object model containing the elements to be displayed and the parameters of the visual representations.
Model
Object model representing source code elements with all the related information
Database of Code Elements
Raw data on the source code elements and precomputed metrics stored as database tables.
Source code
Source code of the analyzed software represented as files. This layer is external to our architecture. It is used to display the original source code of some selected element.
Figure 2. Source code data structure
2.3 Model layer The Model layer implements the object representation of the loaded entities and relationships in the Evospaces system. Each kind of entity or relationship is represented by its own class. Consequently, this layer contains two hierarchies of classes, one for the entities and one for the relationships, following the Famix metamodel for objectoriented programming languages [1]. For example, in figure 3, we show the Famix model for entities.
Figure 1. The Evospaces’ layered architecture
2.3 Database layer At the database level, the source code elements are represented in the entity - relationship paradigm. Elements like classes, methods, variables, attributes, packages, files or modules are entities. The way those entities are structured (containment relations and programminglanguage level relations), communicate or work together is represented as relationship. The database contains one table per software entity and one table per “relationships” between software entities. Then, at this level, the software under investigation is modeled as a huge entityrelationship diagram like the one presented in figure 2. Moreover, all entities and relationships have extra properties like source level information (names, labels, parameters) and metrics values. These properties depend
Figure 3. Famix model for entities
2.4 ModelView layer This layer is the first to deal with visualization issues. It contains all the values and parameters used for the 3D rendering of the entities and relationships. Each object in the ModelView layer has a counterpart in the Model layer. Then, the ModelView layer contains two hierarchies of classes, one for the entities and one for the relationships that are similar to the hierarchies in the Model layer. However the entities and the relationships of the ModelView layer only contain visualizable data. The ModelView layer works as a visual abstraction of the raw data stored in the model layer: it maps the data of the
model layer to displayable elements. In particular, this is where : • The glyphs (graphical objects representing data through visual parameters [1]) are mapped to a given type of entity or relationships; • The values of the metrics are mapped to some visual scale (saturation of colors for example) and positions in the 3D space (layout). Moreover since we wish our system to let us experiment with different representations of the same set of entities and relationships, a given entity or relationship in the Model layer may me mapped to different visual objects in the ModelView layer. This makes it possible to maintain several concurrent views of the same set of software elements. However, at any given time, only one view will be displayed. This layer, which represents the largest part of our system, also contains the classes that control the interaction with the user. Any entity or relationship in this layer is associated with four objects: a shape, a color, a layout and a list of “reactions” to user actions. The “shape” defines how the element will look like in the 3D view (the glyph). It can be as simple as a fixed size geometric volume, like a cube or a cylinder, or be a much more sophisticated visual element, using transparency effects and textures. The dimensions of the glyphs are set proportionally to the value of one or more metrics. Among the metaphors we experimented one of the most appealing is the modern city. Then, the classes and files are represented as buildings and the relationships as solid pipes between the buildings. On the other hands, metrics values intervals are mapped to different textures of buildings. For example, we split the files in three categories depending on their number of lines of code (LOC). Each category is represented by a different kind of building (different texture) (fig.4). In this example we used: • a house for files with 0 to 50 LOC; • an apartment block for files with 51 to 200 LOC; • an office building for files with more than 200 LOC; Morevoer we represented header files (.h) as a city hall with columns and a stickman for the functions and methods in classes and files.
House
Apartment block
Office building
Then, another metrics can be mapped to the height of the building. We then set the number of floors to represent the number of global variables declared in the file (fig 5). We also split the files in three categories according to their number of global variables: • small building for files with 0 or 1 variable; • medium size building for files with 2 to 4 variables; • tall building for files with 5 or more variables. On the other hand, the height of the city hall depends on the number of functions in the header file. (small: 0 to 5 functions, medium: 6 to 15 functions, tall: more than 15 function).
Figure 5. Mapping of metrics to the size The objects representing the entities are distributed in the 3D space using a specific topology (layout). For example we could arrange the entities in rows and columns, in concentric circles, in spiral, etc. Since the layout of the objects also conveys information, we must find a good map of the chosen metrics to the layout so that an intuitive interpretation is possible. In figure 6 we present two layouts among those we investigated. In the concentric layout (left), a possible mapping could be: the older the class the closer to the center. In the chessboard layout (right), the mapping could be the static coupling between classes: the closer the classes the tightly coupled.
Concentric
Chessboard
Figure 6. Examples of layouts Once visualized, the user can interact with the displayed objects. Each visual element has a list of potential actions that the user may perform on it. For example, the user could request to display the value of some metrics, to change the visual appearance the object, to load the related elements, to open the corresponding source file, etc. The list of possible actions is defined for each type of elements and is accessible through a contextual menu.
2.5 Rendering layer Stickman
City hall
Figure 4. Examples of Glyphs
All classes responsible for the actual display of the views on the screen are located in the Rendering layer.
The 3D rendering library used is JOGL [7], a binding of OpenGL for Java, which has been released by Sun for Windows, Solaris, Linux and Mac OS platforms. The rendering engine, which is responsible for the drawing of the 3D scene on the screen, uses the data stored in the ModelView objects. This engine also catches the actions of the user and executes the corresponding operations. The Rendering layer also implements some Eclipse plugin features, like a property page to specify the environment parameters for the Evospaces tool.
3. Interactions in the 3D view 3.1 Interaction with the visual objects So far, our investigations on the interactions modes with the tool went along three directions. First, we studied the way to display the information retrieved from the database and pertaining to a given element. Second we investigated the ways to dynamically change the viewing parameters of the entities and relationships in order to find the best metaphors for the software elements in given situation. Third we investigated the navigation among the displayed software elements. As a result we implemented a context sensitive menu in the 3D space. Almost all actions available for an element are accessible trough its contextual menu. For example, all the available metrics stored in the database for a given element can be represented as a table that is displayed by selecting an item in the contextual menu. On the other hand, the relationships between the elements are manifold. The user can then select the relationship he wants to display by selecting it in a preference window. Then, the relationship will be displayed on demand by clicking the element in the 3D view. The relationships are represented as a solid pipe between the associated elements (fig.7).
an information flow between the connected elements. The red segments drawn on the gray pipe in figure 7 are the moving segments that represent directionality. For any display element on the screen, the user can ask the system to display the corresponding source code using its contextual menu.
3.2 Interaction modes To set up and orient the camera in the 3D scene the user can use the buttons in a navigation panel (figure 8) or use their mouse and keyboard counterpart. Beyond the parameters of the camera, the navigation panel is used to select the relationship to display in the view and ask for the directionality of the relation to be “animated” (red segment moving).
Figure 8. The navigation panel
3.3 Zooming inside objects Since objects representing files of classes can contain other objects (methods and variables), the user can zoom into the objects to display their contents. Then the methods and functions, which are drawn as “Stickmen” of different colors, represent the “workforce” inside the buildings. Each stickmen is surrounded by yellow boxes (its resources) representing the local variables used by the method. Like for the buildings, the user can ask the system to display the relationships associated to a given method (figure 9)
Figure 9. Methods, variables and relationships inside a buildings
Figure 7: Relationships and directionality A colored segment moving along the pipe from the origin to the destination of the relation represents the directionality of the relation. This gives the impression of
If some relationship is displayed at the level of the methods, then it is also represented at the level of its containing building building when zooming out (Figure 10).
C++ files of Mozilla as a huge city. They are distributed on a grid layout according to the containment metrics (files in the same package are displayed close to each other).
Figure 10. Relationship between buildings
3.4 Navigating the city with a road map When travelling in a big and unknown city, it is easy to get lost. Better to have a map handy. In the Evospaces system, such a map can be displayed in one of the corners of the screen to show the user his current position in the city (Figure 11). Unlike real paper maps, the user can zoom into this road map to show it at different scales. This idea has been borrowed from the computer game technology where the user can display “radar views” to get a global awareness of the environment. In this figure we also display the name of the software elements as labels attached to the buildings.
Figure 12. Mozilla as a huge city In Figure 13 we show the contextual menu associated to an object. Through this menu we asked for the display of the values for all the metrics associated to the object. They are displayed as a table on the left of the view.
Figure 13. Displaying the values for all the metrics
6. Related work Figure 11: The file city and its road map.
5. Visualizing and navigating Mozilla’s city As an experiment, we displayed the source code of Mozilla, which is written in C/C++. The parsing and loading of the database has been done as part of another project [15]. Since all the versions of Mozilla are accessible, they have also been stored in the database. We then adapted the Database layer to access it. In its latest release, Mozilla contains more than thirty thousands methods, three thousands classes located in more than two thousands of files. In figure 12 we present the header and
Graphical representations of software have long been accepted as comprehension aids. Many tools enable the user to visualize software using static information, e.g., Rigi [12] , Hy+ [1], SeeSoft [4] , or ShrimpViews [18]. The PolymetricViews system of Lanza [11] was a first step in presenting multiple metrics on the same 2D view. On the other hand Chuah and Eick [1] were among the firsts to use sophisticated glyphs to represent complex information on software objects. The use of 3D views to represent software architecture has been advocated by Feijs L. and De Jongin [5]. However they focused on the representation of the relations between modules, themselves represented as Lego bricks distributed in the
3D space. They did not investigate the use of “familiar” metaphors such as the city. The idea of the city metaphor to represent software objects has been proposed recently by Panas [14]. But, in this work the views are static i.e. non navigable. Then, the quantity of information that can be represented is limited. Langelier et al. [9] presented a visualization of software quality made of 3D boxes representing classes, whose dimensions are mapped to quality metrics. But they did not exploit the city metaphor to ease the interpretation of the view nor did they implement the “vertical” navigation inside the boxes to show their contents. Finally, they did not investigate the visualization of the relationships between the classes. On the other hand 3D visualizations have been used by Jazayeri et al. [8] to represent version and release information of software systems. Recently Pinzger et al. showed the use of 2D Kiviat diagrams also to represent software evolution [16]. The latter is a dimension of software systems that we have not yet investigated nor represented. However, since the database we are using contains all the releases of Mozilla, we will display this information in the future.
7. Conclusions and future work In this paper we presented the Evospaces reverseengineering tool, which allows its users to investigate large software systems by navigating through a virtual city in a 3D space. The main contribution of this paper is in the use of the “familiar” city metaphor with buildings and people, the mapping of metrics value categories to the texture of the buildings and the navigation mode we implemented. In particular we showed how objects could be zoomed in to represent their contents as “workers”. We also showed the use of pipes with a simulation of the flow of information to represent the relationships with their directionality. Then we presented the idea of the “road map” to keep the user informed of his global position when traveling the city. Finally we showed how these 3D techniques could be used to represent a substantial part of a very large system such as Mozilla. Our current work concentrates on the representation of the dynamic information on a system (i.e. its working). We are then looking for supplementary metaphors to represent the interactions (the traffic) in between buildings when objects are sending messages to each other.
8. Acknowledgements We gratefully acknowledge the financial support of the Hasler Foundation for the “Evospaces – Multidimensional navigation spaces for software evolution (project MMI-1976).
9. References [1] Chuah, M. C., Eick, S. G. - Information rich glyphs for software management data. IEEE Computer Graphics and Applications, July1998. [2] Consens, M. P., Mendelzon, A. O. - Hy+: A hygraphbased query and visualisation system. In Proc. of the ACM SIGMOD Int. Conf. on Management Data, SIGMOD Record Volume 22, No. 2, 511–516, 1993. [3] Demeyer S., Tichelaar S., and Ducasse S. - FAMIX 2.1 — The FAMOOS Information Exchange Model. Technical report, University of Bern, 2001 [4] Eick, S. C., Steffen, J. L., Summer E. - Seesoft - a tool for visualizing line oriented software statistics. IEEE Trans. on Soft. Engineering 18(1), Nov. 1992 [5] Feijs L., De Jongin R. – 3D Visualizations of Software Architectures. CACM 41(12), Dec. 1998. [6] Gamma E., Helm R., Johnson R., Vlissides J. – Design Patterns. Elements of Reusable Object Oriented Software. Addison-Wesley Inc. 1995. [7] Java binding for OpenGL, https://jogl.dev.java.net/ [8] Jazayeri M., Gall H., Riva C. - Visualizing software release histories: The use of color and third dimension. Proc. IEEE Int. Conf. on Software Maintenance. ICSM, 1999. [9] Langelier, G., Sahraoui, H., and Poulin, P. Visualization-based analysis of quality for large-scale software systems. In Proc. of the IEEE Int. Conf. on Automated Software Engineering ASE '05. 2005 [10] Lanza M. - Object-Oriented Reverse Engineering. PhD Thesis, Univ. of Bern, Switzerland, May 2003. [11] Lanza M., Ducasse S. – Polymetric Views – A Lightweight Visual Approach to Reverse Engineering. IEEE Trans. on Software Engineering 29(9):782-795, Sept.2003. [12] Mueller, H. A. - Rigi - A Model for Software System Construction, Integration, and Evaluation based on Module Interface Specifications. PhD thesis, Rice University. 1986 [13] www.opengl.org [14] Panas Th. - A Framework for Reverse Engineering, PhD Thesis, Växjö University, Dec. 2005 [15] Pinzger M. - ArchView : Analyzing Evolutionary Aspects of Complex Software Systems, PhD Thesis , Vienna Univ. of Technology, May 2005. [16] Pinzger M., Gall M., Fischer M., Lanza M. Visualizing multiple evolution metrics. Proc. of the ACM symposium on Software visualization 2005. [17] Simon H.A. - The architecture of complexity. In: The Sciences of the Artificial, MIT Press, 1969. [18] Storey, M.-A. D., Mueller, H. A. - Manipulating and documenting software structures using shrimp views. In Proc. IEEE Int. Conf. on Soft. Maintenance, ICSM, 1995.
1. Introduction Since software is a formal and abstract construct, there is no “natural” representation for it. On the other hand a visual representation is an appealing way to represent lots of information simultaneously. Today’s industrial software systems are tremendously complex, with size counting in millions of lines of code. One way to cope with complexity is to represent information hierarchically in several levels of abstraction [17]. Fortunately, software systems are often structured hierarchically as systems, subsystems and components located in packages and/or directories. However containment information does not tell us much about the complexity of the contained elements. Then, metrics can be used to attach measures to the software elements. But metrics are most useful if one can compare their values among several components located in different parts of the system. Then, we must find ways to represent structural and metrics information on the system in the same visual space [10]. Moreover these visual representations should be easily interpretable
by the user, to let him decide what components to investigate further. However, if the unsophisticated display of a few dozen of classes in a diagram can provide some insight to the structure and behavior of a system, we must find way to meaningfully represent hundreds of classes or components. This is a complexity one cannot avoid for industrial-size systems. Although it is clear that a good drawing can replace a thousand words, it all depends on the drawing. Then, the central research questions are, first: how can we exploit familiar visual metaphors (analogical representations borrowed from domain of which the user has direct sensible experience) to help the user grasp a myriad of information in a single view? Second, how can we provide the user with powerful navigation and interaction techniques to let him dig the system and discover information as needed while staying aware of the context? Third, how can we meaningfully represent relationship between software objects? Our system basically rests on the representation of a 3D landscape in which the user can navigate and investigate software objects. It is implemented in Java and JOGL (OpenGL) [13] under Eclipse. As a test bench, we investigated the source code of Mozilla that contains about eleven thousand of files in its latest release. This paper is organized as follow. Section 2 presents the general architecture of our platform called “Evospaces”. Section 3 presents the interaction mechanisms with the virtual landcape we have built. Section 4 presents an example where Mozilla is displayed in a virtual world. As a conclusion, section 5 presents an outlook of the future work.
2. Evospaces tool architecture 2.1 Introduction To allow our tool to display systems written in different programming paradigms and to be able to quickly integrate new visualization metaphors we have built it in five layers (fig 1). Because of the well-defined interfaces between modules, changes made inside a given layer have a limited impact on the other layers. For example, the rendering engine will not be affected when changing the programming language of the program to
analyze provided it follows the same paradigm (object oriented for example).
2.2 Source code layer
on the type of the entity or relationship considered. The classes in the Database layer implement a generic access to the tables. Basically they consists of “builders” [6], that instantiate the objects representing entities and relationships.
This layer represents the raw source code of the software under investigation, structured as files. Those files are parsed off-line to fill the database of code elements. Since we do not know at parsing time what information the users will look for, we have chosen to extract as much structural information as possible from the source code. In particular, a set of widely used metrics is computed on the target system while the database is loaded. This layer is also used when displaying the source code corresponding to some selected element in the views.
Abstraction level
Rendering
The 3D engine that displays the virtual environment and let the user interact with it.
ModelView
Object model containing the elements to be displayed and the parameters of the visual representations.
Model
Object model representing source code elements with all the related information
Database of Code Elements
Raw data on the source code elements and precomputed metrics stored as database tables.
Source code
Source code of the analyzed software represented as files. This layer is external to our architecture. It is used to display the original source code of some selected element.
Figure 2. Source code data structure
2.3 Model layer The Model layer implements the object representation of the loaded entities and relationships in the Evospaces system. Each kind of entity or relationship is represented by its own class. Consequently, this layer contains two hierarchies of classes, one for the entities and one for the relationships, following the Famix metamodel for objectoriented programming languages [1]. For example, in figure 3, we show the Famix model for entities.
Figure 1. The Evospaces’ layered architecture
2.3 Database layer At the database level, the source code elements are represented in the entity - relationship paradigm. Elements like classes, methods, variables, attributes, packages, files or modules are entities. The way those entities are structured (containment relations and programminglanguage level relations), communicate or work together is represented as relationship. The database contains one table per software entity and one table per “relationships” between software entities. Then, at this level, the software under investigation is modeled as a huge entityrelationship diagram like the one presented in figure 2. Moreover, all entities and relationships have extra properties like source level information (names, labels, parameters) and metrics values. These properties depend
Figure 3. Famix model for entities
2.4 ModelView layer This layer is the first to deal with visualization issues. It contains all the values and parameters used for the 3D rendering of the entities and relationships. Each object in the ModelView layer has a counterpart in the Model layer. Then, the ModelView layer contains two hierarchies of classes, one for the entities and one for the relationships that are similar to the hierarchies in the Model layer. However the entities and the relationships of the ModelView layer only contain visualizable data. The ModelView layer works as a visual abstraction of the raw data stored in the model layer: it maps the data of the
model layer to displayable elements. In particular, this is where : • The glyphs (graphical objects representing data through visual parameters [1]) are mapped to a given type of entity or relationships; • The values of the metrics are mapped to some visual scale (saturation of colors for example) and positions in the 3D space (layout). Moreover since we wish our system to let us experiment with different representations of the same set of entities and relationships, a given entity or relationship in the Model layer may me mapped to different visual objects in the ModelView layer. This makes it possible to maintain several concurrent views of the same set of software elements. However, at any given time, only one view will be displayed. This layer, which represents the largest part of our system, also contains the classes that control the interaction with the user. Any entity or relationship in this layer is associated with four objects: a shape, a color, a layout and a list of “reactions” to user actions. The “shape” defines how the element will look like in the 3D view (the glyph). It can be as simple as a fixed size geometric volume, like a cube or a cylinder, or be a much more sophisticated visual element, using transparency effects and textures. The dimensions of the glyphs are set proportionally to the value of one or more metrics. Among the metaphors we experimented one of the most appealing is the modern city. Then, the classes and files are represented as buildings and the relationships as solid pipes between the buildings. On the other hands, metrics values intervals are mapped to different textures of buildings. For example, we split the files in three categories depending on their number of lines of code (LOC). Each category is represented by a different kind of building (different texture) (fig.4). In this example we used: • a house for files with 0 to 50 LOC; • an apartment block for files with 51 to 200 LOC; • an office building for files with more than 200 LOC; Morevoer we represented header files (.h) as a city hall with columns and a stickman for the functions and methods in classes and files.
House
Apartment block
Office building
Then, another metrics can be mapped to the height of the building. We then set the number of floors to represent the number of global variables declared in the file (fig 5). We also split the files in three categories according to their number of global variables: • small building for files with 0 or 1 variable; • medium size building for files with 2 to 4 variables; • tall building for files with 5 or more variables. On the other hand, the height of the city hall depends on the number of functions in the header file. (small: 0 to 5 functions, medium: 6 to 15 functions, tall: more than 15 function).
Figure 5. Mapping of metrics to the size The objects representing the entities are distributed in the 3D space using a specific topology (layout). For example we could arrange the entities in rows and columns, in concentric circles, in spiral, etc. Since the layout of the objects also conveys information, we must find a good map of the chosen metrics to the layout so that an intuitive interpretation is possible. In figure 6 we present two layouts among those we investigated. In the concentric layout (left), a possible mapping could be: the older the class the closer to the center. In the chessboard layout (right), the mapping could be the static coupling between classes: the closer the classes the tightly coupled.
Concentric
Chessboard
Figure 6. Examples of layouts Once visualized, the user can interact with the displayed objects. Each visual element has a list of potential actions that the user may perform on it. For example, the user could request to display the value of some metrics, to change the visual appearance the object, to load the related elements, to open the corresponding source file, etc. The list of possible actions is defined for each type of elements and is accessible through a contextual menu.
2.5 Rendering layer Stickman
City hall
Figure 4. Examples of Glyphs
All classes responsible for the actual display of the views on the screen are located in the Rendering layer.
The 3D rendering library used is JOGL [7], a binding of OpenGL for Java, which has been released by Sun for Windows, Solaris, Linux and Mac OS platforms. The rendering engine, which is responsible for the drawing of the 3D scene on the screen, uses the data stored in the ModelView objects. This engine also catches the actions of the user and executes the corresponding operations. The Rendering layer also implements some Eclipse plugin features, like a property page to specify the environment parameters for the Evospaces tool.
3. Interactions in the 3D view 3.1 Interaction with the visual objects So far, our investigations on the interactions modes with the tool went along three directions. First, we studied the way to display the information retrieved from the database and pertaining to a given element. Second we investigated the ways to dynamically change the viewing parameters of the entities and relationships in order to find the best metaphors for the software elements in given situation. Third we investigated the navigation among the displayed software elements. As a result we implemented a context sensitive menu in the 3D space. Almost all actions available for an element are accessible trough its contextual menu. For example, all the available metrics stored in the database for a given element can be represented as a table that is displayed by selecting an item in the contextual menu. On the other hand, the relationships between the elements are manifold. The user can then select the relationship he wants to display by selecting it in a preference window. Then, the relationship will be displayed on demand by clicking the element in the 3D view. The relationships are represented as a solid pipe between the associated elements (fig.7).
an information flow between the connected elements. The red segments drawn on the gray pipe in figure 7 are the moving segments that represent directionality. For any display element on the screen, the user can ask the system to display the corresponding source code using its contextual menu.
3.2 Interaction modes To set up and orient the camera in the 3D scene the user can use the buttons in a navigation panel (figure 8) or use their mouse and keyboard counterpart. Beyond the parameters of the camera, the navigation panel is used to select the relationship to display in the view and ask for the directionality of the relation to be “animated” (red segment moving).
Figure 8. The navigation panel
3.3 Zooming inside objects Since objects representing files of classes can contain other objects (methods and variables), the user can zoom into the objects to display their contents. Then the methods and functions, which are drawn as “Stickmen” of different colors, represent the “workforce” inside the buildings. Each stickmen is surrounded by yellow boxes (its resources) representing the local variables used by the method. Like for the buildings, the user can ask the system to display the relationships associated to a given method (figure 9)
Figure 9. Methods, variables and relationships inside a buildings
Figure 7: Relationships and directionality A colored segment moving along the pipe from the origin to the destination of the relation represents the directionality of the relation. This gives the impression of
If some relationship is displayed at the level of the methods, then it is also represented at the level of its containing building building when zooming out (Figure 10).
C++ files of Mozilla as a huge city. They are distributed on a grid layout according to the containment metrics (files in the same package are displayed close to each other).
Figure 10. Relationship between buildings
3.4 Navigating the city with a road map When travelling in a big and unknown city, it is easy to get lost. Better to have a map handy. In the Evospaces system, such a map can be displayed in one of the corners of the screen to show the user his current position in the city (Figure 11). Unlike real paper maps, the user can zoom into this road map to show it at different scales. This idea has been borrowed from the computer game technology where the user can display “radar views” to get a global awareness of the environment. In this figure we also display the name of the software elements as labels attached to the buildings.
Figure 12. Mozilla as a huge city In Figure 13 we show the contextual menu associated to an object. Through this menu we asked for the display of the values for all the metrics associated to the object. They are displayed as a table on the left of the view.
Figure 13. Displaying the values for all the metrics
6. Related work Figure 11: The file city and its road map.
5. Visualizing and navigating Mozilla’s city As an experiment, we displayed the source code of Mozilla, which is written in C/C++. The parsing and loading of the database has been done as part of another project [15]. Since all the versions of Mozilla are accessible, they have also been stored in the database. We then adapted the Database layer to access it. In its latest release, Mozilla contains more than thirty thousands methods, three thousands classes located in more than two thousands of files. In figure 12 we present the header and
Graphical representations of software have long been accepted as comprehension aids. Many tools enable the user to visualize software using static information, e.g., Rigi [12] , Hy+ [1], SeeSoft [4] , or ShrimpViews [18]. The PolymetricViews system of Lanza [11] was a first step in presenting multiple metrics on the same 2D view. On the other hand Chuah and Eick [1] were among the firsts to use sophisticated glyphs to represent complex information on software objects. The use of 3D views to represent software architecture has been advocated by Feijs L. and De Jongin [5]. However they focused on the representation of the relations between modules, themselves represented as Lego bricks distributed in the
3D space. They did not investigate the use of “familiar” metaphors such as the city. The idea of the city metaphor to represent software objects has been proposed recently by Panas [14]. But, in this work the views are static i.e. non navigable. Then, the quantity of information that can be represented is limited. Langelier et al. [9] presented a visualization of software quality made of 3D boxes representing classes, whose dimensions are mapped to quality metrics. But they did not exploit the city metaphor to ease the interpretation of the view nor did they implement the “vertical” navigation inside the boxes to show their contents. Finally, they did not investigate the visualization of the relationships between the classes. On the other hand 3D visualizations have been used by Jazayeri et al. [8] to represent version and release information of software systems. Recently Pinzger et al. showed the use of 2D Kiviat diagrams also to represent software evolution [16]. The latter is a dimension of software systems that we have not yet investigated nor represented. However, since the database we are using contains all the releases of Mozilla, we will display this information in the future.
7. Conclusions and future work In this paper we presented the Evospaces reverseengineering tool, which allows its users to investigate large software systems by navigating through a virtual city in a 3D space. The main contribution of this paper is in the use of the “familiar” city metaphor with buildings and people, the mapping of metrics value categories to the texture of the buildings and the navigation mode we implemented. In particular we showed how objects could be zoomed in to represent their contents as “workers”. We also showed the use of pipes with a simulation of the flow of information to represent the relationships with their directionality. Then we presented the idea of the “road map” to keep the user informed of his global position when traveling the city. Finally we showed how these 3D techniques could be used to represent a substantial part of a very large system such as Mozilla. Our current work concentrates on the representation of the dynamic information on a system (i.e. its working). We are then looking for supplementary metaphors to represent the interactions (the traffic) in between buildings when objects are sending messages to each other.
8. Acknowledgements We gratefully acknowledge the financial support of the Hasler Foundation for the “Evospaces – Multidimensional navigation spaces for software evolution (project MMI-1976).
9. References [1] Chuah, M. C., Eick, S. G. - Information rich glyphs for software management data. IEEE Computer Graphics and Applications, July1998. [2] Consens, M. P., Mendelzon, A. O. - Hy+: A hygraphbased query and visualisation system. In Proc. of the ACM SIGMOD Int. Conf. on Management Data, SIGMOD Record Volume 22, No. 2, 511–516, 1993. [3] Demeyer S., Tichelaar S., and Ducasse S. - FAMIX 2.1 — The FAMOOS Information Exchange Model. Technical report, University of Bern, 2001 [4] Eick, S. C., Steffen, J. L., Summer E. - Seesoft - a tool for visualizing line oriented software statistics. IEEE Trans. on Soft. Engineering 18(1), Nov. 1992 [5] Feijs L., De Jongin R. – 3D Visualizations of Software Architectures. CACM 41(12), Dec. 1998. [6] Gamma E., Helm R., Johnson R., Vlissides J. – Design Patterns. Elements of Reusable Object Oriented Software. Addison-Wesley Inc. 1995. [7] Java binding for OpenGL, https://jogl.dev.java.net/ [8] Jazayeri M., Gall H., Riva C. - Visualizing software release histories: The use of color and third dimension. Proc. IEEE Int. Conf. on Software Maintenance. ICSM, 1999. [9] Langelier, G., Sahraoui, H., and Poulin, P. Visualization-based analysis of quality for large-scale software systems. In Proc. of the IEEE Int. Conf. on Automated Software Engineering ASE '05. 2005 [10] Lanza M. - Object-Oriented Reverse Engineering. PhD Thesis, Univ. of Bern, Switzerland, May 2003. [11] Lanza M., Ducasse S. – Polymetric Views – A Lightweight Visual Approach to Reverse Engineering. IEEE Trans. on Software Engineering 29(9):782-795, Sept.2003. [12] Mueller, H. A. - Rigi - A Model for Software System Construction, Integration, and Evaluation based on Module Interface Specifications. PhD thesis, Rice University. 1986 [13] www.opengl.org [14] Panas Th. - A Framework for Reverse Engineering, PhD Thesis, Växjö University, Dec. 2005 [15] Pinzger M. - ArchView : Analyzing Evolutionary Aspects of Complex Software Systems, PhD Thesis , Vienna Univ. of Technology, May 2005. [16] Pinzger M., Gall M., Fischer M., Lanza M. Visualizing multiple evolution metrics. Proc. of the ACM symposium on Software visualization 2005. [17] Simon H.A. - The architecture of complexity. In: The Sciences of the Artificial, MIT Press, 1969. [18] Storey, M.-A. D., Mueller, H. A. - Manipulating and documenting software structures using shrimp views. In Proc. IEEE Int. Conf. on Soft. Maintenance, ICSM, 1995.
