SourceMiner - User Guide

(1)

glccarneiro@gmail.com

SourceMiner - User Guide

(2)

Figures

Figure 1: Eclipse's Plugin folder...6

Figure 2: Launching SourceMiner ...6

Figure 3: Opening SourceMiner’s views...7

Figure 4: The Proposed Infrastructure...8

Figure 6: Treemaps View ...13

Figure 7: Treemaps View Menu...14

Figure 8: Polymetric View...15

Figure 10: Dependency View Menu ...17

Figure 11: Class Dependency View ...18

Figure 14: Efferent Coupling of Selected Node in the Class Dependency View ...19

Figure 15: Package Dependency View ...20

Figure 16: Changing the center ...20

Figure 17: Grid View in the Dependency Strength Perspective ...21

Figure 18: Grid View Menu ...21

Figure 19: Spiral Egocentric Dependency Graph in the Dependency Strength Perspective ...22

Figure 20: Spiral Egocentric Dependency Graph Menu ...22

Figure 21: Range Slider Filters ...24

Figure 23: Range Slider Filters ...24

Figure 24: Colors in the Treemaps View...26

Figure 25: Colors in the Polymetric View...26

Figure 26: Colors in the Dependency View ...26

Figura 27: Colors in the Grid View...26

Figura 28: Concern Filter ...26

Figura 29: Concerns in the Grid View ...27

Figure 30: Concerns in the Class Dependency View ...27

Figura 31: Concerns in the Polymetric (a) and the Treemaps (b) View ....28

Figure 32: Concerns in the Spiral Egocentric Graph View ...28

Figure 33: ...28

Figure 34 ...29

(4)

Tables

Table 1: Perspectives and their respective views ...10

(5)

1. Installing SourceMiner

Firstly, you should download the last version of the Eclipse IDE for Java Developers available at http://www.eclipse.org/downloads/.

Secondly, you should install the ConcernMapper plug-in developed by Martin Robillard at McGill University. ConcernMapper provides ways to keep track of all the code related to concerns, providing a xml record of the subset of a software system associated to different concerns. In case you want more detailed information about ConcernMapper, visit its website at http://www.cs.mcgill.ca/~martin/cm/. To install it, please follow the instructions below:

• From the Eclipse menu bar, select Help | Software Updates

| Find and Install...

• Select "Search for new features to install" and click Next >

• Click on the New Remote Site... button.

• For the name, enter "ConcernMapper". For the URL, enter

"http://www.cs.mcgill.ca/~martin/cm", and click OK

• Select the new ConcernMapper entry in the list and click Finish

• In the list of features to install, select the root node of the ConcernMapper tree, and click Next.

• Select that you accept the terms of the license agreement, and click Next.

• Click Finish, and then Install.

• Restart your Eclipse.

The next step is to open ConcernMapper and use its functionalities as suggested bellow:

• Open the Java perspective.

• Select Window | Reset Perspective. The ConcernMapper View will appear.

• In the Package Explorer, open the project under analysis and select the file “/Mobile Media0X/Concern Mobile Media0X_OO.cm”. Where “X” is the number of the version under analysis.

• Drag and drop this file to the ConcernMapper View. All the concerns previously mapped will be presented in this view. The Package Explorer and Outline views are now updated and also

(6)

present the concerns along with the software entities that they affect.

Finally, you are ready to install SourceMiner. You should copy the jar file org.gesa.sourceminer_2.17.0.jar and copy it to your Eclipse´s “plugins”

folder (Figure 1).

Figure 1: Eclipse's Plugin folder

You are now ready to launch SourceMiner:

• (Re-)Start your Eclipse.

• In the Package Explorer, select and open a Java project you want to analyze with SourceMiner. Note that this step should be executed whenever you want to visualize a project with SourceMiner. Currently, SourceMiner can work on one project at a time.

• Right-click on the project “Visualize with SourceMiner” (Figure 2)

Figure 2: Launching SourceMiner

Once SourceMiner finish the analyses of the selected project, follow the sequence Window Show View Other SourceMiner and select all

(7)

the available views and press OK. The Figure 3 illustrates how to open the views.

Figure 3: Opening SourceMiner’s views

