68 lines
5.6 KiB
Markdown
68 lines
5.6 KiB
Markdown
type:: [[REVIEWS]]
|
||
todoist:: [Todoist](https://todoist.com/showTask?id=6416790095)
|
||
year:: 2023
|
||
venue:: [[JSS]]
|
||
status:: [[DONE]]
|
||
full-title:: GRuM – A Flexible Model-Driven Runtime Monitoring Framework and its Application to Automated Aerial and Ground Vehicles
|
||
links:: [Local library](zotero://select/library/items/4RW75889), [Web library](https://www.zotero.org/users/1039502/items/4RW75889)
|
||
|
||
-
|
||
- [[Attachments]]
|
||
- [JSSOFTWARE-D-22-00977_reviewer.pdf](zotero://select/library/items/CBP56TTH) {{zotero-imported-file CBP56TTH, "JSSOFTWARE-D-22-00977_reviewer.pdf"}}
|
||
- [[Highlights]]
|
||
- ((63b59f6e-a0c7-44cb-a21e-5ad1da709790))
|
||
- ((63b5e998-f6f6-4e35-88ae-01e73e73dd23))
|
||
- ((63b6dddf-5ecb-45d7-b5b8-393724736bf6))
|
||
- What kind of changes?
|
||
- ((63b6de38-c645-47c6-bc9a-90e54cc15ecb))
|
||
#+BEGIN_IMPORTANT
|
||
Important to check the differences with previous work
|
||
#+END_IMPORTANT
|
||
- Two main contributions
|
||
- ((63b6deb4-c1eb-4a3e-bc87-57c1348dcb07))
|
||
- ((63b6debe-f03c-4254-a86b-06f38ac4d5eb))
|
||
- ((63b84bca-3d81-462d-8bbe-66989d750b4c))
|
||
- ((63b84c07-ed8b-4501-bd4e-384ff614c0da))
|
||
- ((63b84d29-556c-4ed6-b174-8d1c904de7b5))
|
||
- #+BEGIN_IMPORTANT
|
||
((63b84d5f-e656-4b1d-ac2b-e1594fb26ac1))
|
||
#+END_IMPORTANT
|
||
- ((63b852eb-9e43-4bf6-bfa9-68d88785b9ff))
|
||
- ((63b85327-1a50-4bce-beae-3d3166e02e8e))
|
||
- ((63bc2121-6652-4fe7-b050-b8cdad6ab34d))
|
||
- What language has been used to specify the weaving model?
|
||
- That's the answer: ((63bc2cc9-913c-4875-ba32-16a44e4ca432))
|
||
- ((63bc23da-0963-4981-ae5c-53430a12cd50))
|
||
- This is not obvious to me and it should be detailed.
|
||
- ((63bc29c7-2d78-45e7-b64b-6960153edc1b))
|
||
- This is underspecified. Technical details about the used middleware are missing/required
|
||
- ((63bc2c1a-34b8-4d0b-be34-e1cbb7837ab6))
|
||
- Easily???
|
||
- ((63bc36d5-0483-4755-a056-2791ccff2036))
|
||
- To make the sections more readable I would add some details of the case study while presenting the different steps. Currently, they are described but the reader does not have details to fully understand the performed experiments.
|
||
- ((63bc8686-dc99-41a6-82de-3a2ce739f55c))
|
||
- The same for the second case study.
|
||
- ((63bc8a59-5a7e-42df-9bfb-8d4907972f2a))
|
||
- It means that the monitoring environment is configured with contraints to be checked at run-time? what happens if some constraints are violated?
|
||
- ((63bd3dac-e5ae-49f4-85e9-8f01bca6086b))
|
||
- Propertis or property values?
|
||
- ((63bd3e0b-459b-451d-b8b6-9cf6a59f5ccb))
|
||
- Some details about the knowledge of the involved people are missing
|
||
- ((63bd3e3b-ce26-459a-be0d-55e85b21618c))
|
||
- I would explicitely describe the differences of the two systems especially to support their selection. Why them? Clearly describing the peculiar differences of the two systems can support the selection done.
|
||
- ANother aspect that I would clarify is what are the architectural constraints that need to be satisfied in order to make the proposed approach applicable. For instance, it requires the possibility of adding an intermediate components managing the probes and intercepting the values of the parameter of interest. I would make explicit when the approach can be employed for instance in the case of existing and already working systems.
|
||
- ((63bd3f97-8395-4b79-b765-50f7e9ffe7fb))
|
||
- This needs to be made more explicit.
|
||
- [[Comments]]
|
||
- **Summary**: The paper presents a model-driven approach to support the development of runtime monitoring systems. The method mainly consists of domain-specific languages to specify the properties of interest and to link them to the system under monitoring. From the given specification, a monitoring platform is automatically generated. The proposed approach has been validated by considering two different automated aerial and ground vehicles.
|
||
- **Comments**: The paper is about an interesting and relevant problem. Overall, I liked the paper, which is well-written and structured. However, the following issues need to be fixed before its acceptance:
|
||
- The paper should clarify the technical requirements the system of interest should satisfy to endow it with the proposed runtime monitoring infrastructure. For instance, the authors should explain early in the paper that the system of interest should be open in the sense that it should expose the parameters of interest that have to be intercepted by the proposed infrastructure.
|
||
- Following the previous comment, the authors should give details about the monitoring middleware. Currently, the reader can get an intuition about it, but details are required. For instance, I can understand that publish/subscribe mechanisms are exploited by probes, but it is not clear how the monitoring infrastructure automatically recognizes them.
|
||
- Concerning the evaluation, I would clarify the architectural differences between the two considered systems to justify why the authors decided to consider them. Adding such clarifications and characterization of the considered case studies would also solve some of the threats to the external validity of the evaluation.
|
||
- It is necessary to add details about the expertise and knowledge of the people involved in the evaluation.
|
||
- To make the evaluation sections more readable, I would add some details of the case studies while presenting the different steps. They are currently described, but the reader needs details to fully understand the performed experiments.
|
||
- **Minors**:
|
||
- Table 1: NPR, I guess it should be the number of property values instead of the number of properties, isn't it? In particular, the properties are those that are modeled, and the simulation runs consider the number of values produced by the system for the properties of interest.
|
||
-
|
||
-
|
||
- |