Software change requests are often formulated as requests to modify or to add a specific feature or concept. To implement these changes, the features or concepts must be located in the code. In this paper, we describe the scenarios of the feature and concept location. The scenarios utilize a computer-assisted search of software dependence graph. Scenarios are demonstrated by a case study of NCSA Mosaic source code. 1. Introduction In software maintenance and evolution, change requirements are often formulated as requests to modify or to add specific program concepts or features [2, 26]. An example of such a request is "Add a new external viewer to Mosaic web browser". Before any actual change can be made to the system, software programmers must locate the implementation of the concepts ("external viewer") in the source code. Concept location is a process that maps domain concepts to the software components. The input is the maintenance request, expressed in natural language and usin...

Despite significant existing empirical work, little is known about the specific kinds of questions programmers ask when evolving a code base. Understanding precisely what information a programmer needs about the code base as they work is key to determining how to better support the activity of programming. The goal of this research is to provide an empirical foundation for tool design based on an exploration of what programmers need to understand about a code base and of how they use tools to discover that information. To this end, we undertook two qualitative studies of programmers performing change tasks to medium to large sized programs. One study involved newcomers working on assigned change tasks to a mediumsized code base. The other study involved industrial programmers working on their own change tasks to code with which they had experience. The focus of our analysis has been on what information a programmer needs to know about a code base while performing a change task and also on how they go about discovering that information. Based on a systematic analysis of the data from these user studies as well as an analysis of the support that current programming tools provide for these activities, this research makes four key contributions: (1) a catalog of 44 types of questions programmers ask, (2) a categorization of those questions into four categories based on the kind and scope of information needed to answer a question, (3) a description of important context for the process of answering questions, and (4) a description of support that is missing from current programming tools.

Software programs, especially legacy programs, are often large, complex and poorly documented. To maintain these programs software engineers require a variety of efficient analytical tools. Some software maintenance tools use visualizations (i.e. graphical views) to communicate information about software systems. Although many software visualization tools exist, the majority of them are not very effective in practice. Part of the problem is that they are designed in an ad hoc manner, with little empirical evaluation. They are often criticized because they try to force programmers to use a specific approach to understanding software rather than supporting their own approaches. The result is that current software visualization tools do not play as big a role in industry as was anticipated by some researchers. The tools that are used are very basic, consisting of mainly text editors and searching features. With increasingly fast computing platforms, there is great potential for the use of...

Program comprehension research can be characterized by both the theories that provide rich explanations about how programmers comprehend software, as well as the tools that are used to assist in comprehension tasks. During this talk I will review some of the key cognitive theories of program comprehension that have emerged over the past thirty years. Using these theories as a canvas, I will then explore how tools that are popular today have evolved to support program comprehension. Specifically, I will discuss how the theories and tools are related and reflect on the research methods that were used to construct the theories and evaluate the tools. The reviewed theories and tools will be further differentiated according to human characteristics, program characteristics, and the context for the various comprehension tasks. Finally, I will predict how these characteristics will change in the future and speculate on how a number of important research directions could lead to improvements in program comprehension tools and methods. 1.

Accelerating the learning curve of software maintainers working on systems with which they have little familiarity motivated this study. A working hypothesis was that automated methods are needed to provide a fast, rough grasp of a system, to enable practitioners not familiar with it, to commence maintenance with a level of confidence as if they had this familiarity. Expert maintainers were interviewed regarding their strategies and information needs to test this hypothesis. The overriding message is their need for a “starting point ” when analysing code. They also need standardised, reliable and communicable information about a system as an equivalent to knowledge available only to developers or experienced maintainers. These needs are addressed by the proposed “roughcut” approach to program comprehension. Work underway assesses the suitability of using data mining techniques on data derived from source code to provide high level models of a system and module interrelationships. 1. Background Program comprehension is a demanding task comprising up to 90 % of the total time spent on software maintenance [2], [21], [27], which in turn is the most expensive process in the lifetime of software [2]. This has been attributed to a plethora of problems reported in the literature, such as lack of up-to-date and precise documentation, inadequate communication, and unavailability of the original designers and programmers [11], [13]. Researchers have been trying to improve and accelerate the process of program comprehension in a number of ways. Because of the limited amount of information that a maintainer can assimilate at one time, the as-needed strategy suggests maintainers gain an understanding of the application while performing the change process [13]. Similarly partial comprehension has