The available views are: TreeMap View, Polymetric View, Dependency View (that consist in Package and Class Dependency Views), Grid View (Grid and Egocentric graph views), Concern Filter View, and Filters View.

2. A Multi-Perspective Software Visualization Tool

SourceMiner is an Eclipse plug-in that uses non conventional visual metaphors to bring forward useful information from the source code to programmers. With SourceMiner, programmers can explore source code information following the three-step process: overview first, zoom and filter, then details on-demand (which has been called the Information Seeking Mantra [21]). First, programmers need to get an overview of the source code. In the overview, they identify interesting patterns or groups in the code and focuses on them. For analyzing the patterns, programmers need to drill down and access details of the code.

SourceMiner provides you resources to execute these three steps of the information seeking mantra. To further explore the interesting subsets, programmers may use a drill-down capability in order to observe the details about the code. SourceMiner intends not only to provide the

(8)

base visualization resources for all three steps but also bridges the gaps between them.

The views were carefully crafted to convey software entities and their relationships as visual attributes that can be easily recognized. The information provided by the combined use of these views help programmers to handle broad spectrum of software comprehension activities. The views are enriched with filtering, concern mapping, zooming, navigation, and drill-down capabilities to provide better software comprehension resources to the programmer.

3. The Perspectives

SourceMiner uses in its perspectives four key underlying principles to software comprehension: the software package-class-method structure, the inheritance hierarchy, the dependency and the dependency strength. Figure 4 presents them.

In accordance with [22], programmers can configure intuitive views from multiple task-relevant perspectives. A perspective relies on a specific kind of visualization technique that intuitively reveals relationships among software entities. A perspective should address and facilitate a series of tasks, not just one in particular.

Sourceminer provides the following perspectives: the software package- class-method structure, the software inheritance hierarchy, the software dependency and the software dependency strength:

Software Visualization Domain

View(s) to Address the Perspective for Software

Package-Class-Method Structure Treemaps

Polymetric

Package Graphs

Grid

Inheritance Hierarchy

Dependency

Dependency Strength

(C)

Model View Mapping

Polymetric Treemaps

Grid and Egocentric Graph

(B)

Graphs

Software Analysis Domain

Java Source Code AST provided by Eclipse

(A)

Egocentric Graph Class Graphs

(B.1)

(B.2)

Figure 4: The Proposed Infrastructure

(9)

Figure 5: The Map of Concepts and their Relationships

a) The software package-class-method perspective is related to structural representation (Figure 5). It deals with module hierarchy and how they are organized in packages, classes and methods. Important in this perspective is the representation of metrics such as size and cyclomatic complexity of software modules [7]. These two metrics are suitable to enrich the high-level organization of Java package-class- method hierarchies that are better suited for software architecture visualizations.

b) The software inheritance hierarchy perspective is related to data abstraction (Figure 5) [6]. The inheritance in object-oriented programming uses concepts of generalizations and specialization to organize abstraction, better distribute functionalities, and to foster polymorphism [1], and code reuse [2].

c) The software dependency perspective addresses the issue of module coupling (Figure 5). The SE community has presented coupling as one of the essential perspectives of software complexity [3]. The core of the object-oriented paradigm is based on objects that encapsulate data to reduce coupling [4]. This perspective aims at addressing module coupling from the perspective of the existence of relationships and its overall structure.

d) The software dependency strength perspective addresses the issue of module coupling from a different point of view. It complements the software dependency with information regarding the degree of coupling among modules (Figure 5). The excessive inter-module

(10)

dependencies have long been recognized as an indicator of poor software design [5]. Highly coupled systems, those in which modules have unnecessary dependencies, are hard to work with. They are not easy to understand, change and extend in isolation [5].

The combined use of these perspectives provides a broad range of information to programmers to execute development and maintenance tasks. A wide range of visual paradigms from the information and software visualization domains were analyzed to appropriately convey the information of each perspective. The goal of this work was to adopt an effective combination of metaphors to represent each of the perspectives. The infrastructure ended-up adopting the visual paradigms as presented in Table 1: (i) treemaps [8] for the package-class-method perspective; (ii) the polymetric views [6] for the inheritance hierarchy perspective; (iii) class and package node-link-based dependency graphs [9] for the dependency perspective; and (iv) grids combined with node-link-based egocentric graphs for the dependency strength perspective.

