Proceedings Article10.1145/225014.225045
Reverse engineering of legacy code exposed
Bruce W. Weide,Wayne D. Heym,Joseph E. Hollingsworth +2 more
- 23 Apr 1995
- pp 327-331
TL;DR: These observations serve as a wake-up call to those who dream of developing high-quality software systems by transforming them from defective raw materials until software engineers learn to design systems that support modular reasoning about their behavior.
read more
Abstract: Reverse engineering of large legacy software systems generally cannot meet its objectives because it cannot be cost-effective. There are two main reasons for this. First, it is very costly to "understand" legacy code sufficiently well to permit changes to be made safely, because reverse engineering of legacy code is intractable in the usual computational complexity sense. Second, even if legacy code could be cost-effectively reverse engineered, the ultimate objective - re-engineering code to create a system that will not need to be reverse engineered again in the future - is presently unattainable. Not just crusty old systems, but even ones engineered today, from scratch, cannot escape the clutches of intractability until software engineers learn to design systems that support modular reasoning about their behavior. We hope these observations serve as a wake-up call to those who dream of developing high-quality software systems by transforming them from defective raw materials.
read more
Chat with Paper
AI Agents for this Paper
Find similar papers on Google Scholar, PubMed and Arxiv
Write a critical review of this paper
Analyze citations of this paper to find unaddressed research gaps
Citations
•Book
Reverse engineering
Kathryn A. Ingle
- 01 Jan 1994
TL;DR: Understanding of Reverse Engineering is provided and some of the advantages and issues in detail are discussed in detail.
475
•Proceedings Article
Assessing the relevance of identifier names in a legacy software system
Nicolas Anquetil,Timothy C. Lethbridge +1 more
- 30 Nov 1998
TL;DR: This paper defines what it means to have a "reliable naming convention", how this can be tested and under what conditions, and presents examples from the particular legacy software system the authors are studying as well as from the literature.
122
How do professionals perceive legacy systems and software modernization
Ravi Khadka,Belfrit Victor Batlajery,Amir Saeidi,Slinger Jansen,Jurriaan Hage +4 more
- 31 May 2014
TL;DR: The results show that practitioners value their legacy systems highly, the challenges they face are not just technical, but also include business and organizational aspects.
Reasoning about Software-Component Behavior
Murali Sitaraman,Steven Atkinson,Gregory Kulczycki,Bruce W. Weide,Timothy J. Long,Paolo Bucci,Wayne D. Heym,Scott M. Pike,Joseph E. Hollingsworth +8 more
- 27 Jun 2000
TL;DR: There is a simple, understandable, teachable, practical, and provably sound and relatively complete reasoning system for component-based software systems that addresses the reasoning problem.
60
Specification and Verification with References
Bruce W. Weide,Wayne D. Heym +1 more
- 01 Jan 2001
TL;DR: Making pointers/references visible to component clients needlessly complicates specification and verification, and the issues involved are the added difficulty for clients in understanding component specifications, and in reasoning about client program behavior.
References
Mental models and software maintenance
TL;DR: Vidoetaped protocols of experienced programmers as they enhanced a personnel data base program are analyzed and it is suggested that there are two strategies for program understanding, the systematic strategy and the as-needed strategy.
273
Functional representation as design rationale
TL;DR: The functional representation (FR) framework, which captures the causal component of a design rationale (DR), is described, which encodes the designer's account of the causal processes in the device that culminate in achieving its function.
230
Precise documentation of well-structured programs
TL;DR: A new form of program documentation that is precise, systematic and readable, which comprises a set of displays supplemented by a lexicon and an index and which presents a program fragment in such a way that its correctness can be examined without looking at any other display.
119
Reasoning about object-oriented programs that use subtypes
Gary T. Leavens,William E. Weihl +1 more
- 01 Sep 1990
TL;DR: Formal specification and verification techniques for such programs that mimic informal ideas about object-oriented programs by using subtype relationships to classify the behavior of objects of different types are described.
100