A Visualization Method to Support Impacts Analysis in Program Understanding

A Visualization Method to Support Impacts Analysis in Program Understanding Rita Noremi Bt Mohamad Centre for Advanced Software Engineering (CASE) Universiti Teknologi Malaysia Kuala Lumpur, Malaysia rit_emi78@yahoo.com Norbik Bashah Idris Centre for Advanced Software Engineering (CASE) Universiti Teknologi Malaysia Kuala Lumpur, Malaysia norbik@citycampus.utm.my Suhaimi Ibrahim Centre for Advanced Software Engineering (CASE) Universiti Teknologi Malaysia Kuala Lumpur, Malaysia suhaimi@citycampus.utm.my ABSTRACT The software need to undergo some changes is to make the software product more reliable and trustworthy. Thus, the developer is responsible to do the changes to make trustworthy software. The changes of the code might be affected to other part of code. These situations make the developer spend more time to find the affected line in entire code. Change Impact Analysis (CIA) method will be apply to support the developer s program understanding to seek the potential affect or dependency information such as inheritance, Friend, Composition, Calls and Aggregation. A visualization method is applied to make the method effective for program understanding. The visualization method are be use as the tools to represent CIA into graphical that able to guide the developer seeking the potential affect in the line of code. The prototype was developed to combine CIA and visualization method based on C++ Object-Oriented language to enhance program understanding. The prototype called CIA-V will guide the developer to understand the program through diagram and save the time to find affected code. Keywords Program understanding, change impact analysis, visualization method 1. INTRODUCTION In software evolutionary, there have an issue of making software changes in the source code program while the rest of the work products remained not updated. As the source code remains the most reliable artifact, it is clearly accepted by many researchers that codes are the most reference point to maintenance tasks. It is a great challenge to collect all the required software knowledge available in the source code and presents it in the way that is easily understood by the developer. In this paper, the researcher will focus on a mechanism how to handle visualization techniques to facilitate CIA in C++ object-oriented program understanding. CIA was providing one mechanism to aid program understanding. CIA is regarding a study of component relationships and their ripple effects within software [1]. It makes the potential affects visible before the changes are implemented. The CIA is identified the consequences or ripple-effects of software changes to avoid increasing in labors intensive and error prone. Beside that, CIA can reduce the risks of embarking on a costly change. It s because the cost of unexpected problems generally increases with the lateness of their discovery in the software maintenance process. The recent Year 2000 (Y2K) date phenomenon was a good example of why change impact analysis is needed to identify impacts of software change [2]. CIA is implementing with visualization to make it program understanding more useful to the developers or maintainers. In spite of CIA visualization techniques is use to facilitate CIA in program understanding process. This technique is use to described abstract software artifacts and their relations. According to Price et al. [3], software visualization is use for interactive computer graphics, typography, graphic design, animation and cinematography to enhance interface between the software engineers or the computer science student and their program. In this manner, the visualization techniques are a good support tool to aid visualizes the impacted code to a graphical mode and enhancing the program understanding. The ability to visualize the program dependencies and relations will greatly assist a maintainer or management to determine appropriate actions to take with respect to decision-making. 2. CONCEPT Before we go further, there are several concepts or approach that will discuss in this research. The concepts that will concentrate on this research are: i. Program Understanding ii. Change Impact Analysis iii. Relationship in Change Impact iv. Visualization Method This entire concept is related to each other. Program understanding need to use Change Impact Analysis with visualization to enhance understands capability in object-oriented program. 2.1 Program Understanding Program understanding is an important part in software maintenance phase. It is a highly complex task for a number of reasons. It s described the meaning and structure of a software system. The developers need this method to understand the program very well before the changes process is implemented.