Table 1: Perspectives and their respective views

Perspective View(s)

Package-class-method structure

TreeMaps

Inheritance hierarchy Polymetric Views

Package and class

dependency

Package and Class Dependency Graphs

Class dependency strength Grids and Spiral Egocentric Graphs

All the views required adapting and redesigning activities. In the case of the polymetric view, the metaphor was already being used in software visualization for the aforementioned perspective. This required only the reimplementation of the metaphor for the SourceMiner infrastructure. In other cases, such as the treemap and the dependency graph, the metaphors were being used mostly in the information visualization domain. They had to be adapted for the software visualization domain and the task at hand. This will be explained in this section in the mapping

(11)

software attributes to visual attributes paragraphs. In the case of the dependence strength perspective, the metaphors themselves had to be designed for the task at hand.

3.1. A Visual Metaphor for the Software Package-Class-Method Structure Perspective

In case of the package-class-method structural perspective, the infrastructure adopted treemaps [8] as its view ((c)). A treemap is a space-filling visualization method capable of representing large hierarchical collections of quantitative data. It is a 2D visualization that maps a tree structure into rectangles with each rectangle representing a node. Treemaps are very effective in showing node attributes using size (area) and color and they enable users to compare nodes and sub trees at varying depths in the tree. Treemaps furthermore facilitate the discovery of patterns and outliers [8].

Originally designed to visualize files on a hard drive, treemaps have been applied to a wide variety of domains ranging from financial analysis [11]

to sports reporting [10]. Treemaps are especially useful to represent the software package-class-method structure. They are well suited to represent hierarchies and can show many items in one screen shot. It is also very easy to navigate in its hierarchy. Programmers can move from the highest to the lowest level of module abstraction without getting disoriented in the process. Internal treemap rectangles correspond to child nodes and are visualized by recursively subdividing the containing rectangle. The rectangles generated by the squarification algorithm approximate squares, which are easier to compare and select [8].

Furthermore, nested rectangles are represented to provide a better insight in the structure and depth of the hierarchy.

(12)

Figure 6(a): The Editor and Outline View

Figure 6(b): The package Explorer View

Mapping Software Attributes to Visual Attributes

The attributes that are relevant to the package-class-method structure are: the structure of packages, classes and methods itself, and their name and size. Package Explorer and Outline traditionally present these information (Figures 6(a) and 6(b)). However, these views do not provide information about metrics such as size and cyclomatic complexity. In treemap, packages classes and methods are represented as nested rectangles, where the innermost rectangles are methods and the outermost rectangles are packages (Figure 6(c)). Using this metaphor, methods that are together in the same class are represented in the same rectangle. Likewise, classes that are in a specific package are represented in the rectangle, and so on so forth. A single screen shot can represent all methods, classes and interfaces in accordance with its position in the structure. Besides the nested sequence of rectangles,

(13)

other visual attributes such as the rectangles’ area and color are also used to represent software attributes.

Figure 6(c): Treemaps View

Figure 7: Treemaps View Menu

The size and color of each rectangle can represent, for example, the size and complexity of each method (as presented in the Area and Color Menu in Figure 7). As a result, the size of a class will be the sum of its methods’ area whereas the size of a package will be the sum of its classes’ area.

A conceptual zoom is available to display selected packages, classes or methods of the project under analysis. This can be useful to spot anomalies related to module’s size, complexity and number of sub- modules. You can use both zoom in and out functionalities. You just need to select an area of the treemap and click with the left button at the

(14)

point where you want to zoom in. You can repeat that until the method level. To zoom out you should do the same with the right button of the mouse until the project level.

3.2. A Visual Metaphor for the Software Inheritance Hierarchy Perspective

The Polymetric View [6] is the visual metaphor used to represent the software inheritance hierarchy. Originally proposed as a lightweight software visualization technique enriched with software metrics information, polymetric views help to understand the structure and detect problems of a software system in the initial phases of a reverse engineering process [6]. Polymetric is particularly efficient to represent inheritance trees that comprise the software system.

