CHAPTER 4 VISUALIZATION
4.1 Software Comprehension
4.1.1 Program Visualization Design and Implementation
國
立 政 治 大 學
‧
N a
tio na
l C h engchi U ni ve rs it y
display different views as the dimension changes, which improves the comprehension to provide information from different platforms.
4.1.1 Program Visualization Design and Implementation
We developed the Web service so that the front-end application can request the analysis results, which are separated and can be requested at different levels, thus helping with maintenance and improving the performance of the back-end server. We designed the data format for different representation levels, and it is compatible for all applications on different platforms. The engineer can develop the front end—such as apps, Websites, and desktop applications—and represent the analysis results based on the features of applications. In addition Figure 8. Architecture of the system.
‧
manipulation, and because the levels are connected by the index users can easily switch the facet to check different levels. The architecture of the system follows the “loosely coupled” principle, which makes it easier to fix if one of the levels does not work. Also, we created a protocol for the communication between the front-end applications, and thus they can synchronize the status and co-operate. We will give an overview of the data format of each representative level in the following section.System level: Users first login through the app or the Website. After passing the
authentication, they can upload their applications for investigation or access previous analysis. The server keeps the list that includes all of the applications that a user has uploaded, with application names and features; performance data and status; and the paths to access analysis results. The back-end server provides the xml file of analysis result for system level with well-define structure as shown in Fig. 11. There are lots of child nodes (application result) under the root node. Every application the user uploaded is represented by a node and the system can get more information by drilling down to the child node. When one of applications in the list is selected, the system can request the full information of the selected application by the result path attribute. The front-end applications can represent the data by textual or graphic ways so that the manager of IT department can easily understand and compared the performance of different applications.
Architectural level: Users can select an application in the list to view the details on how
many files are vulnerable within the application. This can be done through the app or the Website, and data are represented based on the interface. The level information includes all of the file names, an index, and the vulnerability counts within the application, and users can drill down to the details of a file. The vulnerable files in the visualization tool are displayed as a bee comb, where each file is
‧
represented as a honey cell and colored in red, yellow, or green. The color indicates how vulnerable a file is (dangerous, moderate, or safe). To represent the architectural level, the system request the analysis result of each file as shown in Fig. 12 and Fig. 15 and eliminate the detail information such as source codes and file path. The system collects the data of vulnerability counts of each file and represents them as different colors.
File and program code level: This level provides information on a single file and its source
code, and users can check the vulnerabilities in the file. At this level, users can examine each vulnerability in detail, such as the sensitive function, and determine where it is (line of code) and how to patch it (where to insert the patch statement). The information can also be represented in different formats. On the Website, we created a source code editor so that users can directly modify the vulnerability or add the automatically generated patch code into the source code, and system developers can fix vulnerabilities without knowing much about the vulnerabilities or the codes. It is particularly useful to patch legacy parts of Web applications. On the other hand, users may want to know what the vulnerabilities are and how they are raised and exploited. We generate an interactive dependency graph for each vulnerability for this purpose. This level reveals the detail information of vulnerability in each file as shown in Fig.12 and Fig 15. Every file is represented as a node with many child nodes and system can drill down to get more information about the selected file. Also it can improve performance of system because the system can deal with the data of file individually without processing the redundant data.
Dependency-graph level and data-flow level: Every dependency graph corresponds to one
vulnerability in the file. Both apps and Websites can access this information through the index of vulnerabilities and trigger the displace device to show the graph in 3D. Our server provides an interactive environment that allows engineers to trace program execution step by step or to run a simulation of a sample path to exploit the vulnerability. We also synchronize the dependency graph
‧ 國
立 政 治 大 學
‧
N a
tio na
l C h engchi U ni ve rs it y
and source code and highlight the corresponding line of the selected execution (node in the dependency graph) in the source code. That is, users can trace the source code when they explore executions on the dependency graph. The back-end server transforms the dot files into xml files and front-end applications can easily parse and process the data. The data of dependency graph includes nodes and edges which are the basic components of dependency graph and the visualization tool can build the graph based on the information of nodes and edges. After building the static graph, visualization tool build the data flow based on the direction of edge.
‧ 國
立 政 治 大 學
‧
N a
tio na
l C h engchi U ni ve rs it y
Figure 9: The data structure of system representation level.
Figure 10: The data structure of architectural and file representation levels.
Figure 11: The data structure of the graph level.
‧ 國
立 政 治 大 學
‧
N a
tio na
l C h engchi U ni ve rs it y
Figure 12: The data format of system representation level.
Figure 13: The data format of architectural and file representation level.
‧ 國
立 政 治 大 學
‧
N a
tio na
l C h engchi U ni ve rs it y
Figure 14: The data format of dependency-graph level and data-flow level.