Combining Development Environments with Reverse Engineering 1. Shortcomings of current IDEs

Understanding and maintaining large software systems is a complex and time-consuming yet inevitable challenge. Most systems frequently change and evolve over time to meet new requirements. To perform these changes a software engineer must have an in-depth understanding of the inner structure and implementation of a system. However, the integrated development environment (IDE) usually provides little in the way of support to ease the understanding and changing of software systems. A large body of research exists in the area of reverse engineering and many promising concepts to improve program comprehension have emerged, such as object or method histograms, polymetric views and class blueprints [3]. But the visualizations of reverseengineered information about software systems are usually separated from the user’s working environment, the IDE, and integrated into dedicated reverse engineering tools such as Moose or CodeCrawler. This means that a programmer working on maintenance tasks does not have access to important information about the structure or the dynamic behavior of a software system, such as a view presenting how a class communicates to other classes. For instance, due to the lack of dynamic information (e.g., collaborators of a class) the developer is forced to frequently browse a large code space without the benefit of goal-directed navigational support. Empirical studies report that an engineer performing maintenance tasks on a system spends at least 35 % of the time in navigating dependencies between source artifacts (e.g., which class uses which other classes) [2]. Because so much time is spent navigating source code, current IDEs obviously do not provide adequate means to support the navigation and browsing of software artifacts