As seen in Figure 9, the Polymetric View is a two-dimensional display that uses rectangles to represent software entities, such as classes and interfaces, and edges to represent inheritance relationships between them. The rectangles’ dimensions are used to represent properties of the entities. In SourceMiner, the width corresponds to the number of methods while the height to the number of lines of code of a class or interface.

The color indicates the element type, i.e., whether the element is an external class, an abstract class, an internal class, a common class, an enumeration or an interface. A geometric zoom is available to better display the polymetric view in accordance with the project under analysis (Figure 9).

3.3. A Visual Metaphor for the Software Dependency Perspective

Graphs, composed of objects (nodes) and relations (links), are one of the most commonly used structures in computer science. A simple way to determine the applicability of graph visualization is to consider the following question: Is there an inherent relation among the data elements to be visualized? If the answer to the question is “yes”, then the data can be represented by the nodes of a graph, with the edges representing the relations [23].

(15)

Figure 8: Polymetric View

Figure 9: Polymetric View Menu

Graphs can be used to configure appropriated visual scenarios to spot coupling relationships that are hidden. For this reason, it is a suitable structure to represent dependency among software modules. However, as soon as the size of the graph and the link density increases, node-link graphs face occlusion problems due to link overlapping. Thus, it becomes difficult for programmers to visually explore the graph and interact with its elements (Figure 10) [12]. To tackle this problem, the visual metaphor should provide interactive resources to paint the relationships in accordance with the criteria configured by the user. This will limit the number of nodes and links to be visualized, thus reducing the occlusion occurrences. Programmers may choose to present the graph based on the type of dependency (object, method, field, inheritance, interface implementation, interface inheritance – see menu of type of dependency in Figure 10). Moreover, programmers can select and

(16)

deselect specific nodes and visualize their coupling based on the dependency directions:

• Afferent coupling of selected nodes: which nodes depend on the selected ones (see menu of dependency directions in Figure 10);

• Efferent coupling of selected nodes: which nodes the select ones depend on (see menu of dependency directions in Figure 10);

• Afferent and efferent coupling of selected nodes: display any dependency that include the selected nodes (see menu of dependency directions in Figure 10);

• Afferent and efferent coupling among selected nodes: in this case only display dependencies among the selected nodes (see menu of dependency directions in Figure 10).

Graphs are suitable to represent relationships between elements. The mapping from software attributes to visual attributes is intuitive and can be illustrated by the Figures 10 - 15. In accordance with Figure 16, when you select a node on the graph (simple click), the selected item is highlighted in yellow. Selected nodes (as illustrated by Figures 12, 13 and 14) have special treatment when marked one of the last two options in the dependency directions menu in Figure 10. This is a conceptual zoom to present only specific dependency relationships. You can move any node to the central position with a double click. In the Package Dependency View depicted in Figure 15, you can visualize the web of dependencies among packages. You can select a peripheral package that has a dependency relationship with the central package and use the left button click + the control key while selecting the node to know which classes from this peripheral package caused the dependency.

3.4. A Visual Metaphor for the Software Dependency Strength Perspective A visual metaphor suitable to represent the dependency strength among software modules such as classes and interfaces should convey the modules in decreasing order of dependency, i.e., programmers should be able to easily identify modules with high and low dependency values – a presented in the label at the top of Figure 17. Depending on the dependency direction, selected by the programmer (menu of

(17)

dependency directions in Figure 18), the value of the dependency strength can refer to the afferent coupling value (how many nodes depend on the presented node), efferent coupling of selected nodes (how many nodes the presented node depends on) or both. To complement this scenario, it is also advisable to select a module (class or interface) and double clicking it to have its dependency strength to others in the software system represented (Figure 19). This information is useful to identify classes that are more demanded or that demand more from others. This is the central point of important code smells such as God Class, Shotgun Surgery, Feature Envy, Divergent Change [13][14][15].

The grid layout was adopted to represent the dependency strength of software modules. Software Entities, such as classes and interfaces are presented in decreasing order, i.e., the module with the highest dependency value is in the upper left corner of the canvas whereas the lowest dependency value is in the bottom right corner (Figure 17).

