Papers by Oscar Nierstrasz
... Copyright © 2007, 2008, 2009 by Andrew P. Black, Stéphane Ducasse, Oscar Nierstrasz andDamien... more ... Copyright © 2007, 2008, 2009 by Andrew P. Black, Stéphane Ducasse, Oscar Nierstrasz andDamien Pollet. ... Note that Squeak-dev refers to the developers' mailing-list, which can be browsed here: news.gmane.org/gmane.comp.lang.smalltalk.squeak.general ...
Abstract As systems evolve their structure change in ways not expected upfront. As time goes by, ... more Abstract As systems evolve their structure change in ways not expected upfront. As time goes by, the knowledge of the developers becomes more and more critical for the process of understanding the system. That is, when we want to understand a certain issue of the system we ask the knowledgeable developers. Yet, in large systems, not every developer is knowledgeable in all the details of the system. Thus, we would want to know which developer is knowledgeable in the issue at hand.
Abstract To understand a certain issue of the system we want to ask the knowledgeable developers.... more Abstract To understand a certain issue of the system we want to ask the knowledgeable developers. Yet, in large systems, not every developer is knowledgeable in all the details of the system. Thus, we would want to know which developer is knowledgeable in the issue at hand. In this paper we present the Chronia tool that implements the Ownership Map visualization to understand when and how different developers interacted in which way and in which part of the system
Abstract When reengineering legacy systems, it is crucial to assess if the legacy behavior has be... more 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.
Domain-specific languages (DSLs) are increasingly used as embedded languages within general-purpo... more Domain-specific languages (DSLs) are increasingly used as embedded languages within general-purpose host languages. DSLs provide a compact, dedicated syntax for specifying parts of an application related to specialized domains. Unfortunately, such language extensions typically do not integrate well with the development tools of the host language. Editors, compilers and debuggers are either unaware of the extensions, or must be adapted at a non-trivial cost.
Abstract With the success of agile methodologies more and more projects develop large test suites... more Abstract With the success of agile methodologies more and more projects develop large test suites to ensure that the system is behaving as expected. Not only do tests ensure correctness, but they also o er a live documentation for the code. However, as the system evolves, the tests need to evolve as well to keep up with the system, and as the test suite grows larger, the e ort invested into maintaining tests is a significant activity.
Abstract Software systems are complex and difficult to analyze. Reverse engineering is a complex ... more Abstract Software systems are complex and difficult to analyze. Reverse engineering is a complex analysis that usually involves combining different techniques and tools. Moreover, oftentimes the existing tools are not perfectly suitable for the task, and customization of existing tools, or development of new tools is required. Moose is an extensible reengineering environment designed to provide the necessary infrastructure for tool integration.
Abstract As software systems evolve, they become more complex and harder to understand and mainta... more Abstract As software systems evolve, they become more complex and harder to understand and maintain. Certain reverse engineering techniques attempt to reconstruct software models from source code with the help of a parser for the source language. Unfortunately a great deal of effort may be required to build a specialized parser for a legacy programming language or dialect.
Much of the knowledge about software systems is implicit, and therefore difficult to recover by p... more Much of the knowledge about software systems is implicit, and therefore difficult to recover by purely automated techniques. Architectural layers and the externally visible features of software systems are two examples of information that can be difficult to detect from source code alone, and that would benefit from additional human knowledge. Typical approaches to reasoning about data involve encoding an explicit meta-model and expressing analyses at that level.
Abstract When explaining the true dynamics of legacy systems, we are often short of good metaphor... more Abstract When explaining the true dynamics of legacy systems, we are often short of good metaphors that provoke on the audience the correct understanding of the situation. While war stories are entertaining and fun, the audience often summarizing them as that the original developers were not good and that they would not do the same mistakes. Sometimes managers miss the point that a software system is a living organism for which caretakers are important and that such a system can simply die.
Abstract Integration of multiple languages into each other and into an existing development envir... more Abstract Integration of multiple languages into each other and into an existing development environment is a difficult task. As a consequence, developers often end up using only internal DSLs that strictly rely on the constraints imposed by the host language. Infrastructures do exist to mix languages, but they often do it at the price of losing the development tools of the host language.
Abstract Analyzing historical information can show how a software system evolved into its current... more Abstract Analyzing historical information can show how a software system evolved into its current state, but it can also show which parts of the system are more evolution prone. Yet, historical analysis implies processing a vast amount of information which makes the interpretation difficult. To address this issue, we introduce the notion of history of source code artifacts as a first class entity and define measurements which summarize the evolution of such entities.
Abstract Knowing where to start reverse engineering a large software system, when no information ... more Abstract Knowing where to start reverse engineering a large software system, when no information other than the system's source code itself is available, is a daunting task. Having the history of the code (ie, the versions) could be of help if this would not imply analyzing a huge amount of data. We present an approach for identifying candidate classes for reverse engineering and reengineering efforts. Our solution is based on summarizing the changes in the evolution of object-oriented software systems by defining history measurements.
Abstract The notion of refactoring-transforming the source-code of an object-oriented program wit... more Abstract The notion of refactoring-transforming the source-code of an object-oriented program without changing its external behaviour-has been studied intensively within the last decade. This diversity has created a plethora of toy-examples, cases and code snippets, which make it hard to assess the current state-of-the-art. Moreover, due to this diversity, there is currently no accepted way of teaching good refactoring practices, despite the acknowledgment in the software engineering body of knowledge.
Software evolution research has focused mostly on analyzing the evolution of single software syst... more Software evolution research has focused mostly on analyzing the evolution of single software systems. However, it is rarely the case that a project exists as standalone, independent of others. Rather, projects exist in parallel within larger contexts in companies, research groups or even the open-source communities. We call these contexts software ecosystems.
Few real software systems are built completely from scratch nowadays. Instead, systems are built ... more Few real software systems are built completely from scratch nowadays. Instead, systems are built iteratively and incrementally, while integrating and interacting with components from many other systems. These systems also last longer than their developers might imagine—they are, in effect, eternal. Nevertheless the platforms, tools and environments we use to develop software are still largely based on an outmoded model that presupposes that software systems are closed and will not significantly evolve after deployment.
Abstract Dynamic analysis is increasingly attracting attention for debugging, profiling, and prog... more Abstract Dynamic analysis is increasingly attracting attention for debugging, profiling, and program comprehension. Ten to twenty years ago, many dynamic analyses investigated only simple method execution traces. Today, in contrast, many sophisticated dynamic analyses exist, for instance, for detecting memory leaks, analyzing ownership properties, measuring garbage collector performance, or supporting debugging tasks.
Uploads
Papers by Oscar Nierstrasz