Abstract Program comprehension research can be characterized by both the theories that provide rich explanations about how programmers understand software, as well as the tools that are used to assist in comprehension tasks. In this paper, I review some of the key cognitive theories of program comprehension that have emerged over the past thirty years. Using these theories as a canvas, I then explore how tools that are commonly used today have evolved to support program comprehension. Specifically, I discuss how the theories and tools are related and reflect on the research methods that were used to construct the theories and evaluate the tools. The reviewed theories and tools are distinguished according to human characteristics, program characteristics, and the context for the various comprehension tasks. Finally, I predict how these characteristics will change in the future and speculate on how a number of important research directions could lead to improvements in program comprehension tool development and research methods.

Abstract—Currently available systems for dynamic reverse engineering do not have the satisfying quality. Therefore it is necessary to set the assumptions needed to bring a new methodology that would cover all of the existing solutions. Entire analysis presented in this paper was based on a study of graphic mode initialization of the GeForce GPU. Utilization of 2D acceleration functions, and also all relevant details related to 3D acceleration functions were included.

Abstract. The ability to search for source code on the Internet has proven to be essential for many common software development and maintenance tasks. However, available code search engines are typically limited to lexical searches and do not take in consideration the underlying semantics of source code such as the program structure or language. Especially object-oriented source code, which includes inheritance and polymorphism, is often not modeled to a level in which it can be queried sufficiently. In this paper, we present a Semantic Web-based approach to source code search that uses ontologies to model and connect source code fragments extracted from repositories on the Internet. This modeling approach allows us to reason and search across project boundaries while dealing with incomplete knowledge and ambiguities. In comparison with other search tools, we incrementally build our knowledge base without the need to re-visit fragments or compile the source code. Our search engine is scalable and allows us to process and query a large code base collected from opensource projects.

Abstract—The advent of modern technology shadows its impetus repercussions on successful Legacy systems making them obsolete with time. These systems have evolved the large organizations in major problems in terms of new business requirements, response time, financial depreciation and maintenance. Major difficulty is due to constant system evolution and incomplete, inconsistent and obsolete documents which a legacy system tends to have. The myriad dimensions of these systems can only be explored by incorporating reverse engineering, in this context, is the best method to extract useful artifacts and by exploring these artifacts for reengineering existing legacy systems to meet new requirements of organizations. A case study is conducted on six different type of software systems having source code in different programming languages using the architectural recovery framework. Keywords—Reverse Engineering, Architecture recovery, Architecture artifacts, Reengineering.

Program comprehension remains a major bottleneck for software maintenance. When a programmer must understand a large legacy program whose documentation is scarce, out-of-date, or irrelevant, she must browse its source code to build an effective mental model of its structure and behavior. But source code is far from an ideal representation for this task. I propose a system, DR. JONES, to help a programmer understand an unfamiliar program. DR. JONES is a magic lens over the program that reveals information that usually requires effort to extract from source code. This information is broken into tightly coupled views of the program’s structure and behavior that, taken together, help the programmer build a good mental model of the program. DR. JONES presents these views as diagrams, to engage the programmer’s perception in extracting knowledge about the program. The design of DR. JONES will be motivated by user studies to find the kinds of knowledge programmers seek to extract from unfamiliar programs, and the strategies they employ to do so. DR. JONES will make use of techniques like multiscale browsing, design pattern recognition, and “software jiggling ” to permit the orderly and conceptual exploration of an unfamiliar program. DR. JONES: A Software Archaeologist’s Magic Lens