Software maintenance takes over 50% of the total expenditure that is allocated to a software system during its lifetime and program understanding takes at least 50% of the time spent on the maintenance task [4]. The ability to understand the program and the required visualization is an essential to the software maintenance process. Therefore, program understanding needs one mechanism tool to make understanding process more effective. 2.2 Change Impact Analysis (CIA) Change Impact in regular term is an effect or impression from state and in terminology term is a sequence of impact. Change Impact Analysis or Impact Analysis (IA) is use to: i. Determine the scope and complexity of the software change. ii. Determine change request scope and plan a resource of every particular change. iii. Estimate maintenance cost because maintenance phase is too costly. CIA is use to assess and analysis a change to the code of the module on the other module of the system and determines the scope of a change and provides a measure of its complexity. 2.2.1 CIA Techniques There are several types of techniques in CIA. Arnold and Bohner [5] was list the techniques that former researcher use. The techniques are: i. Cross-reference - to look at part of program that consist reference to variable and procedure. ii. Program Slicing to determine program subset that will effect to variable value given. iii. Program Browser traverse the program with open and iv. close related file. Traceability tracing changes code using Problem Change Request (PCR) given. v. Design and specification reference - changing the code by refer to design and specification. 2.2.2 Change Impacts Granularity Level The change impact can be implementing at every level of granularity. Base on Figure 1, this work defines four hierarchical levels of granularity: a) class level b) method level c) package level d) relationship level Change impact granularity is depending on modification of source code. For example at the method level, the change impact process can be used to identify potentially affected methods due to a change in one method. The change impact process should also be performed across different levels of granularity. For example, a change made to a method may affect the classes, packages or relationship. Relationship existed in classes and methods. If classes or methods were change, relationship level will impact either small or wide impact. To implement granularity level, program slicing will use to identify dependency between artifacts. This work defines two type of dependency: a) Data b) Control Two type of dependency (Table 1) are used to define the dependency in granularity level. The dependency can be defined through data or control flow graph. Table 1. Change Impact dependency Type of level Dependency Class level Data Method level Data and control package level Data and Control Relationship level Data For example, data and control dependency will be use when control statement like if-then-else, while or for appeared in the source code. This control statement usually appeared in methods body. 2.3 Relationship in Change Impact Relationships between classes are describing in Table 2. Relationships can divide into two types. There are direct and indirect relationships. A direct relationship is shown in Table 1. For instance, Class A is super class for Class B and C. Class B is derived from Class B. It s mean Class A and B is an inheritance relationship. This relationship is called direct relationship. When Class A has some changes, Class B will impact. The impact class is called as direct impact. Class C also affected because Class C is part of Class B. This type is called indirect impact and relationship between Class A and C is indirect relationship. Relationship Type Table 2. Relationship Type Relationship Change Impact Signs Signs Inheritance Class x Class Class B Class A Association Class x Method methodb1() Class A Aggregation Class x Class Class x Method Class B Class A methodb1() Class A Composition Friend Class x Class Class x Method Class x Class Method x Class Class B Class A methodb1() Class A Class C Class B Class B methodc1() Invocation Method x Method methodb1() methoda1() Creation Class x Class Class x Method Class B Class A methodb1() Class A Data Uses Class x Class Class x Method Class B Class A methodb1() Class A Definition Class x Method Class A methoda1() Figure 1. Change Impact Granularity Level

