Files
logseq/pages/SOSYM-23-00004493_Proof_hi.md
2025-06-05 22:07:12 +02:00

8.9 KiB

type:: REVIEWS tags:: year:: 2023 venue:: SOSYM full-title:: Improving Repair of Semantic ATL Errors using a Social Diversity Metric date-start:: 21-08-2023 - 18:39 date-submitted:: 31-08-2023 external-links:: ScholarOne Manuscripts (manuscriptcentral.com) status:: DONE deadline-submission:: 09-08-2023 file:: SOSYM-23-00004493_Proof_hi.pdf

- [[Highlights]]
	- #+BEGIN_IMPORTANT
	  ((64ee16d2-ad2f-48ea-810a-9dba3b9e4a4d))
	  ((64ee1ae5-2d5a-4958-ba91-de31fb6b2039))
	  ((64eef00f-1c9d-4a1d-ad79-e9969b7388bc))
	  ((64eef01c-b908-4377-944c-45ddfad615fe))
	  ((64eef044-1fcd-4094-a953-f832ba08adb1))
	  ((64eef09c-7959-4d17-9aaf-d372f7b1d44c))
	  ((64ef04a0-20d3-4582-9d86-9113d8869909))
	  ((64ef0bdc-9a0f-48f4-ab00-c2e327afa47d))
	  ((64ef43d3-9194-4dc2-9dca-0ff2d6704af0))
	  ((64f0535a-500e-4f8d-be63-87bdf5c3e879))
	  THIS SEEMS TO BE THE MAIN DIFFERENCE WITH THE CONFERENCE VERSION OF THE PAPER.
	  #+END_IMPORTANT
	- ((64ee1700-8041-446e-b39d-bfbf97fc6e92))
		- It does not parse.
	- ((64ef0c9e-53be-4e0e-a82a-80b43b9ac49f))
		- I would list the novelties of this work with respect to the conference version. Explicitly list what are the contributions with respect to that paper!
	- ((64eeefb2-14e6-4759-8d50-a309b2b7e88d))
		- Is it only a problem of number of errors? This needs to be explained!
	- ((64eef068-367d-4ffe-b559-70822646ff3b))
		- Diversity is ok, but it should be also put in relation with optimality/correcteness of the solution, isn't it?
	- ((64ef075b-0807-4ba9-9d00-eca724425600))
		- For completeness I would say that transformations can be of different cardinalities concerning the source and target metamodels and not only transform one source model to generate one target model. Then you can say that in this paper you focus on one-to-one transformations.
	- ((64ef0c46-e3d4-4971-b3db-3a7f0c98d933))
	- ((64ef37c8-3018-4922-853d-7b0c16b6e2e9))
		- Such patches look very transformation specific. TO what extent such patches are reusable. What's their benefit instead of operating the changes directly to the transformation under analysis?
		- In other words it is not clear if the difficulty of chaining transformation is higher than formulating repair patches.
			- ((64ef385d-2265-4d40-b96b-d14d95818a44))
			- That's exactly my point!
			- ((64ef3895-e5e5-4881-b7b8-877d13105706))
				- Formulating the changes seems to be very transformation specific and writing them cannot be done independently from understanding the error sources.
			- ((64ef3970-80ba-4e24-ad30-94c074a0dadb))
				- I have doubts especially related to the parameters of such operations. Thus, the solution space is defined by the type of operations and on the input parameters. However, without constraints, the values of the input parameters can be unbounded.
					- The comment is related to this point I guess:
						- ((64ef4349-1534-401d-9d62-05f939afb166))
	- ((64ef3ab5-7feb-41a3-9749-d0faeacccb66))
		- They have to be formalized by making explicit the management of their components (or constituting dimensions), i.e., kind of operations and parameters. At this stage, it is not clear what are the dimensions covered by the evaluation algorithm to create the patch as mentioned in
			- ((64ef3b30-19a3-4139-97a0-ef63ee319beb))
		- My previous comment is also related to this part of the paper
			- ((64ef4597-b4cf-4ab9-aa15-3babe527a6f9))
	- ((64ef4606-e94a-42c9-bbc0-892bd318d1c1))
		- Where do this value come from? This needs to be explained.
	- ((64ef466f-2a72-421b-b8ee-db588e313e49))
		- Local optimality vs global optimality
			- Apparently I'm following a path that eventually will produce the best solution, that might have been reached another path that was discarded early in the process. Can this happen?
	- ((64ef64de-a45a-4a79-b0ef-eb6a379c1e01))
		- It is necessary to define the notion of equivalence, which is used
	- ((64ef6524-42b7-4a96-a0ae-de2f2fe122bc))
		- A clear definition of the used concepts is needed here.
	- ((64f0458e-5577-4dda-abc4-87357be6e9dc))
		- By considering such a complexity, to what extent the approach is more convenient than fixing transformations by hand?
	- ((64f0489e-d6ed-4822-989f-b34b62f694fe))
		- Not clear
	- ((64f04db0-248f-4879-a3dd-46bb07de8af1))
		- What does it mean? What kind of value are you talking about here?
	- ((64f058c4-5a31-457e-a839-59c169abc72f))
		- This figure comes too late in the paper. I would move earlier in the paper and I would make explicit what are the components that are new or changed with respect to the conference version of the paper.
	- ((64f05ba6-5bc4-487d-a894-de0c25999c3f))
		- Argument types?
	- ((64f05bce-71f8-4344-8106-a75fe6e81f97))
		- Operation call is missing in the text.
	- ((64f05cf4-cc04-4566-8a82-c5f3b5876eba))
		- It does not parse.
	- ((64f05e48-f850-442f-992a-6f200e1614d9))
		- You mean without social diversity, right?
	- ((64f05ef8-d659-4183-8af8-620a00d37379))
		- Why manually?
	- ((64f064e9-9ee1-4abb-993a-99039d4a88f8))
		- This is the first time it occurs. I would clearly say since the beginning that the approach is semi automated.