Depending on the coupling option selected in the menu by the programmer, the value of the dependency strength can refer to the afferent coupling value (how many nodes depend on the presented node), efferent coupling of selected nodes (how many nodes the presented node depends on) or both – Figure 20.

Figure 10: Dependency View Menu

(18)

Figure 11: Class Dependency View

Figure 12: Afferent Coupling of Selected Node in the Class Dependency View

(19)

Figure 13: Afferent Coupling of Two Selected Nodes in the Class Dependency View

Figure 14: Efferent Coupling of Selected Node in the Class Dependency View

4. Exploring the Views provided by SourceMiner

Currently, SourceMiner provides six different views to represent Eclipse Java Projects. One can open and arrange them in accordance with its preferences. One important issue is that size, shape and colors are used to convey useful information to software comprehension such as size, complexity, concerns and package that contains a software entity (Figure 5). In addition to the views, filters are also available to set up the type of information to be conveyed. In the next subsections, each of them will be explained.

All the views present the name of the project, the number of packages, classes and methods of the project under analysis (Figures 7, 9, 10, 15, 17, 19 and 20).

(20)

Figure 15: Package Dependency View

Figure 16: Changing the center

The dependency strength layout has two main goals: the first is to present an overview about the coupling degree value of all the modules that comprise a software system. The first goal is presented in a grid layout where the cells represent the modules and their position and the label in each cell represent their coupling degree with other system modules (Figure 17). The Figure 18 presents the Dependency View menu.

The second goal is to present the coupling degree of the selected node with others. This is portrayed as a spiral egocentric graph where the central node is the module under analysis while the other peripheral nodes are positioned in accordance to its dependency strength to the central node, Figure 19. To navigate from the grid view to the spiral egocentric graph, you should double click in the grid cell you want to place as the central node. To return to the grid view, you should click in the “Return to Grid” button at the menu, presented in Figure 20.

(21)

Figure 17: Grid View in the Dependency Strength Perspective

Figure 18: Grid View Menu

(22)

Figure 19: Spiral Egocentric Dependency Graph in the Dependency Strength Perspective

Figure 20: Spiral Egocentric Dependency Graph Menu

4.1. The Filters

Consider -23. Those views are clearly overloaded with information.

Programmers may need to simplify these types of visual scenarios to facilitate their understanding. Simplifications must focus on the entities of interest to the programmer. This can be done by filtering the visual scenario using some entity attributes values of interest. illustrates this process through the use of the Filter View. Range sliders are being used to choose the classes shown on the polymetric view based on their name, number of methods and number of lines of code.

(23)

Figure 21: Range Slider Filters

Filtered out software entities are usually erased from the visual scene. The exceptions are filtered entities that maintain some relationship to unfiltered entities of a given visual scenario. These entities are presented in light transparent colors. Figure 21 highlights two of those entities. In this example, the two filtered out classes are inherited by unfiltered ones. It is important to remark that the elapsed between filtering and view update is instantaneous for all practical purposes. Moreover, all the views are integrated to the same filtering engine in order to maintain consistent visual scenarios under any filtering operation. In the current version of SourceMiner, programmers can use string and range slider filters. String filters are shown in Figure 22. They can be used to select one or more software entities in accordance with the following parameters:

packages, classes, method and interface strings. The range slider filters are shown in Figure 23. They offer the following filtering options: number of methods, lines of code of the class or the method, complexity, afferent and efferent coupling. SourceMiner architecture also facilitates the inclusion of new filtering parameters.

4.2. Using Colors to Represent Module Features

In SourceMiner visual elements can be filled with colors representing concerns, size, complexity and element type (abstract class, external class, interfaces). It is up to programmers to decide what information will be represented by the color that fills the visual elements. Figures 7, 9, 10, 18 and 19 present color options in different views.

(24)

Figure 22: String Filters

Figure 23: Range Object Oriented Slider Filters

4.3. Using Colors to Represent Module Features

In SourceMiner visual elements can be filled with colors representing concerns, size, complexity and element type (abstract class, external class, interfaces). It is up to programmers to decide what information will be represented by the color that fills the visual elements. Figure 24-27 present color options in different views.