2.4 Visualization Method Visualization techniques as a means toward helping developers better understand what their programs are doing. Visualization technique has a two type. The types are: i. Static is focusing on source code that will visualize program structure and code components analysis. At this point, object-oriented programming will use as a research material. ii. Dynamic is focusing on run-time program that will visualize behavior of program during program execution. There are several techniques to implement visualization. But in this paper, we focus on two techniques: i. Fisheye view [6] ii. SHRiMP view [7,8] 2.4.1 Fisheye View Fisheye view is to view hypergraph node. A fisheye view is to manipulate a large graph on a small screen. Fisheye strategy is to provide a balance of local detail and global context in one view. This display method is based on the fisheye lens metaphor where objects in the center of the view are magnified and objects further from the center are reduce in size [7]. (a) (b) (c) Figure 3. (a) before scaling. (b) Center node by a desire scale. (c) The node and its siblings are scaled to fit inside the screen using SHriMP.[7,8] SHriMP view was formerly introduced in RIGI [9]. Beside fisheye view, SHriMP also has a nested graph to use for drill-down information. The nested graph is containing composites node that conveys parent-child relationship in hierarchy [7]. Figure 4 (a) shows a class hierarchy that is displayed as a nested graph in Figure 4(b). For instance, click Class A, the program will display child of Class A. (a) (b) Figure 4 (a) A tree view hierarchy. (b) A nested graph view of the same hierarchy Figure 2. Fisheye- View Figure 2 is an example of fisheye view. Local detail is needed for the local interaction with a structure [6]. For instance, display nearest node such as Class A, Class D and Class E. Class C as main node and is called fisheye. Global context is needed to tell what other parts of the structure exist and where the part in the graph 6]. 2.4.2 SHRiMP View The SHriMP visualization technique employs nested-graph formalism and a fisheye-view algorithm for manipulating large graphs that provides contextual cues and preserves constraints such as orthogonality and proximity among individually resizable nodes [7]. 3. APPROACH 3.1 CIA-V CIA-V is the short name to Change Impact Analysis-Visualization. CIA-V is a technique that combines visualization technique and CIA to enhance program understanding more effective. Research related to this work primarily comes from the source code based maintenance of object-oriented software. This technique have two phases that as shown in Figure 5. The SHriMP layout adjustment algorithm is elegant in its simplicity. Nodes in the graph uniformly give up screen space to allow a node of interest grow [6]. Figure 3 (a), (b) and (c) is SHriMP fisheye views that provide uniformly resize node automatically and manage the screen space available rather than fisheye view. Figure 5. CIA-V Overview

3.1.1 TokenAnalyzer TokenAnalyzer is a parser engine that constructs a knowledge-base on object-oriented component information from C++ source code. The engine will collect information regarding classes, methods and relationship. This information will store into repository. 3.1.2 CATIA Configuration Artifact Traceability for Change Impact Analysis (CATIA) is used TokenAnalyzer information to build traceability graph for CIA. CATIA [10] is regarding requirement relationship, design, code components, test cases and others traceability relationship between artifacts. CATIA s results are a potential affect will store into repository and text file. Figure 6 is an result from CATIA after generate the impact. For instance, mtd2 is a change code that reacts as a primary artifact and secondary artifact will identify the impact in code. In this case, mtd2 will impact methods, classes, packages, test cases and requirement. See the results in Figure 6. 4. PROTOTYPE Figure 7. CIA-V feature Prototype was developing to demonstrate CIA-V. This prototype is a tool as a guide for developer team to understanding program very easily. Beside that, developer would know actual impact before make a decision to do the changes. 4.1 Scenario and Results In this research, On-Board Automobile System (OBA) is use as a program to apply in CIA-V prototype. The scenario will base on three artifacts such as methods, classes and packages. The Figure 8 and 9 is the primary and secondary artifact screen as a main input screen. The result or output will display as textual and graphical screen as shown at figure 10. 3.1.3 CIA-V Technique Figure 6. Output of CATIA [10] CIA-V is one of the technique that combine CIA and visualization. CIA-V is using CATIA s results to turn the results into meaningful diagram. CIA-V has some feature to understand the code easily. The features that are provided (Refer to Figure 7): i. Top-bottom analysis Information from package level to relationship level. ii. Bottom-up analysis Information from relationship level to package iii. Drill-down diagram For instance, methodc1 is belong to Class C. iv. Relationship information Information related relationship between object-oriented components. Figure 8. Primary Artifacts Listing will base on selected artifact.

