ASE 2019 Research Papers

Accepted Papers

Call for Papers

The IEEE/ACM Automated Software Engineering (ASE) Conference series is the premier research forum for automated software engineering. Each year, it brings together researchers and practitioners from academia and industry to discuss foundations, techniques, and tools for automating the analysis, design, implementation, testing, and maintenance of large software systems. ASE 2019 invites high quality contributions describing significant, original, and unpublished results.

Solicited topics include, but are not limited to:

• Automated reasoning techniques
• Component-based service-oriented systems
• Cloud computing
• Computer-supported cooperative work
• Configuration management
• Data mining for software engineering
• Domain modeling and meta-modeling
• Empirical software engineering
• Human-computer interaction
• Knowledge acquisition and management
• Mobile app development
• Maintenance and evolution
• Model-driven development
• Program synthesis & transformations, automated defect repair
• Program comprehension
• Reverse engineering and re-engineering
• Recommender systems for software engineering
• Requirements engineering
• Specification languages
• Software analysis
• Software architecture and design
• Software product line engineering
• Software visualization
• Software security and trust; data privacy
• Testing, verification, and validation

Three categories of submissions are solicited:

• Technical Research Papers should describe innovative research in automating software development activities or automated support to users engaged in such activities. They should describe a novel contribution to the field and should carefully support claims of novelty with citations to the relevant literature. Where a submission builds upon previous work of the author(s), the novelty of the new contribution must be clearly described with respect to the previous work but the author identity should not be revealed, i.e., prior work should be referenced in the third person, to reflect the double-blind review policy. Papers should also clearly discuss how the results were validated.

• Experience Papers should describe a significant experience in applying automated software engineering technology and should carefully identify and discuss important lessons learned, so that other researchers and/or practitioners can benefit from the experience. Of special interest are experience papers that report on industrial applications of automated software engineering.

• New Ideas Papers should describe novel research directions in automating software development activities or automated support to users engaged in such activities. New ideas submissions are intended to describe well-defined research ideas that are at an early stage of investigation and not fully validated, but are argued to be plausible.

SUBMISSION

Abstracts and papers must be submitted electronically through the ASE 2019 HotCRP submission site.

All submissions must be in PDF format and conform, at time of submission, to the IEEE Conference Proceedings Formatting Guidelines (title in 24pt font and full text in 10pt type, LaTeX users must use \documentclass[10pt,conference]{IEEEtran} without including the compsoc or compsocconf option).

Papers submitted to ASE 2019 must not have been published elsewhere and must not be under review or submitted for review elsewhere when being considered for ASE 2019. Authors should be aware of the ACM Policy and Procedures on Plagiarism and the IEEE Plagiarism FAQ.

To check for double submission and plagiarism issues, the chairs reserve the right to (1) share the list of submissions with the PC Chairs of other conferences, affiliated with ACM or IEEE, with overlapping review periods and (2) use external plagiarism detection software, under contract to the ACM or IEEE, to detect violations of these policies.

Technical Research Papers and Experience Papers must not exceed 10 pages (including figures) plus up to 2 pages that contain ONLY references. Exceeding this limit will be grounds for rejection without review. Experience papers should contain the words “experience paper” in the abstract to ensure that they are evaluated in the right category.

New Ideas Papers must not exceed 4 pages (including figures AND references).

Supplementary material can be uploaded via the HotCRP site, but PC members have no obligation to look at the supplementary material.

ASE 2019 will again pursue a double-blind review process. If you have any questions, please see FAQs and/or contact the PC chairs at ase19-chairs@lip6.fr. Authors are encouraged to double check the conflicts of interest on their papers in HotCRP shortly after the submission deadline.

All submissions must be in English.

Submissions that do not adhere to these limits or that violate the formatting guidelines will be desk-rejected without review.

The authors are strongly encouraged to use the HotCRP format checker on their submissions. Note that the format checker is not perfect. In particular, it can complain about small fonts in figures, footnotes, or references. As long as the main text follows the requested format, and the figures are readable, the paper will not be rejected for format violations. If you have any concerns, please contact the program chairs at ase19-chairs@lip6.fr.

ACCEPTED PAPERS

We strongly encourage authors of accepted papers to archive the research artifacts, including code and data, associated with their ASE papers. Software Heritage (presented in a keynote at ASE 2018) requires only providing a URL to an existing archive: https://www.softwareheritage.org/2019/08/05/saving-and-referencing-research-software-in-software-heritage/ Other often used solutions, focusing on data, include Figshare (https://figshare.com/) and Zenodo (https://zenodo.org/).

