Object-oriented legacy system trace-based logic testing
22 Mar 2006-pp 37-46
TL;DR: The approach reifies the execution traces and uses logic programming to express tests on them, which eliminates the need to programatically bring the system in a particular state, and handles the test-writer a high-level abstraction mechanism to query the trace.
Abstract: When reengineering legacy systems, it is crucial to assess if the legacy behavior has been preserved or how it changed due to the reengineering effort. Ideally if a legacy system is covered by tests, running the tests on the new version can identify potential differences or discrepancies. However, writing tests for an unknown and large system is difficult due to the lack of internal knowledge. It is especially difficult to bring the system to an appropriate state. Our solution is based on the acknowledgment that one of the few trustable piece of information available when approaching a legacy system is the running system itself. Our approach reifies the execution traces and uses logic programming to express tests on them. Thereby it eliminates the need to programatically bring the system in a particular state, and handles the test-writer a high-level abstraction mechanism to query the trace. The resulting system, called Testlog, was used on several real-world case studies to validate our claims.
Citations
More filters
07 Jul 2008
TL;DR: This paper proposes a practical approach that attempts to keep track of only the relevant data, and keeps object history information together with the regular objects in the application memory so that data not reachable from current application objects is garbage collected.
Abstract: Back-in-time debuggers are extremely useful tools for identifying the causes of bugs. Unfortunately the "omniscient" approaches that try to remember allprevious states are impractical because they consume too much space or they are far too slow. Several approaches rely on heuristics to limit these penalties, but they ultimately end up throwing out too much relevant information. In this paper we propose a practical approach that attempts to keep track of only the relevant data. In contrast to other approaches, we keep object history information together with the regular objects in the application memory. Although seemingly counter-intuitive, this approach has the effect that data not reachable from current application objects (and hence, no longer relevant) is garbage collected. We describe the technical details of our approach, and we present benchmarks that demonstrate that memory consumption stays within practical bounds. Furthermore, the performance penalty is significantly less than with other approaches.
85 citations
Additional excerpts
...In those approaches the user formulates a query in a higher-level language that is then applied to the logged data [17,18,19,20]....
[...]
22 Oct 2007
TL;DR: A compact visualization, named Package Surface Blueprint, is presented that qualifies the relationships that a package has with its neighbours and presents two specific views one stressing the references made by a package and another showing the inheritance structure of a package.
Abstract: Large object-oriented applications are structured over large number of packages. Packages are important but complex structural entities that may be difficult to understand since they play different development roles (i.e., class containers, code ownership basic structure, architectural elements...). Maintainers of large applications face the problem of understanding how packages are structured in general and how they relate to each others. In this paper, we present a compact visualization, named Package Surface Blueprint, that qualifies the relationships that a package has with its neighbours. A Package Surface Blueprint represents packages around the notion of package surfaces: groups of relationships according to the packages they refer to. We present two specific views one stressing the references made by a package and another showing the inheritance structure of a package. We applied the visualization on two large case studies: ArgoUML and Squeak.
55 citations
Cites background from "Object-oriented legacy system trace..."
...What is the general size of a package in terms of classes, inheritance definition, internal and external class references, imports, exports to other packages?...
[...]
02 Jun 2012
TL;DR: This work presents a running prototype of an object-centric debugger, and shows how, by focusing on objects as the key abstraction, natural debugging operations can be defined to answer developer questions related to runtime behavior.
Abstract: During the process of developing and maintaining a complex software system, developers pose detailed questions about the runtime behavior of the system. Source code views offer strictly limited insights, so developers often turn to tools like debuggers to inspect and interact with the running system. Unfortunately, traditional debuggers focus on the runtime stack as the key abstraction to support debugging operations, though the questions developers pose often have more to do with objects and their interactions. We propose object-centric debugging as an alternative approach to interacting with a running software system. We show how, by focusing on objects as the key abstraction, natural debugging operations can be defined to answer developer questions related to runtime behavior. We present a running prototype of an object-centric debugger, and demonstrate, with the help of a series of examples, how object-centric debugging offers more effective support for many typical developer tasks than a traditional stack-oriented debugger.
53 citations
Cites methods from "Object-oriented legacy system trace..."
...In query-based debugging the user defines a query in a higher-level language that is then applied to the logged data [31], [32], [33], [34]....
[...]
13 Oct 2009
TL;DR: Enriched DSM (eDSM) is presented where cells are enriched with contextual information about the type of dependencies (inheritance, class reference...), the proportion of referencing entities, and theportion of referenced entities is presented.
Abstract: Dependency Structure Matrix (DSM) has been successfully applied to identify software dependencies among packages and subsystems. A number of algorithms were proposed to compute the matrix so that it highlights patterns and problematic dependencies between subsystems. However, existing DSM implementations often miss important information to fully support reengineering effort. For example, they do not clearly qualify and quantify problematic relationships, information which is crucial to support remediation tasks.In this paper we present enriched DSM (eDSM) where cells are enriched with contextual information about (i) the type of dependencies (inheritance, class reference...), (ii) the proportion of referencing entities, (iii) the proportion of referenced entities. We distinguish independent cycles and stress potentially simple fixes for cycles using coloring information. This work is language independent and has been implemented on top of the Moose reengineering environment. It has been applied to non-trivial case studies among which ArgoUML, and Morphic the UI framework available in two open-source Smalltalks, Squeak and Pharo. Solution to problems identified by eDSM have been performed and retrofitted in Pharo main distribution.
43 citations
Cites background from "Object-oriented legacy system trace..."
...: It is a visualization that can be applied to packages [7]....
[...]
DOI•
01 Jan 2006
TL;DR: This paper presents the design and implementation of a backward-in-time debugger for a dynamic language called UNSTUCK and shows the solution to key implementation challenges.
Abstract: Traditional debugging and stepping execution trace are well-accepted techniques to understand deep internals about a program. However in many cases navigating the stack trace is not enough to find bugs, since the cause of a bug is often not in the stack trace anymore and old state is lost, so out of reach from the debugger. In this paper, we present the design and implementation of a backward-in-time debugger for a dynamic language, i.e., a debugger that allows one to navigate back the history of the application. We present the design and implementation of a backward-in-time debugger called UNSTUCK and show our solution to key implementation challenges.
43 citations
References
More filters
Book•
01 Jan 2002TL;DR: This paper addresses problem of understanding and reengineering such object-oriented legacy systems by presenting a set of "reengineering patterns" - recurring solutions that experts apply while reengineering and maintaining object- oriented systems.
Abstract: The rapid growth of object-oriented development over the past twenty years has given rise to many object-oriented systems that are large, complex and hard to maintain. These systems exhibit a range of problems, effectively preventing them from satisfying the evolving requirements imposed by their customers. In our paper, we address problem of understanding and reengineering such object-oriented legacy systems. The material is presented as a set of "reengineering patterns" - recurring solutions that experts apply while reengineering and maintaining object-oriented systems. The patterns distill successful techniques in planning a reengineering project, reverse-engineering, problem detection, migration strategies and software redesign. The principles and techniques described have been observed and validated in a number of industrial projects, and reflect best practice in object-oriented reengineering.
415 citations
"Object-oriented legacy system trace..." refers background in this paper
...Furthermore, writing tests is one pattern to support software understanding: encode the assumption in a test and check whether the test fails or succeeds [6]....
[...]
...Moreover, due to poor design, it is often difficult to bring the system into the wanted state [6]....
[...]
...Indeed, in the context of legacy systems, one of the few trustable sources of information is the execution of the application itself [6]....
[...]
...One reengineering pattern is to start the reengineering from running the system, by emphasizing that it is important to have the knowledge of the domain when understanding the code [6]....
[...]
01 Nov 1992
TL;DR: A venturi scrubber for the scrubbing of an inlet gas stream with a scrubbing liquid or slurry, to remove gaseous or vaporous components from the gas stream, or to remove entrained solid particulate or discrete liquid droplet (fog or mist) constituents, and thereby to prevent air pollution and/or to recover the component or constituent.
Abstract: A venturi scrubber for the scrubbing of an inlet gas stream with a scrubbing liquid or slurry, to remove gaseous or vaporous components from the gas stream, or to remove entrained solid particulate or discrete liquid droplet (fog or mist) constituents, and thereby to prevent air pollution and/or to recover the component or constituent. The venturi scrubber has an adjustable throat characterized by the provision of structure to adjust the cross-sectional dimension of the gas passage at or adjacent to the throat section. The structure includes at least one movable baffle at the periphery of the gas passage, and a container. The container is disposed external to and contiguous with the baffle, and a controlled amount of a fluid is passed into the container so that the internal fluid pressure within the container, and resultant volumetric dimension of the container, and thereby also the resultant displacement of the baffle relative to the periphery of the throat section, are adjustable in proportion to a change in the flow rate of the inlet gas stream.
189 citations
"Object-oriented legacy system trace..." refers methods in this paper
...However, because a general tree pattern matching problem with variables is NP-complete and would no be usable for pattern matching an execution trace consisting of several thousand messages, we use the left order embedding algorithm described in [15] to pattern match an execution trace....
[...]
TL;DR: This work identifies five levels of object-oriented testing; four of these map nicely into the commonly accepted unit, integration, and system levels of traditional software testing; and identifies two new testing constructs and a directed graph notation that helps formalize object- oriented integration testing.
Abstract: IntegKItCO~ 0 bject-oriented software development raises important testing issues. Many of these stem from attempts to directly apply theoretical constructs and techniques of traditional software develop ment and testing to object-oriented software. We examine this traditional heritage here, with special emphasis on assumptions and practices that need to be modified or replaced. We identify five levels of object-oriented testing; four of these map nicely into the commonly accepted unit, integration, and system levels of traditional software testing. (Placement of the remaining level is primarily a management consideration .) We also identify two new testing constructs and a directed graph notation that helps formalize object-oriented integration testing. These are illustrated with an object-oriented formulation of an automated teller machine (ATM) system. The source code (ObjectiveC) for this system is available from the authors. We begin with an important distinction: structure vs. behavior. Most of the popular notations used in software development (E/R models, data flow diagrams, structure charts, PDLs, and so on) portray software structure: the components, relationships among these, the interfaces,
175 citations
"Object-oriented legacy system trace..." refers background in this paper
...In a pioneering paper [14] the authors argue that testing object-oriented software should not focus on units but on the message exchange between them in a scenario....
[...]
01 Oct 1998
TL;DR: An off-line, flexible approach for visualizing the operation of an object-oriented system at the architectural level is developed, which complements and extends existing profiling and visualization approaches available to engineers attempting to utilize dynamic information.
Abstract: Dynamic information collected as a software system executes can help software engineers perform some tasks on a system more effectively. To interpret the sizable amount of data generated from a system's execution, engineers require tool support. We have developed an off-line, flexible approach for visualizing the operation of an object-oriented system at the architectural level. This approach complements and extends existing profiling and visualization approaches available to engineers attempting to utilize dynamic information. In this paper, we describe the technique and discuss preliminary qualitative studies into its usefulness and usability. These studies were undertaken in the context of performance tuning tasks.
173 citations
"Object-oriented legacy system trace..." refers methods in this paper
...[22] use program events traces to visualise program execution patterns and eventbased object relationships such as method invocations and object creation....
[...]
Proceedings Article•
27 Apr 1998TL;DR: An execution pattern view that lets a programmer visualize and explore a program's execution at varied levels of abstraction and drastically reduce the information a programmer must assimilate, with little loss of in sight is presented.
Abstract: Execution patterns are a new metaphor for visualizing execution traces of object-oriented programs We present an execution pattern view that lets a programmer visualize and explore a program's execution at varied levels of abstraction The view employs visual, navigational, and analytical techniques that accommodate lengthy, real-world traces By classifying repetitive behavior automatically into high-order execution patterns, we drastically reduce the inform ation a programmer must assimilate, with little loss of in sight
173 citations