33 lines
3.8 KiB
Markdown
33 lines
3.8 KiB
Markdown
type:: [[REVIEWS]]
|
||
tags::
|
||
year:: 2025
|
||
venue:: [[MODELS]]
|
||
full-title:: DTRAM: A Formal Specification and Architecture Model for RESTful Microservices
|
||
date-start:: [[23-05-2025]] - 17:24
|
||
date-submitted::
|
||
external-links::
|
||
status:: [[DONE]]
|
||
deadline-submission::
|
||
file:: [[@MODELS_2025_paper_8]]
|
||
parent::
|
||
todoist:: https://app.todoist.com/app/task/dtram-a-formal-specification-and-architecture-model-for-res-tful-microservices-6Xh6hgrjQMrRFmg8
|
||
|
||
- ### [[Highlights]]
|
||
- ### [[Comments]]
|
||
- Summary of the paper: The paper proposes a model named Data Transfer Architecture Model (DTRAM) to formally specify RESTful microservices. In particular, the approach provides the modeling constructs to model and simulate resource hierarchies and the creation and deletion of resources. The authors compare the approach with Alloy by means of user study involving 24 developers.
|
||
- Strengths:
|
||
- + Evaluation of the approach involving experienced professionals
|
||
- Weaknesses:
|
||
- Abstract and introductory sections are vague and poorly structured.
|
||
- Evaluation lacks clarity in terms of goal and metrics of the comparison.
|
||
- Many concepts and terms are introduced without proper context or background.
|
||
- Detailed comments:
|
||
- The paper has several presentation issues that compromise the whole quality of the paper, which is not effective neither in presenting the problems to address nor the related solutions. The main concerns are related to the following issues organized per sections of the paper:
|
||
- Abstract and Introduction section: The abstract needs substantial revision. It lacks clarity and fails to communicate the scope and contributions of the paper. Concerning the Introduction section, it contains terms like PUSH and PULL without providing prior context. The extended model (DTRAM) is introduced abruptly and without a clear description of its goal or intended benefits. Moreover, the claim about the lack of formal specification languages for microservices is too strong and underexplored. The authors should clarify the type of specification they refer to and frame this claim in a more clear way.
|
||
- Background and Motivating Example: The motivating example in Section II lacks focus. The problem the authors aim to address is not clearly articulated. The use of figures to show resource hierarchies could be improved by using listings instead. Moreover, the background on the original Data Transfer Architecture Model is not sufficiently contrasted with existing modeling approaches like ADLs.
|
||
- DTRAM and Tooling: The description of the tool and its capabilities is vague. It’s unclear what the generated prototype can do, what the purpose of the simulation is, who the simulation tool’s target user is, and in which development phase it is intended to be used. It is not clearly explained what the enhancements to the visual modeling tool are and what limitations of the prior version they address.
|
||
- Evaluation: The purpose of the tasks assigned to participants is not clearly stated. The authors should explicitly clarify what skills or insights the tasks are designed to test. The comparative advantage of DTRAM over Alloy is not convincingly justified. Since Alloy is general-purpose and DTRAM is domain-specific, it is expected that DTRAM might be more usable in its domain. The paper should better explain the evaluation criteria and metrics. The tole of the case studies in relation to the research questions is unclear. It should be explained how they substantiate or extend the findings from the evaluation.
|
||
- Questions for the authors
|
||
- Q1: What are the key differences between DTRAM and existing architectural description languages? Why is a new formalism needed?
|
||
- Q2: Could you clarify the exact purpose of the simulation feature and the development activities it supports?
|
||
- |