For example, here is one webpage that describes how to release the data: https://ineed.coffee/5205/how-to-disclose-data-for-double-blind-review-and-make-it-archived-open-data-upon-acceptance/

If you have questions not answered below, please contact the program chairs at ase19-chairs@lip6.fr

Q: Why Double Blind?

There are many reasons for a submission track to employ a double-blind review process – not the least being the considerable number of requests to do so from the community. For more information on motivation for double-blind reviewing, see Claire Le Goues’ very well argued, referenced, and evidenced blog posting in favor of double-blind review processes for Software Engineering conferences. See also a list of double-blind resources from Robert Feldt, as well as a more formal study of the subject by Moritz Beller and Alberto Bacchelli.

Q: How to prepare your paper for double-blind reviewing?

You must make every reasonable effort to honor the double-blind review process, but you do not need to guarantee that your identity is undiscoverable. The double-blind aspect of the review process is not to set up an adversarial identity-discovery process. Essentially, the guiding principle should be to maximize the number of people who could plausibly be authors, subject to the constraint that no change is made to any technical details of the work. Therefore, you should ensure that the reviewers are able to read and review your paper without needing to know who any of the authors are. Specifically, this involves at least adhering to the following three points:

• Omit all authors’ names and affiliations from the title page. If you have acknowledgements, do not mention any names or organizations.

• Refer to your own work in the third person. You should not change the names of your own previously published tools, approaches, or systems, because this would clearly compromise the review process; it would also violate the constraint that “no change is made to any technical details of the work”. Instead, refer to the authorship or provenance of tools, approaches, or systems in the third person, so that it is credible that another author could have written your paper.

• If possible, do not rely on supplementary material (your web site, your GitHub repository, your YouTube channel, a companion technical report or thesis) in the paper. Such material might reveal author identities. It is possible to post a link to an anonymous GitHub repository, but the repository should be checked carefully for any information that could reveal author identity, and it could be helpful to warn the reader that accessing the repository could reveal author identity. It is also possible to submit supplementary material with the paper, but again it is necessary to check the material carefully for anything that can reveal author identity.

Q: Can I disseminate non-blinded version of my submitted work by discussing it with colleagues, giving talks, publishing it at arXiv, etc.?

You can discuss and present your work that is under submission at small meetings (e.g., job talks, visits to research labs, a Dagstuhl or Shonan meeting), but you should avoid broadly advertising it in a way that reaches the reviewers even if they are not searching for it. For example, you should not discuss your work with members of the program committee, publicize your work on mailing lists or media that are widely shared and can reach the program committee, or post the submitted work on arXiv or a similar site just shortly before submitting to the conference. One option is to make a tech report at your institution, which allows someone to cite the work, if need be, like arXiv, but doesn’t have the same degree of visibility.

Q: I published a previous version of my work on arXiv or as a tech report at my institution. Do I need to cite it, and if so how?

A paper on arXiv or a tech report is not a publication. If there is a need to cite the old version because it contains some important information that is not in the submission, then the previous version can be cited anonymously, if a normal citation would reveal the names of the authors. If the submission completely subsumes the previous version, then there is no need to cite the previous version at all.

Q: I previously published an earlier version of this work elsewhere than arXiv. What should I do about citing that previous work?

If the previous work is published in a peer-reviewed venue, then it should be cited, but in the third person so that it is not revealed that the cited work and the submitted paper share one or more authors. This would include posters, but only if the poster is accompanied by a paper in the conference proceedings. Posters that are not represented in the proceedings can be ignored.

Q: What about a PhD or master’s thesis?

It’s perfectly fine to publish work arising from a PhD or master’s degree, and there’s no need to cite it in a submission that is undergoing double-blind review because prior dissertation publication does not compromise novelty. In the final camera-ready version of the paper, please do cite the dissertation to acknowledge its contribution.

In general, the guideline is that the author’s job is to ensure that the submission is readable and reviewable, without the reviewers needing to know the identities of the submission’s authors. You do not need to make it impossible for the reviewers to discover the authors’ identities. The referees will be trying hard not to discover the authors’ identities, so they will likely not be searching the web to check whether there is a tech report or other unpublished material related to this work.

This FAQ is based on guidelines for double-blind reviewing from ASE 2018 (http://www.ase2018.com/?p=author_instructions) and ICSE 2019 (https://2019.icse-conferences.org/track/icse-2019-Submitting-to-ICSE2019-Q-A).