4.4. Using Colors and Labels to Represent Concerns

Using Colors and Labels to Represent Concerns SourceMiner’ s architecture enables the mapping of many other software attributes into visual cues. Several features can be added to SourceMiner using this

(25)

approach. One could for example get version control and bug tracking information and visually represent them in the SourceMiner views. As a proof of concept, one of such feature was developed to represent concerns of software modules using colors and labels as visual clues (Figura 28-32).

The separation of concerns in software implementation was first mentioned by Dijkstra [17] and Parnas [18]. Since then, the term concern has been used to describe anything a developer might want to consider as a conceptual unit in a program. Ideally, concerns should be tidily encapsulated within modules with well-defined interfaces [68]. Much of the complexity of software design can be derived from the poor modularization of concerns. Hence, software engineers generally try to keep concerns well modularized as they implement a system. To represent concerns in SourceMiner, expert programmers examine the code and manually assign the concerns using the ConcernMapper plugin [19][20]. The mapping is then saved in xml-like files. SourceMiner reads these files in order to visually represent the concern mapping as colors in the views.

The infrastructure can currently represent concerns in its four different perspectives and in their respective views. Visual elements are filled with colors representing the mapped concerns. For instance, rectangles or circles representing classes, interfaces or methods affected by a specific concern will be filled with the color associated to that concern.

Programmers should use SourceMiner’s Concern Filter to select the colors to be associated with the concerns in a given moment. Figure 28 presents an example of a concern filter containing a set of concerns mapped and fed into an Eclipse Project. After the color(s) selection, the visual mapping can then be presented in any of the SourceMiner’s views as shown in Figures 29-34. Programmers can use this information to assess concern modularization based on the following attributes: (i) scattering – the degree to which a concern is spread over different modularity units, (ii) dedication – how much of each modularity unit is affected by a concern, and (iii) tangling – the degree to which concerns are intertwined to each other in the modularity units.

The use of visualization to analyze concern modularization differs from other approaches in that it allows programmers to assess simultaneously scattering, dedication and tangling from the views. These concepts are manifested originally altogether in the views. It is up to the programmers to configure the best scenario to analyze them.

(26)

Figure 24: Colors in the Treemaps View

Figure 25: Colors in the Polymetric View

Figure 26: Colors in the Dependency View

Figura 27: Colors in the Grid View

Figura 28: Concern Filter

(27)

Figura 29: Concerns in the Grid View

Figure 30: Concerns in the Class Dependency View

(28)

Figura 31: Concerns in the Polymetric (a) and the Treemaps (b) View

Figure 32: Concerns in the Spiral Egocentric Graph View

Figure 33: Grid View presenting Concerns as a Color Attribute

(29)

Figure 34: Spiral Egocentric Graph presenting Concerns as a Color Attribute

4.5. Geometric and Conceptual Zoom

SourceMiner’s views work with both geometric and conceptual zooms.

Geometric zoom is the control of the presented information by scaling up and down its visual elements. Zooming-in will increase the number of pixels per visual element. Conceptual zoom is the control of the level of details in which a set of elements is presented. Zooming in and out will navigate on the inheritance and structural trees, or expand and collapse the level of dependency information shown (See Figure 9).

With a conventional geometric zoom all objects change only their size;

with conceptual zoom they can additionally change shape, details (not merely size of existing details) or, indeed, their very presence in the display, with objects appearing and disappearing according to the context of the map at hand [16].

4.6. RoundTrip Resources

The term roundtrip visualization is used to describe visualization systems that are linked with the data from which they are generated in such a manner that changes to the underlying data updates the visualization and changes made through the visualization itself are reflected in the underlying data. SourceMiner currently enables programmers to navigate from its views to the corresponding source code. Clicking on a view entity permits round-trip navigation between the views and the IDE editor. By doing this, it is possible to analyze the source code

(30)

corresponding to the software entity that is selected in a given SourceMiner view.

(31)

References

1. L. Cardelli and P. Wegner. On understanding types, data abstraction, and polymorphism. Computing Surveys, 17(4):471–522, December 1985.

