Re-documenting, Visualizing and Understanding Software System Using DocLike Viewer Shahida Sulaiman 1,2 , Norbik Bashah Idris 2 , Shamsul Sahibuddin 3 , Sarina Sulaiman 3 1 Faculty of Computer Science Universiti Sains Malaysia Minden, Pulau Pinang, Malaysia 2 Center for Advanced Software Engineering (CASE) Universiti Teknologi Malaysia Kuala Lumpur, Malaysia 3 Faculty of Computer Science & Information Technology Universiti Teknologi Malaysia Skudai, Johor, Malaysia shahida@case.utm.my Abstract Visualizing the artifacts of a software system graphically has proven to improve the cognitive strategies and understanding of the subject system by programmers. This is more crucial when they need to maintain a software system with out-dated documentation or without system documentation at all. Many tools have emerged and they predominantly consist of a reverse engineering environment and a viewer to visualize software artifacts such as in the form of graphs. The tools also grant structural re-documentation of existing software system but they do not directly utilize document- like software visualization in their approaches. This paper proposes DocLike Modularized Graph (DMG) method that represents the software architectures of a reverse engineered subject system graphically in a modularized and standardized document-like manner. To realize this method, we have built a prototype tool called DocLike Viewer that enables a user to re-document, visualize and comprehend a subject system written in C language that is parsed by an existing parser. From the experiment conducted we found that our method managed to statistically improve cognition of a subject system in terms of productivity and quality to solve certain types of maintenance tasks. 1. Introduction Visualization for software is also called software visualization (SV). It has played a great role as a method in program comprehension, which is vital in the costly software maintenance. According to Price et al. [7], software visualization is the use of interactive computer graphics, typography, graphic design, animation and cinematography to enhance interface between the software engineers or the computer science student and their programs. The objective is to use graphics to enhance the understanding of a program that has already been written. CASE (Computer-Aided Software Engineering) workbench in the class of maintenance and reverse engineering such as CIA [3], Rigi [17], PBS [6] and SNiFF+ [16] are normally incorporated with editor window in which the abstracted software artifacts will be visualized graphically besides their textual information. These tools are able to assist and optimize software engineers’ program comprehension or cognitive strategies, particularly when there is an absence of design level documentation that should describe the architecture and dependencies among the components for various levels of software abstraction (see Table 1). Existing methods of the tools focus on visualizing the software artifacts whilst structural re-documentation as another aspect provided by them. Nevertheless, they do not directly grant the environment to re-document the software system via their viewer. Thus, this has motivated us to propose DocLike Modularized Graph (DMG) method employed in DocLike Viewer prototype tool that represents the existing software architectures graphically in a modularized and standardized document- like manner. The discussion and evaluation of our DMG method in DocLike Viewer will be based on Storey’s work [11] that provides the cognitive framework to describe and evaluate software exploration tools, or in our context we refer them as SV tools. The framework embraces two aspects: (i) Enhance program comprehension (Bottom-up, Top-down, Integrated) and (ii) Reduce cognitive overhead (Navigation, Orientation cues, User interface). Table 1: The taxonomy of level of information abstraction Level of abstraction Level Number Information abstracted Very high L1 System architecture High L2 System-subsystem hierarchy view L3 System hierarchy view (module-to- module dependencies or program-to- program dependencies) Low L4 Function/procedure/method dependencies within module or inter- module (call graph) L5 Function/procedure/method versus variable /data usage dependencies (data flow graph) Very low L6 Pseudo code/algorithm Proceedings of the Tenth Asia-Pacific Software Engineering Conference (APSEC’03) 1530-1362/03 $ 17.00 © 2003 IEEE