- [[Comments]]
	- The paper presents an automated approach to fix semantic errors of ATL model transformations. The technique exploits evolutionary algorithms and test cases consisting of input and out models to automatically identify sequences of changes to be operated to the original transformation to be fixed. This is an extension of a conference version of the work. The main novelty introduced in this paper is the introduction of social diversity to drive the search process. According to the performed experiments, injecting social diversity into the process improves the effectiveness and efficiency of the approach.
	- The paper is well-written and structured, and it addresses an interesting and relevant problem related to model-transformation development. I have the following suggestions to improve the article, with the aim of clarifying aspects that are not precisely described in the current version of the submission:
	- Patches like those shown in the example depicted in Fig. 4 look very transformation-specific, especially concerning the parameters of the considered operations. In particular, the solution space is defined by the type of operations and the input parameters. Indeed, the number of operations is limited, whereas the values of the input parameters can be potentially unbounded.
		- Following my previous comment, edit operations have to be adequately formalised in Section 2.5 as done for the other elements of the considered problem. Edit operations given in Equation (3) have to be further detailed to cover all the defining aspects, including the input parameters.
		- Fig. 5 shows examples of path mutations, and it is unclear where identifiers like "collect" and "union" come from. Indeed, these are ATL operators; thus, it is a specific dimension the algorithm has to explore to generate mutations. Can you elaborate on how this works?
		- In section 3.2.1, the authors write, "if the obtained model is equivalent to the expected output...". At this point of the paper, it is necessary to define the notion of equivalence. Later in the paper, it becomes clear that EMFCompare is exploited, and the equivalence notion is related to the number of differences calculated by EMFCompare.
		- As discussed in Sect. 4.1 defying fitness functions is a critical task that needs to be done carefully. Considering such complexity, the paper should present a qualitative discussion to elaborate on the extent of the approach being more convenient than fixing transformations by hand.
		- Related to the previous points, what can the authors say about the generalizability/reusability of the edit operations and fitness functions? Can they be defined in a knowledge base and considered to fix any ATL transformations potentially?
		- Figure 10 comes too late in the paper. I would move it earlier by making graphically explicit what components are new or changed with respect to the conference version of the paper.
		- The description of Table 3 (second paragraph of pag. 15 of the paper) should be fixed as follows:
			- ... their arguments .... -> ... their argument types?
			- "operation call" should be mentioned in the text.
		- In the last paragraph of section 5.2, the authors mention that comparing the patched transformations with their correct versions is performed manually. If I'm not wrong, such a comparison is done by EMFCompare, isn't it?
		- At the beginning of section 6.1, the authors write that the approach aims to improve the *semi-automatic* repair of model transformations. Thus, the system is not fully automated as readers may understand by looking at Fig. 10. I suggest refining the figure and the corresponding text by clearly showing the automated phases and those that instead require human intervention.
-