The software engineering initiative of DLR

Haupt, Carina; Meinel, Michael; Schlauch, Tobias

doi:10.1145/3194747.3194753

Cited by 7 publications

(3 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Open science and especially artifact availability suffer from a variety of similar issues as open-access publishing (Swan 2006;Haupt et al 2018;). 25 -Properly publishing an artifact requires a lot of initial (e.g., documentation, packaging) and maintenance effort (e.g., updating information when an author's affiliation changes).…”

Section: Reasons Not To Publish Artifactsmentioning

confidence: 99%

“…While double-blind reviews can reduce reviewing biases (Le Goues et al 2018) and are preferred by a majority of authors (Prechelt et al 2018), the authors also have to anonymize their artifacts and data ). 26 -Researchers may be unaware or uninterested in the benefits of publishing artifacts (Haupt et al 2018). -Selecting a suitable software license is simple when publishing artifacts that have been developed from scratch.…”

Section: Reasons Not To Publish Artifactsmentioning

confidence: 99%

See 1 more Smart Citation

Publish or perish, but do not forget your software artifacts

et al. 2020

View full text Add to dashboard Cite

Open-science initiatives have gained substantial momentum in computer science, and particularly in software-engineering research. A critical aspect of open-science is the public availability of artifacts (e.g., tools), which facilitates the replication, reproduction, extension, and verification of results. While we experienced that many artifacts are not publicly available, we are not aware of empirical evidence supporting this subjective claim. In this article, we report an empirical study on software artifact papers (SAPs) published at the International Conference on Software Engineering (ICSE), in which we investigated whether and how researchers have published their software artifacts, and whether this had scientific impact. Our dataset comprises 789 ICSE research track papers, including 604 SAPs (76.6 %), from the years 2007 to 2017. While showing a positive trend towards artifact availability, our results are still sobering. Even in 2017, only 58.5 % of the papers that stated to have developed a software artifact made that artifact publicly available. As we did find a small, but statistically significant, positive correlation between linking to artifacts in a paper and its scientific impact in terms of citations, we hope to motivate the research community to share more artifacts. With our insights, we aim to support the advancement of open science by discussing our results in the context of existing initiatives and guidelines. In particular, our findings advocate the need for clearly communicating artifacts and the use of non-commercial, persistent archives to provide replication packages.

show abstract

Section: Reasons Not To Publish Artifactsmentioning

confidence: 99%

Section: Reasons Not To Publish Artifactsmentioning

confidence: 99%

Publish or perish, but do not forget your software artifacts

et al. 2020

View full text Add to dashboard Cite

show abstract

“…Also, research software such as ESMs are often seen as a by-product of scientific research rather than a distinct contribution by itself (Storer, 2017). However, since researchers rely on these software models, software quality is an important goal in many research facilities (Haupt, Schlauch, & Meinel, 2018). High-quality software requires not only efforts in development but also maintenance.…”

Section: Introductionmentioning

confidence: 99%

Facilitating Test-Driven Development via Domain-Specific Languages in Computational Science Software Engineering

Gundlach,

Jung,

Hasselbring

2023

Preprint

View full text Add to dashboard Cite

Research software plays a critical role in computational science. Therefore, the software should be of high quality. Producing such software involves efforts not only in initial development, but also during maintenance. One concept for improving the quality of software and reducing maintenance efforts is Test-Driven Development (TDD), which involves implementing tests, e.g., unit tests, as a specification for development. The effects are high test coverage and better overall software quality, but also additional effort in implementing tests. By separation of concerns, such additional efforts can be facilitated through the use of tailored notations such as domain-specific languages (DSLs). DSLs provide different levels of abstraction, for example, to separate the definition of tests from other concerns in software development. Not only does this incentivize research software engineers (RSEs) to write tests, but it also helps reduce the time required to write tests. The DSL TDD-DSL addresses this to facilitate the implementation of TDD using the Fortran Unit Testing Framework (UTF) pFUnit 4.0. TDD-DSL is focused on unit test definition and source code integration. It is implemented in Python for system under tests (SUTs) written in Fortran 90 or later. To reduce the effort of defining tests, TDD-DSL separates the test definition from the implementation and setup. Especially the latter can cause additional effort in practice, which can be mitigated by using code generators provided with the DSL tooling. The DSL allows describing test conditions as assertions and test cases as collections of assertions. TDD-DSL provides content assist within code editors for the underlying UTF, reducing the effort required in its deployment. It also supports parsing the SUT to expand the content assist with source code information and high-level error messaging for the test description. The content assist includes publicly available variables, types, functions and routines. TDD-DSL further supports the definition of unit values such as SI units to help Scientific Modelers check unit values in the software at runtime. For this purpose, the DSL tooling enables the generation of code templates for new implementations in the source code according to the defined tests. To simplify extending the DSL and improve overall maintainability, the DSL tooling employs the language server protocol (LSP) and also public available tools such as the ANTLR4 grammar. Using LSP also enables a multi-editor support to integrate the DSL tooling into different editors and IDEs. In this paper we report on the design and implementation of the DSL and its tooling as well as the evaluation with Scientific Modelers and RSEs.

show abstract