History data of edit operations are more beneficial than those stored in version control systems since they provide detailed information on how source code was changed. Meanwhile, a large number of recorded edit operations discourage developers and researchers from roughly understanding the changes. To assist with this task, it is desirable that they easily obtain traceability links for changed program elements over two source code snapshots before and after a code change. In this paper, we propose a graph representation called Operation History Graph (OHG), which presents code change information with such traceability links that are inferred from the history of edit operations. An OHG instance is generated by parsing any source code snapshot restored by edit histories and combining resultant abstract syntax trees (ASTs) into a single graph structure. To improve the performance of building graph instances, we avoided simply maintaining every program element. Any program element presenting the inner-structure of methods and non-changed elements are omitted. In addition, we adopted a lightweight static analysis for type name resolving to reduce required memory resource in the analysis while the accuracy of name resolving is preserved. Moreover, we assign a specific ID to each node and edge in the graph instance so that a part of the graph data can be separately stored and loaded on demand. These decisions make it feasible to build, manipulate, and store the graph with limited computer resources. To demonstrate the usefulness of the proposed operation history graph and verify whether detected traceability links are sufficient to reveal actual changes of program elements, we implemented tools to generate and manipulate OHG instances. The evaluation on graph generation performance shows that our tool can reduce the required computer resource as compared to another tool authors previously proposed. Moreover, the evaluation on traceability shows that OHG provides traceability links with sufficient accuracy as compared to the baseline approach using GumTree.

Understanding which refactoring transformations were performed is in demand in modern software constructions. Traditionally, many researchers have been tackling understanding code changes with history data derived from version control systems. In those studies, problems of the traditional approach are pointed out, such as entanglement of multiple changes. To alleviate the problems, operation histories on IDEs' code editors are available as a new source of software evolution data nowadays. By replaying such histories, we can investigate past code changes in a fine-grained level. However, the prior studies did not provide enough evidence of their effectiveness for detecting refactoring transformations. This paper describes an experiment in which participants detect refactoring transformations performed by other participants after investigating the code changes with an operation-replay tool and diff tools. The results show that both approaches have their respective factors that pose misunderstanding and overlooking of refactoring transformations. Two negative factors on divided operations and generated compound operations were observed in the operation-based approach, whereas all the negative factors resulted from three problems on tangling, shadowing, and out-of-order of code changes in the difference-based approach. This paper also shows seven concrete examples of participants' mistakes in both approaches. These findings give us hints for improving existing tools for understanding code changes and detecting refactoring transformations.

Once a software product has been released, a large number of software products may be derived from an original single product. Management and maintenance of product variants are important, but those are hardly cared because developers do not make efforts for the further maintainability in the initial phase of software development. However, history of products would be lost in typical cases and developers have only source code of products in the worst case. In this paper, we approximate the evolution history of software products using source code of them. Our key idea is that two successive products are the most similar pair of products in evolution history, and have many similar source files. We did an experiment to compare the analysis result with actual evolution history. The result shows 78% (on average) of edges in the extracted trees are consistent with the actual evolution history of the products.

Modularity is an effective evaluation approach for understanding the structural quality of evolutionary software. However, there are many diverse ways to measure it. In this paper, we analyze and compare various modularity metrics that have been studied in different domains to assess their applicability to evolutionary software analysis. Through extensive experiments with artificial DSMs and open-source software, we find that the correlations of those metrics are generally high despite their differences. However, our experiments show that a certain metric can be more sensitive to particular modular factors, hence applying of comprehensive modularity metrics must be taken into consideration.

In this letter, we apply dynamic software updating to long-lived applications on the DDS middleware while minimizing service interruption and satisfying Quality of Service (QoS) requirements. We dynamically updated applications which run on a commercial DDS implementation to demonstrate the applicability of our approach to dynamic updating. The results show that our update system does not impose an undue performance overhead–all patches could be injected in less than 350 ms and the maximum CPU usage is less than 17%. In addition, the overhead on application throughput due to dynamic updates ranged from 0 to at most 8% and the deadline QoS of the application was satisfied while updating.

In a software maintenance phase, since quality assurance engineers frequently only change source codes, the consistency between the source codes and their specification documents cannot be kept. In this paper we propose a supporting technique for changing specification documents automatically so that the specifications can be consistent with the source codes. In our technique, we represent a program with multiple graphs and we consider the changes on programs as the modification of the graphs. The modification of the graphs is formalized with a sequence of the operation on the graphs. We design the rules of how to relate the operations on program graphs to the operations on graphs that represent specification documents. By applying these rules, we can detect what modification and which parts of the specification document should be made to maintain the consistency between the specification and the program, when the program is modified.

This paper describes the design of the reflective concurrent object-oriented specification language RMondel. RMondel is designed for the specification and modeling of distributed systems. It allows the development of executable specifications which may be modified dynamically. Reflection in RMondel is supported by two fundamental features that are: Structural Reflection (SR) and Behavioral Reflection (BR). Reflection is the capability to monitor and modify dynamically the structure and the behavior of the system. We show how the features of the language are enhanced using specific meta-operations and meta-objects, to allow for the dynamic modification of types (classes) and instances using the same language. RMondel specification can be modified by adding or modifying types and instances to get a new adapted specification. Consistency is checked dynamically at the type level as well as at the specification level. At the type level, structural and behavioral constrations are defined to preserve the conformance of types. At the specification level, a transaction mechanism and a locking protocol are defined to ensure the consistency of the whole specification.