4.1.1 Methods Table 3 is an example method listing for primary artifact. Table 3. Example methods (Primary artifact) Method ID mtd1 drivingstationhandler() mtd2 getstate() mtd3 ison() In this case, I choose mtd2 or getstate() as a method code to change. Then, secondary artifact will generate the impact. The result was display graphical and textual mode. Figure 9. Secondary Artifacts Impact will base on selected primary artifact. Scenario 1: A secondary artifact is Method. Refer table 4 as a result in textual and Figure 11 as visualization with relationship information. Table 4. Result from Impacted Method Method ID mtd1 drivingstationhandler() mtd2 getstate() mtd14 getoperationsignal() mtd16 checkcruisemodel() (a) Figure 11. Visualization - method to methods Scenario 2: A secondary artifact is Classes. Refer table 5 as a result in textual and Figure 12 as visualization. Class ID cls1 cls2 cls8 Table 5. Result from Impacted Classes CDrivingStation Cpedal CCruiseManager, (b) Figure 10. (a)result in Textual. (b) Result in graphical

Table 8. Result from Impacted Method Method ID mtd1 drivingstationhandler() mtd2 getstate() mtd14 getoperationsignal() mtd16 checkcruisemodel() Figure 12. Visualization - method to classes Scenario 3: A secondary artifact is Packages. Refer table 6 as a result in textual and Figure 13 as visualization. Table 6. Result from Impacted Packages Package ID pkg1 DrivingStation pkg4 CruiseMgmt, Figure 14. Visualization - classes to methods Scenario 2: A secondary artifact is Classes. Refer table 9 as a result in textual and Figure 15 as visualization. Class ID cls1 Table 9. Result from Impacted Classes CDrivingStation Figure 13. Visualization - methods to packages 4.1.2 Classes Table 7 is an example classes listing for primary artifact. Class ID cls1 CDrivingStation cls2 Cpedal cls3 Cignition Table 7. Example classes (Primary artifact) I choose cls2 or Cpedal as a class to change. Then, secondary artifact will generate the impact. The result was display graphical and textual mode. Scenario 1: A secondary artifact is Method. Refer table 8 as a result in textual and Figure 14 as visualization with relationship information. Figure 15. Visualization - classes to classes Scenario 3: A secondary artifact is Packages. Refer table 10 as a result in textual and Figure 16 as visualization. Table 10. Result from Impacted Packages Package ID pkg1 DrivingStation pkg4 CruiseMgmt,

Class ID cls5 cls6 Table 13. Result from Impacted Classes CKeypad CInitManager Figure 16. Visualization - classes to packages 4.1.3 Packages Table 11 is an example packages listing for primary artifact. Table 11. Example classes (Primary artifact) Package ID pkg1 DrivingStation pkg2 Pedal pkg3 InitMgmt I choose pkg2 or Pedal as a package to explore. Secondary artifact will generate the impact. The result will display in graphical and textual mode. Figure 18. Visualization - packages to classes Scenario 3: A secondary artifact is Packages. Refer table 14 as a result in textual and Figure 19 as visualization. Table 14. Result from Impacted Packages Package ID pkg3 InitMgmt Scenario 1: A secondary artifact is Method. Refer table 12 as a result in textual and Figure 17 as visualization with relationship information. Table 12. Result from Impacted Method Method ID mtd5 keypadhandler() mtd9 main() Figure 19. Visualization - packages to packages 4.1.3 View Source Code and Drill-Down Result Beside textual and graphical output, there is two more output that will obtain from the selected graphical node. There is a view source code and Drill-Down function that allow user to know the detail of the changes code. Figure 17. Visualization - packages to methods In this function, the user can know the file involve and code location. For instance, mtd5 (keypadhandler()) is belong to Ckeypad class in ControlPanel package and the file involve is keypad.h and keypad.cpp. The method name involve will highlight with yellow color in the files. This scenario is shown as Figure 20. Scenario 2: A secondary artifact is Classes. Refer table 13 as a result in textual and Figure 18 as visualization.