2. P. Steyaert, C. Lucas, K. Mens, and T. D’Hondt. Reuse contracts:

Managing the evolution of reusable assets. In J. Coplien, editor, Proceedings of the 11th conference on Object-Oriented Programming Systems, Languages and Applications, pages 268–285.

ACM Press, October 1996.

3. Fenton, N.E. and S.L. Pfleeger. Software Metrics: A Rigorous and Practical Approach, Revised. 1997, Boston, MA: International Thomson Publishing.

4. Briand, L.; Wüst, J.; Lounis, H. Using Coupling Measurement for Impact Analysis in Object-Oriented Systems. Fraunhofer Institute for Experimental Software Engineering, Germany, 1999 ISERN-99–03.

5. Sangal, N.; Jordan, E.; Sinha, V.; Jackson, D. Using dependency models to manage complex software architecture. In: OOPSLA '05:

Proceedings of the 20th annual ACM SIGPLAN conference on Object oriented programming, systems, languages, and applications. Vol. 40.

ACM Press, New York, NY, USA, pp. 167-176.

6. Lanza, M.; Ducasse, S. Polymetric Views - A Lightweight Visual Approach to Reverse Engineering. In IEEE Transactions on Software Engineering (TSE), Vol. 29, No. 9, pp. 782 - 795, September 2003. IEEE Computer Society, 2003.

7. T. J. McCabe. A Complexity Measure. Software Engineering, IEEE Transactions on, vol. SE-2, no. 4, pp. 308-320, 1976.

8. Shneirderman, B. Tree Visualization with Tree-Maps: A 2-D Space-Filling Approach. ACM Transactions on Graphics (ToG) 11, 1 (1992), 92–99.

9. Cruz, I.; and Tamassia, R. How to visualize a graph: Specification and algorithms - a graph drawing tutorial. Graph Drawing 94´. DIMACS International Workshop. Princeton, New Jersey - October 1994.

10.Jin, L., and Banks, D. Tennisviewer: A browser for competition trees.

IEEE Computer Graphics and Applications 17, 4, 63-65. 1997.

11.Jungmeister, W., and Turo, D. Adapting treemaps to stock portfolio visualization. Tech. Rep. UMCP-CSD CS-TR- 2996, 1992. University of Maryland, College Park, Maryland 20742, U.S.A.

12.Ghoniem, M., Fekete, J.-D., and Castagliola, P. A Comparison of the Readability of Graphs Using Node-Link and Matrix-Based Representations. In Proceedings of the 10th IEEE Symposium on Information Visualization (INFOVIS’ 04) (2004), pp. 17–24.

(32)

13.Lanza, M.; Radu Marinescu. Object-Oriented Metrics in Practice - Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems. Springer, 2006.

14.Arthur Riel. Object-Oriented Design Heuristics. Addison Wesley, Boston MA, 1996.

15.Fowler, M. Refactoring: Improving the Design of Existing Code.

Addison Wesley, 1999.

16.Boulos, M. The use of interactive graphical maps for browsing medical/health Internet information resources, International Journal of Health Geographics 2(1), 2003.

17. Dijkstra, E. A Discipline of Programming. Prentice Hall, Englewood Cliffs, NJ, USA, 1976

18. Parnas, D. On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12):1053 – 1058, December 1972

19.ConcernMapper - Simple Separation of Concerns for Eclipse.

Available at http://www.cs.mcgill.ca/~martin/cm/.

20.Robillard, M; Murphy, G. Representing Concerns in Source Code.

ACM Transactions on Software Engineering and Methodology, 16(1), Article 3, February 2007.

21.Ben Shneiderman. The Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations. In Proceedings of the IEEE Symposium on Visual Languages, pages 336-343, Washington. IEEE Computer Society Press, 1996.

22.Wu, J., and M.-A. Storey. A Multi-perspective Software Visualization Environment. In Proceedings of CASCON'2000, November 2000, pp.

41-50.

23.Herman, I.; Melançon, G.; and Marshall, M. Graph visualization and navigation in information visualization: A survey. IEEE Transactions on Visualization and Computer Graphics, vol. 6, no. 1, pp. 24-43, 2000.

SourceMiner - User Guide