International Journal of Software Engineering and Knowledge Engineering

Data, information, knowledge, and wisdom forms a progressive relationship. Information is formed by data collation. Knowledge is filtered, refined, and processed from relevant information. Wisdom is based on knowledge and is accumulated through experience. This paper uses the progressive relationship of service data, information, knowledge, and wisdom to explain the expression of service knowledge graph. It is an increasingly challenging demand to discover trusted Cloud service providers with service data, information, and knowledge. We propose an efficient method of trusted service provider discovery based on service knowledge graphs, called PDG (Provider Discovery based on Graphs), to ensure that each service instance of composite services in Cloud systems is trustworthy. PDG evaluates the outputs of service providers in service classes with the help of additional service information. According to the additional service information, service knowledge is generated and trusted service providers can be found easily. PDG improves the accuracy of processing results by automatically replacing data provided by untrusted service providers with results provided by trusted service providers.

Design pattern detection can provide useful insights to support software comprehension. Accurate and complete detection of pattern instances are extremely important to enable software usability improvements. However, existing design pattern detection approaches and tools suffer from the following problems: incomplete description of design pattern instances, inaccurate behavioral constraint checking, and inability to support novel design patterns. This paper presents a general framework to detect design patterns while solving these issues by combining static and dynamic analysis techniques. The framework has been instantiated for typical behavioral and creational patterns, such as the observer pattern, state pattern, strategy pattern, and singleton pattern to demonstrate the applicability. Based on the open-source process mining toolkit ProM, we have developed an integrated tool that supports the whole detection process for these patterns. We applied and evaluated the framework using software execution data containing around 1,000,000 method calls generated from eight synthetic software systems and three open-source software systems. The evaluation results show that our approach can guarantee a higher precision and recall than existing approaches and can distinguish state and strategy patterns that are indistinguishable by the state-of-the-art.

Question Answering systems over Knowledge Graphs (KG) answer natural language questions using facts contained in a knowledge graph, and Simple Question Answering over Knowledge Graphs (KG-SimpleQA) means that the question can be answered by a single fact. Entity linking, which is a core component of KG-SimpleQA, detects the entities mentioned in questions, and links them to the actual entity in KG. However, traditional methods ignore some information of entities, especially entity types, which leads to the emergence of entity ambiguity problem. Besides, entity linking suffers from out-of-vocabulary (OOV) problem due to the limitation of pre-trained word embeddings. To address these problems, we encode questions in a novel way and encode the features contained in the entities in a multilevel way. To evaluate the enhancement of the whole KG-SimpleQA brought by our improved entity linking, we utilize a relatively simple approach for relation prediction. Besides, to reduce the impact of losing the feature during the encoding procedure, we utilize a ranking algorithm to re-rank (entity, relation) pairs. According to the experimental results, our method for entity linking achieves an accuracy of 81.8% that beats the state-of-the-art methods, and our improved entity linking brings a boost of 5.6% for the whole KG-SimpleQA.

When encountering bug issues, developers tend to search the bug repository and commit repository for references. However, the links between bug reports and commits in version control systems are often missed, and the information in bug repository and commit repository can provide is simple. When developers search a bug issue, they can only get the information of bug reports or commits, which are loose and difficult for developers to refer. What’s more, many searching results are not accurate. To deal with these problems, this paper proposes an approach to deal with the bug and commit information with the topic model, and construct bug knowledge graph as a service to assist in bug search. In addition, as the amount of bug related information continuously increase, it is time-consuming to update the data. We can automatically update the bug knowledge graph with the LTM topic model (a lifelong topic model). Finally, the experiment with the bug reports from Bugzilla@Mozilla and the corresponding commits from Github was conducted. The experiment results show that our approach is effective and efficient to help developers search relevant bugs for reference by constructing the bug knowledge as a service.

Do developers postpone fixing Technical Debt (TD) in software systems? TD is a metaphor that refers to short-term decisions in software development that may affect the cost of the software development life cycle. The bad smell is an imperfect solution in the software system that negatively impacts the internal software quality and maintainability. In this paper, we will study five open-source software projects (OSSPs) that have several releases and also estimate the numbers of architecture smells (ASs), design smells (DSs), and code smells (CSs) for every release. Designite will be used to detect smells. We describe a case study conducted to explore the following: (1) What is the average smells density for architecture, design, and code smells in an OSSP? (2) Does the density of each smell type increase over multiple releases? (3) What percentage of each smell-type density is eliminated by refactoring? We collected around 2 million LOC from five OSSPs that have multiple releases from the GitHub repository to statistically analyze the software concerning the smells as indicators of TD. We find 36% of Architecture Technical Debt (ATD) is Cyclic Dependency, while 33% of Design Debt (DD) is Cyclically-dependent Modularization. More than 70% of Code Debt (CD) is Magic Number. Even though the developers do refactoring between releases, the TD density in general increases. On average, by refactoring, developers remove around 48%, 16%, and 22% from the introduced ATD, DD, and CD from their next release, respectively.

Business-to-Business (B-to-B) software development companies develop services to satisfy their customers’ requirements. Developers should prioritize customer satisfaction because customers greatly influence agile software development. However, satisfying current customer’s requirements may not fulfill actual users or future customers’ requirements because customers’ requirements are not always derived from actual users. To reconcile these differences, developers should identify conflicts in their strategic plan. This plan should consider current commitments to end users and their intentions as well as employ a data-driven approach to adapt to rapid market changes. A persona models an end user representation in human-centered design. Although previous works have applied personas to software development and proposed data-driven software engineering frameworks with gap analysis between the effectiveness of commitments and expectations, the significance of developers’ commitment and quantitative decision-making are not considered. Developers often do not achieve their business goal due to conflicts. Hence, the target of commitments should be validated. To address these issues, we propose Data-Driven Persona Retrospective (DDR) to help developers plan future releases. DDR, which includes the Persona Significance Index (PerSI) to reflect developers’ commitments to end users’ personas, helps developers identify a gap between developers’ commitments to personas and expectations. In addition, DDR identifies release situations with conflicts based on PerSI. Specifically, we define four release cases, which include different situations and issues, and provide a method to determine the release case based on PerSI. Then we validate the release cases and their determinations through a case study involving a Japanese cloud application and discuss the effectiveness of DDR.