Catalogue Search | MBRL
Are you sure you want to remove the book from the shelf?
{{itemTitle}}
17,924
result(s) for
"Software ecosystems."
Sort by:
Code comment generation based on graph neural network enhanced transformer model for code understanding in open-source software ecosystems
In open-source software ecosystems, the scale of source code is getting larger and larger, and developers often use various methods (good code comments or method names, etc.) to make the code easier to read and understand. However, high-quality code comments or method names are often unavailable due to tight project schedules or other reasons in open-source software ecosystems such as Github. Therefore, in this work, we try to use deep learning models to generate appropriate code comments or method names to help software development and maintenance, which requires a non-trivial understanding of the code. Therefore, we propose a Graph neural network enhanced Transformer model (GTrans for short) to learn code representation to understand code better. Specifically, GTrans learns code representation from code sequences and graphs. We use a Transformer encoder to capture the global representation from code sequence and a graph neural network (GNN) encoder to focus on the local details in the code graph, and then use a decoder to combine both global and local representations by attention mechanism. We use three public datasets collected from GitHub to evaluate our model. In an extensive evaluation, we show that GTrans outperforms the state-of-the-art models up to 3.8% increase in METEOR metrics on code comment generation and outperforms the state-of-the-art models by margins of 5.8%–9.4% in ROUGE metrics on method name generation after some adjustments on the structure. Empirically, we find the method name generation task depends on more local information than global, and the code comment generation task is in contrast. Our data and code are available at
https://github.com/zc-work/GTrans
.
Journal Article
Modeling and Security in Cloud Ecosystems
Clouds do not work in isolation but interact with other clouds and with a variety of systems either developed by the same provider or by external entities with the purpose to interact with them; forming then an ecosystem. A software ecosystem is a collection of software systems that have been developed to coexist and evolve together. The stakeholders of such a system need a variety of models to give them a perspective of the possibilities of the system, to evaluate specific quality attributes, and to extend the system. A powerful representation when building or using software ecosystems is the use of architectural models, which describe the structural aspects of such a system. These models have value for security and compliance, are useful to build new systems, can be used to define service contracts, find where quality factors can be monitored, and to plan further expansion. We have described a cloud ecosystem in the form of a pattern diagram where its components are patterns and reference architectures. A pattern is an encapsulated solution to a recurrent problem. We have recently expanded these models to cover fog systems and containers. Fog Computing is a highly-virtualized platform that provides compute, storage, and networking services between end devices and Cloud Computing Data Centers; a Software Container provides an execution environment for applications sharing a host operating system, binaries, and libraries with other containers. We intend to use this architecture to answer a variety of questions about the security of this system as well as a reference to design interacting combinations of heterogeneous components. We defined a metamodel to relate security concepts which is being expanded.
Journal Article
Investigating user feedback from a crowd in requirements management in software ecosystems
Requirements management is a process that aims to ensure that the needs of stakeholders are met through delivering adequate and quality software products. However, requirements management becomes challenging in open and dynamic environments with multiple stakeholders who belong to different organizations and collaborate over a common technological platform as in software ecosystems (SECO). In SECO, distinct crowds of users provide requirements, change requests, and bug reports through feedback across multiple communication channels. However, user feedback from a crowd is often not considered in requirements management activities in SECO because of its complexity. Our study aims to investigate whether and how user feedback from a crowd is considered in requirements management in SECO. To achieve this goal, we conducted a field study based on interviews with 20 professionals involved in activities in this context. We identified ten mechanisms used to gather user feedback from a crowd in requirements management in SECO and six approaches to analyze this feedback. User feedback from a crowd influences requirements management in SECO, making it more open and collaborative. Moreover, the continuous flow of user feedback makes crowd-based requirements engineering (CrowdRE) possible in SECO.
Journal Article
Developer reactions to protestware in open source software: the cases of color.js and es5.ext
There is growing concern about maintainers self-sabotaging their work in order to take political or economic stances, a practice referred to as “protestware”. Our objective is to understand the discourse around discussions on such an attack, how it is received by the community, and whether developers respond to the attack in a timely manner. We study two notable protestware cases i.e., colors.js and es5-ext. Results indicate that protestware discussions are spread more quickly on the GitHub platform, while security vulnerabilities are faster on social media. By establishing a taxonomy of protestware discussions, we identify posts that express stances and provide technical mitigation instructions. We applied a thematic analysis to 684 protestware related posts to identify five major themes during the discussions: i. disseminate and response, ii. stance, iii. reputation, iv. communicative styles, v. rights and ethics. This work sheds light on the nuanced landscape of protestware discussions, offering insights for both researchers and developers into maintaining a healthy balance between the political or social actions of developers and the collective well-being of the open-source community.
Journal Article
VulNet: Towards improving vulnerability management in the Maven ecosystem
Developers rely on software ecosystems such as Maven to manage and reuse external libraries (i.e., dependencies). Due to the complexity of the used dependencies, developers may face challenges in choosing which library to use and whether they should upgrade or downgrade a library. One important factor that affects this decision is the number of potential vulnerabilities in a library and its dependencies. Therefore, state-of-the-art platforms such as Maven Repository (MVN) and Open Source Insights (OSI) help developers in making such a decision by presenting vulnerability information associated with every dependency. In this paper, we first conduct an empirical study to understand how the two platforms, MVN and OSI, present and categorize vulnerability information. We found that these two platforms may either overestimate or underestimate the number of associated vulnerabilities in a dependency, and they lack prioritization mechanisms on which dependencies are more likely to cause an issue. Hence, we propose a tool named VulNet to address the limitations we found in MVN and OSI. Through an evaluation of 19,886 versions of the top 200 popular libraries, we find VulNet includes 90.5% and 65.8% of the dependencies that were omitted by MVN and OSI, respectively. VulNet also helps reduce 27% of potentially unreachable or less impactful vulnerabilities listed by OSI in test dependencies. Finally, our user study with 24 participants gave VulNet an average rating of 4.5/5 in presenting and prioritizing vulnerable dependencies, compared to 2.83 (MVN) and 3.14 (OSI).
Journal Article
Performance measurement practices in software ecosystem
Purpose
– This paper aims to present the results of a survey study on performance and healthiness measurement practices in a Tunisian software ecosystem. The study evaluates the five dimensions of software ecosystem healthiness: robustness, productivity, interoperability, stakeholder's (customer and employee) satisfaction and creativity in the Tunisian context.
Design/methodology/approach
– In this research a questionnaire was developed and distributed to the 150 Tunisian software ecosystem partners.
Findings
– The results of this study show that managers should analyze the robustness, productivity, interoperability, stakeholder's (customer and employee) satisfaction and creativity measures simultaneously in order to enhance the quality of the decision-making process.
Research limitations/implications
– In this study, one software ecosystem and 60 partners were examined. Future research should increase the number of respondents and the software ecosystem in order to generalize these results.
Originality/value
– This paper is unique in reflecting the general practices and perceptions of software ecosystem organizations on performance and healthiness measures in Tunisia.
Journal Article