Call for Cases

In order to facilitate the comparison of transformation tools, we are soliciting potential case studies. Specific areas of transformation case studies relevant to TTC are described on our aims and scope page. For TTC 2016, we continue to encourage the submission of cases relating to reactive transformation or to program transformation. If you have a suitable case study, please describe it shortly but as detailed as needed and submit it to the online submission system. Please include a reference solution to your case to support the evaluation of the correctness of submitted solutions.

Our program committee will select a small, but representative set of case studies to be used for the contest. Case descriptions should answer the following questions:

  • What is the context of the case? (provide a short description and references)
    • What is the subject to be modeled? (what are the input and output modeling languages?)
    • What is the purpose of the models? (what are they typically used for from a larger perspective than the proposed case study?)
  • What are variation points in the case? (divide up your case in core characteristics and extensions)
  • What are the criteria for evaluating the submitted solutions to the case?
    • Correctness test: which are the reference input/ouput documents (models/graphs) and how should they be used? Ideally, a case description includes a testsuite, as well as a test driver (The test driver can be an online web service, or a local script that can be deployed in SHARE (see http://is.tm.tue.nl/staff/pvgorp/share)
    • Which transformation tool-related features are important and how can they be classified? (e.g., formal analysis of the transformation program, rule debugging support, ...)
    • What transformation language-related challenges are important and how can they be classified? (e.g., declarative bidirectionality, declarative change propagation, declarative subgraph copying, cyclic graph support, typing issues, ...)
    • How to measure the quality of submitted solutions, at the design level? (e.g., measure the number of rules, the conciseness of rules, ...)
  • How can the solutions be evaluated (ranked) systematically using information technology? Please provide one of the following:
    • a simple spreadsheet (an evaluation form that can be aggregated easily (See for example http://goo.gl/QwxTAs),
    • a so-called "classification scheme" in ResearchR (See http://goo.gl/QA7npw) (or a similar web 2.0 platform.)

Please submit at http://www.easychair.org/conferences/?conf=ttc2016. Your submission should include:

  • a case description answering the above questions in PDF format using the CEUR-WS style and not exceeding 10 excluding references and appendices.
  • a URL to a publicly available repository hosting service (e.g., github, bitbucket) that contains all test artifacts as well as the evaluation / ranking instrument and any other necessary resources. The repository hosting should additionally provide a basic issue tracking system to keep track of any problems encountered by solution authors. This link should be referenced in the PDF document. Furthermore, in an appendix within the document should be clearly described all necessary instructions how to evaluate the the submission. For example, if the case includes a reference implementation (which is highly recommended), a set of steps to run the implementation should be provided.

The deadline for cases is 17 March 2016.

Subsequent Phases

Following the selection of a subset of the submitted cases by our programme committee, the following phases will be conducted.

Phase 2: Case solution submission. All those who like to participate in the contest will be asked to choose one or more case studies, take their favorite transformation tool and submit their solutions. A separate call for solutions will be distributed, after the cases have been selected.

Phase 3: Open peer review. The solution reviewing before the workshop will be done by other solution submitters. All solution submitters have to review three other solutions to the case that they have addressed. These reviews will not be anonymous, since these reviewers ideally will also be the opponents at the workshop. The purpose of the peer reviewing is that the participants get as much insight into the competitor's solutions as possible and also to raise potential problems. Case submitters should be available at this stage to resolve conflicting interpretations (if any) about the case description.

Phase 4: Workshop and live contest. Besides the presentations of the submitted solutions, the workshop will comprise a live contest. For more details (such as example cases and solutions from previous editions), please consult the TTC website: http://www.transformation-tool-contest.eu