Human-written API documentation often becomes outdated, requiring developers to update it manually. Researchers have proposed identifying outdated API name references in documentation, yet have not addressed updating API documentation. Now, emerging large language models (LLMs) are capable of generating code examples and text descriptions. Then, a key question arises: Can LLMs assist in updating API documentation? In this paper, we propose an approach for leveraging an LLM to update API documentation with code change information. To evaluate this approach, we select five open-source projects that manage documentation revisions on GitHub and analyze the differences in documentation between two releases to derive ground truths. We then assess the accuracy of LLM-generated updates by comparing them to the ground truths. Our results show that LLM-generated updates achieve higher METEOR than outdated API documentation (0.771 vs 0.679). It indicates that the LLM updates are more similar to the human updates than the outdated documentation. Our results also reveal that LLMs update code-related information in API documentation with a maximum F1 score of$\mathbf{0. 9 2 1}$.

Prompt-based large language models (LLMs) have demonstrated their ability to perform tasks with minimal or no additional training data. In the context of issue classification, researchers have actively explored the capabilities of LLMs in classifying issue reports. However, existing studies still face limitations in accuracy. This study replicates an LLM-based issue classification study using GPT-3.5 Turbo and explores variants, such as adopting different models like Llama$3.18 B$and GPT-4o. Experimental results show that the classifier fine-tuned with GPT-3.5 Turbo still yields the same accuracy as shown in the original research and that the classifier fine-tuned with Llama$3.18 B(0.8004)$yields an F1-score of 0.0535 lower than that of the classifier fine-tuned with GPT-3.5 Turbo (0.8467). On the other hand, the classifier with GPT-4o (0.8639) yields an average$\mathbf{F 1}$-score$\mathbf{0. 0 1}$higher than that of the classifier fine-tuned with GPT-3.5 Turbo (0.8467). Additionally, the project-agnostic classifier fine-tuned with GPT-4o yields the highest$\mathbf{F 1}$-score of$\mathbf{0. 8 6 8 0}$. These findings contribute to advancing LLM-based issue classification by providing experimental insights into the accuracy of LLMs in this issue classification task.

Microservices architectures offer significant advantages, including independent deployment, scalability, and improved system flexibility. Nonetheless, as the number of services increases, systems often experience diminished modularity, resulting in architectural degradation. We propose a comprehensive modularity assessment framework that systematically integrates three dimensions of modularity for a microservice system: inter-service coupling, intra-service cohesion, and data dependency. An integrated modularity score that aggregates these individual metrics presents overall architectural modularity. We also evaluate the propose framework by experimenting with seven JavaScript-based microservice systems. The evaluation result demonstrates the framework's ability to identify modularity-related issues and variations across services. The findings provide actionable insights to inform architectural decision-making and promote more maintainable, scalable, and modular microservice systems.

• To our knowledge, this is the first method that focuses on connectors for the reconstruction of an execution view. • We developed the tools that automate the steps of the method, which can handle large volumes of input data. • To evaluate our proposed method, we conducted three real-world case studies. • Our case studies demonstrated that the proposed approach reconstructs an execution architecture with more than 86 % F1-score and less than 13.9 person-hours. • The tools and evaluation results are available at our GitHub repository. An execution architecture view plays a crucial role in depicting the structure of a software system at runtime and analyzing its execution aspects, such as concurrency and performance. However, such execution views are frequently missing in real-world practices. Therefore, researchers have endeavored to reconstruct execution architecture views from software systems. However, existing approaches either require domain experts’ knowledge or are applicable only to systems with particular architecture styles. In this paper, we propose a systematic approach to reconstructing an execution architecture view, without prior knowledge of the components and connectors in the target system. With the proposed approach, by defining a candidate set of execution view connectors and mapping rules from source code to execution view connectors, developers can reconstruct an execution view. To evaluate the proposed approach, we applied it to three real-world software systems. Our evaluation results show that the proposed approach reconstructs an execution architecture with a higher than 86 % F1-score and less than 13.9 person-hours.

In GitHub, open-source software (OSS) developers label issue reports. As issue labeling is a labor-intensive manual task, automatic approaches have developed to label issue reports. However, those approaches have shown limited performance. Therefore, it is necessary to analyze the performance of predicting labels for an issue report. Understanding labels with high performance and those with low performance can help improve the performance of automatic issue labeling tasks. In this paper, we investigate the performance of individual label prediction. Our investigation uncovers labels with high performance and those with low performance. Our results can help researchers to understand the different characteristics of labels and help developers to develop a unified approach that combines several effective approaches for different kinds of issues.

Issue reports are documents with which users report problems and state their opinions on a software system. Issue reports are useful for software maintenance, but managing them requires developers’ considerable manual effort. To reduce such effort, previous studies have mostly suggested methods for automatically classifying issue reports. However, most of those studies classify issue reports according to issue types, based only on whether the report is relevant to a bug, whether the report is duplicated, or whether the issue is functional or nonfunctional. In this paper, we intend to link issue reports and a user manual and so propose a deep learning model-based method that classifies issue reports according to software features that are described in the user manual in order to help developers relate issue reports to features to make changes to a software system. In order to classify issue reports according to the feature descriptions in a user manual, our method uses a deep learning technique with a word embedding technique. The key insight in our method is that the sections of a user manual that describe software features contain the words and sentences similar to those in issue reports. Based on the insight, we construct a classification model that learns the feature descriptions (i.e. sections) in a user manual and classifies issue reports according to the feature descriptions. We evaluate the proposed method by comparing its classification performance with that of the state-of-the-art method, TicketTagger. The experimental results show that the proposed method yields 10% ∼ 24% higher classification f1-score than that of TicketTagger. We also experiment with two deep learning models and four word embedding techniques and find out that the Convolution Neural Network model with FastText (or GloVe) yields the best performance. Our study shows the feasibility of classifying issue reports according to software features, which can be the basis for successive studies to classify issue reports into software features.

