Models@Runtime: The Development and Re-Configuration Management of Python Applications Using Formal Methods

Round 1

Reviewer 1 Report

The abstract must inform the most relevant implications of the study, as well as the research method (not the entire methodology, just the method) employed.

the introduction is too long and invades the method section. No fgures must appear here. Please separate the empirical content and ralocate it in the third  section. Please also reinforce the complexity issue of the first paragraph, it is essential to justify your study.

Backgroung section is ok.
Divide section 3 in antecedents, where you justify your methodology (here figure 1 fits well ) and the methodology itself. Currently, this part is ok, but a table with related previous study should help to positioning your study in front of the state ofthe art. (as your table 5, but regarding issues previou, not comparing after results)

Development is fine, but, if possible and viable, add a sensitive analysis, thete is, what if the main parameters slightly vary?

Concluion is incomplete, as a discussion on implication lacks. Who win what and why upon yor study?

see you in the next round.

Author Response

Please see the attachment.

Authors have attached the responses to both reviewers.

Please check comments to REVIEWER 1.

We would like to thank the reviewers for their fruitful comments,which have been taken into account in this new version of the paper.

Author Response File: Author Response.pdf

Reviewer 2 Report

The manuscript proposes a model-driven approach to assist in the development and re-configuration for Python applications. The model is based on Petri Net, and two modules (i.e., Model Execution Engine and Python Execution Engine) are designed and implemented to fulfill the requirements of development and re-configuration. A case study is also described in the manuscript to demonstrate the usage of the proposed model-driven approach.

Overall, the context of the research question and the solution to the research question are well-described. Readers of the journal can get insight into the model-driven approach through the manuscript. However, it is suggested that the benefit, the trade-off, and the usage of the proposed approach can be elaborated in more detail. Thus, the contribution of the manuscript can be presented explicitly.

Several comments and suggestions to the manuscript are stated as the following.

1. It is suggested that the authors can elaborate on the advantage of the model-driven approach and the models@runtime first. Through the examples (i.e., the grading example and the SLA example) mentioned in the manuscript, readers might not understand the benefit brought by the model-driven approach and the models@runtime. Instead, they might choose the traditional software development process to develop and maintain software systems. The contribution of the manuscript could be underestimated.

2. Based on comment 1, the authors can elaborate on the cost and benefit of the proposed approach from the perspective of software developers. Thus, readers can understand the trade-off between the proposed approach and the traditional software development process.

3. Based on the manuscript, the increasing complexity is also a major challenge to software development and maintenance. Can the proposed approach deal with the above challenge (e.g., a huge change happens in the SLA case)? Could authors share some insights into this?

4. In Section 1 (Introduction), the manuscript states that "using the models@runtime technique, developers could perform this change without stopping the execution." However, in Section 3: Proposal, the manuscript states that "This process involves suspending the execution, until the developers add the corresponding GRRs to rewrite the current structure and, therefore, satisfy the new requirement." Is continuous execution a major feature of the proposed approach? It is suggested that the authors can elaborate on this in more detail.

5. In Section 1 (Introduction), the manuscript states that "The behavior of applications can be changed by applying Graph Rewriting Rules (GRRs)". The change of the structure is shown by GRRs. However, the implementation of the new statement is not clear. Should software developers write the new statement in GRR? Where is the new statement? What process should software developers follow? It is suggested that the authors can elaborate on this in more detail. 

6. In Figure 3, the "P5" and "P6" should be "P4" and "P5" respectively. In addition, the caption of the figure should be checked again.

7. In Section 3.2 (Framework Architecture and Behavior), it seems the framework components designed in this study exchange messages through TCP/IP sockets. Is it necessary to build the client/server architecture for the operation of the proposed approach? Authors can share some insights into it.

8. In Section 3.3 (Development, reconfiguring and monitoring of Python applications), the manuscript states that "The framework provides this function by clicking on the green button labeled Run." However, there is no figure about this. It is suggested that the authors can refine the sentences or provide corresponding figures for readers.

9. The authors provide information about related studies in Section 5. The information is very useful. However, it is suggested that the authors can elaborate on the improvement (or the difference) of the manuscript in more detail for readers. Thus, readers can get more insight into the contribution of the manuscript.

10. Can the source code be generated automatically through the proposed approach?

Author Response

Please see the attachment.

Authors have attached the responses to both reviewers.

Please check comments to REVIEWER 1.

We would like to thank the reviewers for their fruitful comments,which have been taken into account in this new version of the paper.

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Authors have satisfactorily addressed most issues