Results 1 - 10
of
50
Locating Features in Source Code
, 2003
"... Understanding the implementation of a certain feature of a system requires to identify the computational units of the system that contribute to this feature. In many cases, the mapping of features to the source code is poorly documented. In this paper, we present a semi-automatic technique that reco ..."
Abstract
-
Cited by 133 (2 self)
- Add to MetaCart
Understanding the implementation of a certain feature of a system requires to identify the computational units of the system that contribute to this feature. In many cases, the mapping of features to the source code is poorly documented. In this paper, we present a semi-automatic technique that reconstructs the mapping for features that are triggered by the user and exhibit an observable behavior. The mapping is in general not injective; that is, a computational unit may contribute to several features. Our technique allows to distinguish between general and specific computational units with respect to a given set of features. For a set of features, it also identifies jointly and distinctly required computational units.
Hipikat: Recommending pertinent software development artifacts
- In ICSE’03
"... A newcomer to a software project must typically come up-to-speed on a large, varied amount of information about the project before becoming productive. Assimilating this information in the open-source context is difficult because a newcomer cannot rely on the mentoring approach that is commonly used ..."
Abstract
-
Cited by 98 (4 self)
- Add to MetaCart
A newcomer to a software project must typically come up-to-speed on a large, varied amount of information about the project before becoming productive. Assimilating this information in the open-source context is difficult because a newcomer cannot rely on the mentoring approach that is commonly used in traditional software developments. To help a newcomer to an open-source project become productive faster, we propose Hipikat, a tool that forms an implicit group memory from the information stored in a project’s archives, and that recommends artifacts from the archives that are relevant to a task that a newcomer is trying to perform. To investigate this approach, we have instantiated the Hipikat tool for the Eclipse open-source project. In this paper, we describe the Hipikat tool, we report on a qualitative study conducted with a Hipikat mock-up on a mediumsized in-house project, and we report on a case study in which Hipikat recommendations were evaluated for a task on Eclipse. 1.
Recovering high-level views of object-oriented applications from static and dynamic information
- Proceedings ICSM’99 (International Conference on Software Maintenance
, 1999
"... Recovering architectural documentation from code is crucial to maintaining and reengineering software systems. Reverse engineering and program understanding approaches are often limited by the fact that (1) they propose a fixed set of predefined views and (2) they consider either purely static or pu ..."
Abstract
-
Cited by 61 (19 self)
- Add to MetaCart
Recovering architectural documentation from code is crucial to maintaining and reengineering software systems. Reverse engineering and program understanding approaches are often limited by the fact that (1) they propose a fixed set of predefined views and (2) they consider either purely static or purely dynamic views of the application. In this paper we present an environment supporting the generation of tailorable views of object-oriented systems from both static and dynamic information. Our approach is based on the combination of user-defined queries which allow an engineer to create high-level abstractions and to produce views using these abstractions.
Towards the Reverse Engineering of UML Sequence Diagrams for Distributed, Multithreaded Java software
, 2004
"... This paper proposes a comprehensive methodology and instrumentation infrastructure for the reverse-engineering of UML (Unified Modeling Language) sequence diagrams from dynamic analysis. One motivation is of course to help people understand the behavior of systems with no (complete) documentation. H ..."
Abstract
-
Cited by 45 (1 self)
- Add to MetaCart
This paper proposes a comprehensive methodology and instrumentation infrastructure for the reverse-engineering of UML (Unified Modeling Language) sequence diagrams from dynamic analysis. One motivation is of course to help people understand the behavior of systems with no (complete) documentation. However, such reverse-engineered dynamic models can also be used for quality assurance purposes. They can, for example, be compared with design sequence diagrams and the conformance of the implementation to the design can thus be verified. Furthermore, discrepancies can also suggest failures in meeting the specifications. We formally define our approach using metamodels and consistency rules. The instrumentation is based on Aspect-Oriented Programming in order to alleviate the overhead usually associated with source code instrumentation. A case study is discussed to demonstrate the applicability of the approach on a concrete example.
Using Dynamic Information for the Iterative Recovery of Collaborations and Roles
- In Proceedings of ICSM ’2002 (International Conference on Software Maintenance
, 2002
"... Modeling object-oriented applications using collaborations and roles is now well accepted. Collaboration-based or role-based designs decompose an application into tasks performed by a subset of the applications' classes. Collaborations provide a larger unit of understanding and reuse than classes, a ..."
Abstract
-
Cited by 37 (5 self)
- Add to MetaCart
Modeling object-oriented applications using collaborations and roles is now well accepted. Collaboration-based or role-based designs decompose an application into tasks performed by a subset of the applications' classes. Collaborations provide a larger unit of understanding and reuse than classes, and are an important aid in the maintenance and evolution of the software. This kind of design information is lost, however, at the implementation level, making it hard to maintain and evolve an existing software application. The extraction of collaborations from code is therefore an important issue in design recovery. In this paper we propose an iterative approach which uses dynamic information to support the recovery and understanding of collaborations. We describe a tool we have developed to support our approach and demonstrate its use on a case study.
Understanding the Behavior of Java Programs
, 2000
"... To fully understand the underlying architecture of an object-oriented software system, both static and dynamic analyses are needed. Dynamic reverse engineering techniques are especially important for understanding the run-time behavior of objects in a distributed object systems and in systems that r ..."
Abstract
-
Cited by 36 (0 self)
- Add to MetaCart
To fully understand the underlying architecture of an object-oriented software system, both static and dynamic analyses are needed. Dynamic reverse engineering techniques are especially important for understanding the run-time behavior of objects in a distributed object systems and in systems that rely heavily on polymorphism. Shimba, a prototype reverse engineering environment, has been built to support understanding an existing Java software system. The dynamic event trace information is generated automatically as a result of running the target system under a customized sdk [14] debugger and viewed as scenario diagrams using the SCED tool [5]. In SCED, state diagrams can be synthesized automatically from scenario diagrams. This facility is used to visualize the total behavior of a selected object or method, disconnected from the rest of the system. This paper demonstrates how Shimba aids understanding the behavior of Java programs. A case study in made to validate the usefulness of ...
Representing Concerns in Source Code
, 2003
"... Many program evolution tasks involve source code that is not modularized as a single unit. Furthermore, the source code relevant to a change task often implements different concerns, or high-level concepts that a developer must consider. Finding and understanding concerns scattered in source code is ..."
Abstract
-
Cited by 33 (6 self)
- Add to MetaCart
Many program evolution tasks involve source code that is not modularized as a single unit. Furthermore, the source code relevant to a change task often implements different concerns, or high-level concepts that a developer must consider. Finding and understanding concerns scattered in source code is a difficult task that accounts for a large proportion of the effort of performing program evolution. One possibility to mitigate this problem is to produce textual documentation that describes scattered concerns. However, this approach is impractical because it is costly, and because, as a program evolves, the documentation becomes inconsistent with the source code. The thesis of this dissertation is that a description of concerns, representing program structures and linked to source code, that can be produced cost-effectively during program investigation activities, can help developers perform software evolution tasks more systematically, and on different versions of a system. To validate the claims of this thesis, we have developed a model for a structure, called concern graph, that describes concerns in source code in terms of relations between program elements. The model also defines precisely the notion of inconsistency between a concern graph and the
Implicit Context: Easing Software Evolution and Reuse
- IN 8TH INTERNATIONAL SYMPOSIUM ON THE FOUNDATIONS OF SOFTWARE ENGINEERING
, 2000
"... Software systems should consist of simple, conceptually clean software components interacting along narrow, well-defined paths. All too often, this is not reality: complex components end up interacting for reasons unrelated to the functionality they provide. We refer to knowledge within a component ..."
Abstract
-
Cited by 30 (5 self)
- Add to MetaCart
Software systems should consist of simple, conceptually clean software components interacting along narrow, well-defined paths. All too often, this is not reality: complex components end up interacting for reasons unrelated to the functionality they provide. We refer to knowledge within a component that is not conceptually required for the individual behaviour of that component as extraneous embedded knowledge (EEK). EEK creeps into a system in many forms, including dependences upon particular names and the passing of extraneous parameters. This paper proposes the use of implicit context as a means for reducing EEK in systems by combining a mechanism to reflect upon what has happened in a system, through queries on the call history, with a mechanism for altering calls to and from a component. We demonstrate the benefits of implicit context by describing its use to reduce EEK in the Java TM Swing library.
Static And Dynamic Reverse Engineering Techniques for Java Software Systems
, 2000
"... This dissertation shows that integration of dynamic and static information aids the performance of reverse engineering tasks. An experimental environment called Shimba has been built to support reverse engineering of Java software systems. The static information is extracted from Java byte code [118 ..."
Abstract
-
Cited by 29 (4 self)
- Add to MetaCart
This dissertation shows that integration of dynamic and static information aids the performance of reverse engineering tasks. An experimental environment called Shimba has been built to support reverse engineering of Java software systems. The static information is extracted from Java byte code [118]. It can be viewed and analyzed with the Rigi reverse engineering tool [74]. The dynamic event trace information is generated automatically as a result of running the target system under a customized Java Development Kit (JDK) debugger. Information about the dynamic control flow of selected objects or methods can also be extracted. The event trace can then be viewed and analyzed with the SCED tool. To support model comprehension, the models built can be used to modify and improve each other by means of information exchange, model slicing, and building abstractions