statements. Then CodeSurfer represent all the information in visualization. CC-RIDER was produce by Western West is similar like CodeSurfer but CC-RIDER focus on C and C++ especially objectoriented programming. This product is a visualization tools that present complete information on functions, variables, enum values, macros and etc [12]. But both products more on visualize the interaction of relationship between components. (a) Rigi is the one of a visual software understanding tool [9]. Rigi can help maintainer to better understand and re-document the software. Rigi includes parsers to read the source code such as C, C++ and COBOL and produce a graph of extracted artifacts such as procedures, variables, calls, and data access. In Rigi, the information serves as documentation that is up-to-date and accurate because it is derived from the actual source code. This research differs from the above. In this paper, researcher tries to identify the change impact of a software component of interest and turns it into visualization. It s mean a user can visualize the dependencies between artifacts which can be defined in terms of variables, methods or classes and deep until detail statement. The knowledge of artifact relationships needs a special study on impact analysis before it can be turned into graphical views for visualization. (b) Code Location (C) Figure 20. (a) View Source Code and Drill Down. (b) Code location. (c) Header and CPP File 5. RELATED RESEARCH CodeSurfer is the one of Reverse Engineering tools that provide program analysis, understanding and inspection system for ANSI C. CodeSurfer was produce by GrammaTech s which based on system dependence graph, a fundamental intermediate structure for representing program[11]. This product was focus on structure programming and dependency based on methods, variable and 6. CONCLUSION AND FUTURE WORK This paper is focusing on enhancing program understanding using change impact analysis and visualization as a support tools. We study a mechanism to handle the impact analysis and visualization in software system to produce a tool for program understanding. We cater into our work a capability to support the change impact with some degree of visualization. Visualization is applicable not only to a proposed change artifact but also to any other artifacts of interest from which we can visualize its dependencies in software system. In spite of that, change impact analysis in this paper only caters direct impact because indirect impact is very complicated to implement. These indirect impacts need a more study in a specific mechanism and technique to handle the situation. This restriction we leave as a next future work. 7. REFERENCES [1] Lee M., Algorithmic analysis of the impacts of changes to object-oriented software, Proceedings of 34 th International Conference on Technology of Object-Oriented Languages and Systems, 2000, pp. 61-70. [2] Arnold R.S., Impact analysis in the software change process: A year 2000 perspective, Proceedings of International Conference of Software Maintenance, 1996, pp. 42-51. [3] Shahida Sulaiman, Norbik Bashah Idris, Shamsul Sahibuddin, Sarina Sulaiman, Re-documenting, Visualizing and Understanding Software System Using DocLike Viewer, 10th Asia-Pacific Software Engineering Conference (APSEC'03), 2003, pp. 154. [4] Timothy S. Jones and Jim Welsh, Software visualisation in a language based editor. In Proc. Software Visualisation Work, Adelaide, Australia, 1997, pp. 9-18.

[5] S.A. Bohner, R.S. Arnold, An Introduction to Software Change Impact Analysis, Software Change Impact Analysis, IEEE CS Press, Los Alamitos, CA, 1996, pp.1-26. [6] Storey, Margaret-Anne D. and Müller, Hausi A, Graph Layout Adjustment Strategies, In Brandenburg, Franz J., Eds. Proceedings Graph Drawing, Passau, Germany, 1996, pp. 487-499. [7] Storey, M.-A.D. Kenny Wong Muller, H.A., Rigi: A Visualization Environment for Reverse Engineering, Software Engineering, Proceedings of the 19 th International Conference,1997, pp.606-607. [8] Peggy Storey, HausiMueller and KennyWong, Manipulating and Documenting Software Structures, In P. Eades and K. Zhang, editors, Software Engineering and Knowledge Engineering, World Scientific, 1996, pp. 244-264. [9] K. Wong. Rigi blurb. February 1996 [10] Ibrahim, S. Munro, M. & Deraman, A., A Requirements traceability to Support Change Impact Analysis., Asian Journal of Information Technology 4(4), 2005, pp. 329-338. [11] GrammaTech s, Dependence Graphs and Program Slicing, 2000, pp. 1. [12] Western Wares, CC-RIDER C/C++ Program Visualization Tool White Paper, 1998, pp. 5