Application programming interfaces (APIs) continually evolve to meet ever-changing user needs, and documentation provides an authoritative reference for their usage. However, API documentation is commonly outdated because nearly all of the associated updates are performed manually. Such outdated documentation, especially with regard to API names, causes major software development issues. In this paper, we propose a method for automatically updating outdated API names in API documentation. Our insight is that API updates in documentation can be derived from API implementation changes between code revisions. To evaluate the proposed method, we applied it to four open source projects. Our evaluation results show that our method, FreshDoc, detects outdated API names in API documentation with 48 percent higher accuracy than the existing state-of-the-art methods do. Moreover, when we checked the updates suggested by FreshDoc against the developers' manual updates in the revised documentation, FreshDoc detected 82 percent of the outdated names. When we reported 40 outdated API names found by FreshDoc via issue tracking systems, developers accepted 75 percent of the suggestions. These evaluation results indicate that FreshDoc can be used as a practical method for the detection and updating of API names in the associated documentation.

Software extensibility, the capability of adding new functions to a software system, is established based on software architecture. Therefore, developers need to evaluate the capability when designing software architecture. To support the evaluation, researchers have proposed metrics based on quality models or scenarios. However, those metrics are vague or subjective, depending on specific systems and evaluators. We propose the extensibility metric for software architecture (EMSA), which represents the degree of extensibility of a software system based on its architecture. To reduce the subjectivity of the metric, we first identify a typical task of adding new functions to a software system. Second, we define the metrics based on the characteristics of software architecture and its changes and finally combine them into a single metric. The originality of EMSA comes from defining metrics based on software architecture and extensibility tasks and integrating them into one. Furthermore, we made an effort to translate the degree into effort estimation expressed as person-hours. To evaluate EMSA, we conducted two types of user studies, obtaining measurements in both a laboratory and a real-world project. The results show that the EMSA estimation is reasonably accurate [6.6% MMRE and 100% PRED(25%)], even in a real-world project (93.2% accuracy and 8.5% standard deviation).

Recommendation systems are intended to increase developer productivity by recommending files to edit. These systems mine association rules in software revision histories. However, mining coarse-grained rules using only edit histories produces recommendations with low accuracy, and can only produce recommendations after a developer edits a file. In this work, we explore the use of finer-grained association rules, based on the insight that view histories help characterize the contexts of files to edit. To leverage this additional context and fine-grained association rules, we have developed MI, a recommendation system extending ROSE, an existing edit-based recommendation system. We then conducted a comparative simulation of ROSE and MI using the interaction histories stored in the Eclipse Bugzilla system. The simulation demonstrates that MI predicts the files to edit with significantly higher recommendation accuracy than ROSE (about 63 over 35 percent), and makes recommendations earlier, often before developers begin editing. Our results clearly demonstrate the value of considering both views and edits in systems to recommend files to edit, and results in more accurate, earlier, and more flexible recommendations.

Recently, several graphical tools have been proposed to help developers avoid becoming disoriented when working with large software projects. These tools visualize the locations that developers have visited, allowing them to quickly recall where they have already visited. However, developers also spend a significant amount of time exploring source locations to visit, which is a task that is not currently supported by existing tools. In this work, we propose a graphical code recommender NavClus, which helps developers find relevant, unexplored source locations to visit. NavClus operates by mining a developer's daily interaction traces, comparing the developer's current working context with previously seen contexts, and then predicting relevant source locations to visit. These locations are displayed graphically along with the already explored locations in a class diagram. As a result, with NavClus developers can quickly find, reach, and focus on source locations relevant to their working contexts. http://www.youtube.com/watch?v=rbrc5ERyWjQ.

When performing software evolution tasks, programmers spend a significant amount of time exploring the code base to find methods, fields or classes that are relevant to the task at hand. We propose a new clustering approach called NavClus to recommend collections of code relevant to tasks. By gradually aggregating navigation sequences from programmers' interaction history, NavClus clusters pieces of code that are contextually related. The resulting clusters become the basis for NavClus to recommend collections of code that are likely to be relevant to the programmer's given task. We compare NavClus and TeamTracks, the state of the art code recommender for sharing navigation data among programmers. The results show that NavClus recommends pieces of code relevant to tasks considerably better than TeamTracks.

For software with nontrivial size and complexity, it is not feasible to manually perform architecture reconstruction. Therefore it is essential for the software architecture miner who is mining architecture from the existing software to have a well-defined software architecture reconstruction process that helps incorporate as much tool use as possible at the appropriate steps of architecture reconstruction. There are some existing software architecture reconstruction frameworks but they do not provide guidelines on how to systematically utilize tools to produce architecture views for a reconstruction purpose. In this paper, we propose a framework for tool-based software architecture reconstruction. This framework consists of a generic process for software architecture reconstruction and the steps to derive from it a concrete tool-based process to be used for actual architecture reconstruction. The architecture miner can use this framework to analyze source code for modifying source code as well as to reconstruct software architecture from source code.

We report on an exploratory study we conducted to investigate what kind of diagrammatic tool support, if any, is desired by programmers. The study involved 19 professional programmers working at three different companies. We found that the study participants desire a wide range of information content in diagrams, which would change depending upon the particular context of use. Meeting these needs may require flexible, adaptive and responsive diagramming tool support.