30 research outputs found
Using Structural and Semantic Information to Identify Software Components
Component Based Software Engineering (CBSE) seeks to promote the reuse of software by using existing software modules into the development process. However, the availability of such a reusable component is not immediate and is costly and time consuming. As an alternative, the extraction from preexisting OO software can be considered.In this work, we evaluate two community detection algorithms for the task of software components identification. Considering 'components' as 'communities', the aim is to evaluate how independent, yet cohesive, the components are when extracted by structurally informed algorithms.We analyze 412 Java systems and evaluate the cohesion of the extracted communities using four document representation techniques. The evaluation aims to find which algorithm extracts the most semantically cohesive, yet separated communities.The results show a good performance in both algorithms, however, each has its own strengths. Leiden extracts less cohesive, but better separated, and better clustered components that depend more on similar ones. Infomap, on the other side, creates more cohesive, slightly overlapping clusters that are less likely to depend on other semantically similar components
Extracting software modules as communities
Component Based Software Engineering (CBSE) is a development discipline based on the availability of software components, that are described and indexed for internal or external, present or future, reuse. Although the creation of reusable components is requested to be designed from scratch, this is often time consuming and expensive. An alternative is to extract such components from pre-existing OO software. In this work, we compare two different community detection algorithms to perform components extraction from existing software. Considering 'components' as 'communities', the aim is to evaluate how independent, yet cohesive, the components are, when extracted by community detection algorithms. Using a small sample of 3 Java systems, we show how the components can be extracted based on structural information. Furthermore, we consolidate the extracted components using semantic information, to ensure their cohesion. We use three document representation techniques to evaluate the internal cohesion of components. The results show that both algorithms perform well with each having their own strengths. Leiden extracts less cohesive, but better separated, and better clustered components that depend less on similar ones. Infomap, on the other side, creates more cohesive, slightly overlapping clusters that are more likely to depend more on other semantically similar components. </p
LabelGit:A Dataset for Software Repositories Classification using Attributed Dependency Graphs
Software repository hosting services contain large amounts of open-source
software, with GitHub hosting more than 100 million repositories, from new to
established ones. Given this vast amount of projects, there is a pressing need
for a search based on the software's content and features. However, even though
GitHub offers various solutions to aid software discovery, most repositories do
not have any labels, reducing the utility of search and topic-based analysis.
Moreover, classifying software modules is also getting more importance given
the increase in Component-Based Software Development. However, previous work
focused on software classification using keyword-based approaches or proxies
for the project (e.g., README), which is not always available. In this work, we
create a new annotated dataset of GitHub Java projects called LabelGit. Our
dataset uses direct information from the source code, like the dependency graph
and source code neural representations from the identifiers. Using this
dataset, we hope to aid the development of solutions that do not rely on
proxies but use the entire source code to perform classification.Comment: 5 pages, 2 figures, 1 tabl
Multi-granular Software Annotation using File-level Weak Labelling
One of the most time-consuming tasks for developers is the comprehension of
new code bases. An effective approach to aid this process is to label source
code files with meaningful annotations, which can help developers understand
the content and functionality of a code base quicker. However, most existing
solutions for code annotation focus on project-level classification: manually
labelling individual files is time-consuming, error-prone and hard to scale.
The work presented in this paper aims to automate the annotation of files by
leveraging project-level labels; and using the file-level annotations to
annotate items at larger levels of granularity, for example, packages and a
whole project.
We propose a novel approach to annotate source code files using a weak
labelling approach and a subsequent hierarchical aggregation. We investigate
whether this approach is effective in achieving multi-granular annotations of
software projects, which can aid developers in understanding the content and
functionalities of a code base more quickly.
Our evaluation uses a combination of human assessment and automated metrics
to evaluate the annotations' quality. Our approach correctly annotated 50% of
files and more than 50\% of packages. Moreover, the information captured at the
file-level allowed us to identify, on average, three new relevant labels for
any given project.
We can conclude that the proposed approach is a convenient and promising way
to generate noisy (not precise) annotations for files. Furthermore,
hierarchical aggregation effectively preserves the information captured at
file-level, and it can be propagated to packages and the overall project
itself.Comment: Accepted at the Journal of Empirical Software Engineerin
Antipatterns in software classification taxonomies
Empirical results in software engineering have long started to show that findings are unlikely to be applicable to all software systems, or any domain: results need to be evaluated in specified contexts, and limited to the type of systems that they were extracted from. This is a known issue, and requires the establishment of a classification of software types. This paper makes two contributions: the first is to evaluate the quality of the current software classifications landscape. The second is to perform a case study showing how to create a classification of software types using a curated set of software systems. Our contributions show that existing, and very likely even new, classification attempts are deemed to fail for one or more issues, that we named as the ‘antipatterns’ of software classification tasks. We collected 7 of these antipatterns that emerge from both our case study, and the existing classifications. These antipatterns represent recurring issues in a classification, so we discuss practical ways to help researchers avoid these pitfalls. It becomes clear that classification attempts must also face the daunting task of formulating a taxonomy of software types, with the objective of establishing a hierarchy of categories in a classification
Antipatterns in Software Classification Taxonomies
Empirical results in software engineering have long started to show that
findings are unlikely to be applicable to all software systems, or any domain:
results need to be evaluated in specified contexts, and limited to the type of
systems that they were extracted from. This is a known issue, and requires the
establishment of a classification of software types.
This paper makes two contributions: the first is to evaluate the quality of
the current software classifications landscape. The second is to perform a case
study showing how to create a classification of software types using a curated
set of software systems.
Our contributions show that existing, and very likely even new,
classification attempts are deemed to fail for one or more issues, that we
named as the `antipatterns' of software classification tasks. We collected 7 of
these antipatterns that emerge from both our case study, and the existing
classifications.
These antipatterns represent recurring issues in a classification, so we
discuss practical ways to help researchers avoid these pitfalls. It becomes
clear that classification attempts must also face the daunting task of
formulating a taxonomy of software types, with the objective of establishing a
hierarchy of categories in a classification.Comment: Accepted for publish at the Journal of Systems and Softwar