119 lines
12 KiB
Markdown
119 lines
12 KiB
Markdown
tags:: [[#zotero]]
|
||
title:: @MODELS_2025_paper_8
|
||
item-type:: [[document]]
|
||
original-title:: MODELS_2025_paper_8
|
||
language:: en
|
||
links:: [Local library](zotero://select/library/items/2WFLI77E), [Web library](https://www.zotero.org/users/1039502/items/2WFLI77E)
|
||
|
||
- ### Attachments
|
||
- [PDF](zotero://select/library/items/FQNS7KRE) {{zotero-imported-file FQNS7KRE, "MODELS_2025_paper_8.pdf"}}
|
||
- ### Notes
|
||
- I'm reviewing a research paper and I took the following notes:
|
||
|
||
# Annotazioni
|
||
(23/5/2025, 17:16:01)
|
||
|
||
- “Abstract—Verification” (“MODELS_2025_paper_8”, p. 1) #ffd400
|
||
*The abstract needs to be reworked. It's not convey exactly the point, it's not clear and it does not present what the paper is about.*
|
||
|
||
- “The Data Transfer Architecture Model [1] is a formal model that can describe both specifications and architectures of RESTful microservices, and can generate executable prototypes of the services with selecting data transfer methods between PUSH and PULL styles.” (“MODELS_2025_paper_8”, p. 1) #ffd400
|
||
|
||
- “However, the model does not have sufficient capability to specify practical microservices as it cannot directly represent the creation and deletion of resources or their hierarchical structure.” (“MODELS_2025_paper_8”, p. 1) #ffd400
|
||
|
||
- “we extend the model to allow hierarchical access to the internal structure of resources, as well as the creation and deletion of resources by structuring resource states” (“MODELS_2025_paper_8”, p. 1) #5fb236
|
||
|
||
- “verification and validation of specifications have been emphasized in the development of large-scale systems that require high reliability.” (“MODELS_2025_paper_8”, p. 1) #5fb236
|
||
|
||
- “However, little work has done on formal specification languages for microservices.” (“MODELS_2025_paper_8”, p. 1) #ffd400
|
||
*Are you sure? I think it's important to better support such a sentence. it is important to clarify what kind of specification the authors are referring to, the intended goal of the specification, etc.*
|
||
|
||
- “whether the choice of PUSH or PULL data transfer conforms to a given formal specification” (“MODELS_2025_paper_8”, p. 1) #ffd400
|
||
*These terms PUSH and PULL suddenly appear even in the abstract without proper context.*
|
||
|
||
- “Therefore, in this paper, we extend the Data Transfer Architecture Model to allow hierarchical access to the internal structure of resources, as well as the creation and deletion of resources by structuring resource states. In this paper, we call the extended model the extended Data Transfer Architecture Model or simply DTRAM.” (“MODELS_2025_paper_8”, p. 1) #ff6666
|
||
*PLease make the paragarph more clear. There are many occurrences of sentences that are not properly written and that go directly to the point. It is necessary to provide preliminary and background information. For isntance DTRAM is mentioned without giving a proper context or discussing the main concept of the approach and what's its focus/goal.*
|
||
|
||
- “we conducted an experiment that compares DTRAM with a well-known formal specification language Alloy [2] with 24 professional engineers who have 3 or more years of Web services development experience.” (“MODELS_2025_paper_8”, p. 1) #5fb236
|
||
|
||
- “DTRAM is significantly better suited than Alloy for describing the specifications of the microservices.” (“MODELS_2025_paper_8”, p. 1) #ffd400
|
||
*With respect to what criteria? To what exteent DTRAM is better than Alloy. What are the comparative criteria that have been considered?*
|
||
|
||
- “II. MOTIVATING EXAMPLE” (“MODELS_2025_paper_8”, p. 2) #ffd400
|
||
*BY reading section 2 I don't see what's the challenge, what are the issues that authors want to focus. It is necessary to explicitly state what's the problem with the presented motivating example.*
|
||
|
||
- “The system is constructed as RESTful microservices that have the resource hierarchies shown in Fig. 1.” (“MODELS_2025_paper_8”, p. 2) #ffd400
|
||
*instead of using a figure I would use a listing.*
|
||
|
||
- “A. Overview of Data Transfer Architecture Model” (“MODELS_2025_paper_8”, p. 2) #ffd400
|
||
*By reading this section, I don't what's novel with respect to existing modeling languages to specify architectures (e.g., AADL, etc)*
|
||
|
||
- “specifications and architectures of RESTful microservices.” (“MODELS_2025_paper_8”, p. 2) #5fb236
|
||
|
||
- “At the specification level, 1) and 2) are needed to describe external behavior. Therefore, resources and their state transitions are the basis of the specification model.” (“MODELS_2025_paper_8”, p. 2) #5fb236
|
||
|
||
- “The model has another construct, channel.” (“MODELS_2025_paper_8”, p. 2) #5fb236
|
||
|
||
- “the input (in), output (out) and reference (ref) ports,” (“MODELS_2025_paper_8”, p. 2) #5fb236
|
||
|
||
- “arbitrary number of resources can connect to each port.” (“MODELS_2025_paper_8”, p. 2) #5fb236
|
||
|
||
- “An event channel directly receives an event from the outside of the system as a message, and the states of all outputside resources immediately change.” (“MODELS_2025_paper_8”, p. 3) #5fb236
|
||
|
||
- “In the Data Transfer Architecture Model, such a chain of message transfers is assumed to be performed simultaneously within a single event frame” (“MODELS_2025_paper_8”, p. 3) #5fb236
|
||
|
||
- “Here, v(_, _) and x(_, _) represent the state transition functions of resources v and x, respectively” (“MODELS_2025_paper_8”, p. 3) #5fb236
|
||
|
||
- “Since resources of the Data Transfer Architecture Model do not support hierarchical composition, they cannot directly represent the hierarchical structures of ‘resources’ in RESTful microservices. Therefore, we intend to extend the Data Transfer Architecture Model to allow hierarchical access to the internal structure of resources, as well as the creation and deletion of resources.” (“MODELS_2025_paper_8”, p. 3) #5fb236
|
||
|
||
- “To bind each path parameter to the enclosing channel, we allow a channel to have its specific parameter named selector.” (“MODELS_2025_paper_8”, p. 3) #5fb236
|
||
|
||
- “In addition, to support one to many transfer (i.e., distribution of data) and many to one transfer (i.e., collection of data), we introduce hierarchical structures into channels.” (“MODELS_2025_paper_8”, p. 3) #5fb236
|
||
|
||
- “the tool allows the user to choose a data transfer method between the PULL and PUSH-styles for each data transfer, and to generate an executable JAX-RS prototype that conforms to the chosen data transfer methods.” (“MODELS_2025_paper_8”, p. 7) #a28ae5
|
||
|
||
- “Although a described model can be tested by generating, compiling and deploying a prototype, this process is too burdensome for frequent iteration.” (“MODELS_2025_paper_8”, p. 7) #ffd400
|
||
*What's the prototype is able to do?*
|
||
|
||
- “We design the simulation feature to virtually execute the described model in an interactive manner.” (“MODELS_2025_paper_8”, p. 7) #ffd400
|
||
*What's the goal of this simulation?*
|
||
|
||
- “As shown in Fig. 7, each resource is represented as an ellipse within the simulation window.” (“MODELS_2025_paper_8”, p. 7) #ffd400
|
||
*Who is supposed to be the user of the developed simulation tool? in which development process/phase?*
|
||
|
||
- “To evaluate the suitability of DTRAM for describing specifications of RESTful microservices and the effectiveness of the simulation feature, we pose the following research questions.” (“MODELS_2025_paper_8”, p. 8) #ffd400
|
||
|
||
- “RQ1: Which representation model, DTRAM or Alloy, is more suitable for describing behavior of RESTful microservices?” (“MODELS_2025_paper_8”, p. 8) #5fb236
|
||
|
||
- “RQ2: Is the visualization of the simulation by visual modeling tool helpful for understanding DTRAM models?” (“MODELS_2025_paper_8”, p. 8) #5fb236
|
||
|
||
- “model representation rather than the specifications of each description language in the evaluation in RQ1.” (“MODELS_2025_paper_8”, p. 8) #5fb236
|
||
|
||
- “The effectiveness of the simulation will depend on the method of visualization. Therefore, we examine the effectiveness of the visualization in RQ2.” (“MODELS_2025_paper_8”, p. 8) #5fb236
|
||
|
||
- “We recruited 24 professional Web service engineers as participants through a crowdsourcing service on the condition of having 3 or more years of development experience” (“MODELS_2025_paper_8”, p. 8) #5fb236
|
||
|
||
- “We provided the participants with the experiment procedure and the details of the experimental tasks on a website. The participants were asked to answer the questionnaire after completing each task. All tasks can be completed within a web browser. Each task is related to a Web service. As target Web services, we prepared two services; SimpleTwitter (ST for short) as a SNS and InventoryManagement (IM for short) as an enterprise microservice. ST is a simple tweet system and IM is a simplified inventory management system for a liquor store. Also, we prepared four models that are written in Alloy and DTRAM and describe the specifications of two target Web services (in the following, abbreviated as ‘ST Alloy’, ‘ST DTRAM’, ‘IM Alloy’, ‘IM DTRAM’)” (“MODELS_2025_paper_8”, p. 8) #ffd400
|
||
*What was the goal of the task? this is not clear. For what?*
|
||
|
||
- “As a whole, each participant was asked to work on four tasks. Considering order effects of the tasks, we divided the participants into four groups in Table I, and changed the order of the tasks for each group.” (“MODELS_2025_paper_8”, p. 8) #5fb236
|
||
|
||
- “1) Read the outline page. 2) Read the page explaining Alloy. 3) Read the page explaining the specification of IM. 4) Work on IM Alloy (1st task). 5) Read the page explaining DTRAM. 6) Work on IM DTRAM (2nd task). 7) Read the page explaining the specification of ST. 8) Work on ST Alloy (3rd task). 9) Work on ST DTRAM (4th task).” (“MODELS_2025_paper_8”, p. 8) #5fb236
|
||
|
||
- “VII. CASE STUDIES” (“MODELS_2025_paper_8”, p. 9) #ffd400
|
||
*It's not clear the contribution of the case studies with respect to the whole experiments and to the given research questions. It is not clear to what extent the case studies help to answer the research questions.*
|
||
|
||
- “Both applications are online Android applications developed in our laboratory for project-based learning, with their backends implemented as RESTful services using JAX-RS.” (“MODELS_2025_paper_8”, p. 9) #5fb236
|
||
|
||
- “We think that the results are due to the difference in the underlying computation models (semiprocedural style of DTRAM and declarative style of Alloy). For specification descriptions of RESTful microservices, semiprocedural language is considered suitable.” (“MODELS_2025_paper_8”, p. 10) #5fb236
|
||
|
||
- “In this paper, we presented a formal specification and architecture model for RESTful microservices, DTRAM, which extends the Data Transfer Architecture Model to represent the creation and deletion of resources and their hierarchical structure.” (“MODELS_2025_paper_8”, p. 10) #5fb236
|
||
|
||
- “we enhanced the visual modeling tool to support DTRAM models and enable direct simulation of the described model.” (“MODELS_2025_paper_8”, p. 10) #ffd400
|
||
*With respect to this clarification. What are the enhancements that have been operated on the visual modeling tool? what are the challenges that the previous version was affected with?*
|
||
|
||
- “The results show that DTRAM is significantly better suited than Alloy for describing their specifications” (“MODELS_2025_paper_8”, p. 10) #ffd400
|
||
*This seems quite obvious. You are comparing a general-purpose approach (Alloy) with a domain specific one (DTRAM as presented in the paper). Thus is not surprising that DTRAM performs better than Alloy with respect to the usability aspect.*
|
||
|
||
- “confirmed that nearly the entire APIs were regenerated correctly from newly described DTRAM models” (“MODELS_2025_paper_8”, p. 10) #5fb236
|
||
|
||
Consider that those that are tagged with #5fb236 are just highlights, those that are tagged with #e56eee and #a28ae5 are important sentences. Please pay attention instead to the notes that are tagged with #ffd400. Those that are tagged with #ff6666 are typos or errors. Could you please draft a review by organizing it as follows: SUMMARY: Just a few sentences to summarize the work. COMMENTS: Organize the notes, especially those that contain issues or typos. Moreover, list the strengths and weaknesses of the work (no more than 3 items each). At the end, list 3 questions for the authors that might be involved in a rebuttal phase. |