Files
logseq/pages/PAPERS___LEV4REC.md
T
2025-06-02 17:15:13 +02:00

4.0 KiB
Raw Blame History

full-title:: LEV4REC: A feature-based approach to engineering RSSEs type:: JournalPaper external-links:: MDEGroup/SoSyM-LEV4REC (github.com) LEV4REC_Sosym_Reviews - Google Docs todoist:: https://todoist.com/showTask?id=6718800976 year:: 2023 tentative-submission-deadline:: 04-09-2023 status:: SUBMITTED venue:: COLA date-submitted:: 22-11-2023 priority:: progress:: {{renderer :todomaster}}

- Confini del lavoro
- Rinominare il tool
- #+BEGIN_QUOTE
  I recommend to add a scenario as a guiding line through the whole article which would explain step [[by]] step how to start]] from exploiting software requirements of the SR to develop and implement them using the low-code approach.
  #+END_QUOTE
	- Explanatory / running rec sys developed with and without LEV4REC
		- We need to clarify the challenges one has to deal with while developing a [[RecSys]]
			- Probably we are not able to address all of them (report part of the ESEM paper)
			- The explanatory example should limit the presentation of the challenges that are addressed [[by]] the tool
- Put the [[Paper]] in the scope of [[SOSYM]]
	- We could change the focus (even in the title) on the usage of MDE for supporting the development of [[RecSys]]
		- Essentially we are showin gan application of MDE for developing tools in the domain of [[RecSys]]
- WE claim **domain** independence!!!!
	- How to convince the reader about such a claim?
	- The best is to remove / reduce such a clain and list the domains that we can cover. In other words what are the characteristcs of the [[RecSys]] that we support?
		- We cannot mention specific domains, but we should chracterize the [[RecSys]] (from a component or structure point of view) that we support. For instance, in terms of algorithms we currently support only .....
		- On the other end it's important to stress the constraint management aspects (this is the main novelty)
			- We could even promote this aspect as main goal of the [[Paper]] / approach
	- The domain concept has to be removed from the [[Paper]]. WE need to show what are the main ingredients of [[RecSys]] and how we enable / manage their composition and configuration
- How to answer [[Comments]] like:
	- ** At this point, I do not know precisely how to transpose the "last lines I already typed before my cursor". Is this enough to use your approach? Or do I need more refined specification? This is where a guiding scenario should be used.**
	- In my opinion here we should show how the developer is supposed to refine / finalize the [[code]] generated [[by]] the approach. How to accept user customizations / development ?
- ** I think that RQ1 is enough for the validation if you are more systematic about "existing recommender systems". **
	- systematic means that the considered [[recsys]] are different with respect to some peculiar characteristics that should be introduced when writing the content replacing the domain aspect above
- #+BEGIN_QUOTE
  Il target del lavoro e' uno sviluppatore di sistemi di raccomandazione
  #+END_QUOTE
	- Quali sono le challenges che attualmente deve affrontare?
		- Difficolta nello gestire le varie dipendenze tra algoritmi, dati, encoding, pre-processi (noi la risolviamo con il feature e vincoli)
- ### Related works
	- ![Softw Pract Exp - 2022 - SavaryLeblanc - Software assistants in software engineering  A systematic mapping study.pdf](../assets/Softw_Pract_Exp_-_2022_-_SavaryLeblanc_-_Software_assistants_in_software_engineering_A_systematic_mapping_study_1684241801009_0.pdf)
- ### Tasks
	- DONE Lavorare su abstract [[01-09-2023]]
	- DONE RIvedere introduction [[01-09-2023]]
	- DONE Rivedere sesione 2 [[01-09-2023]]
	- DONE Rivedere sezione 3 [[01-09-2023]]
	- DONE Rivedere sezione 4 [[02-09-2023]]
	- DONE Rivedere sezione 5 [[02-09-2023]]
	- DONE Rivedere sezione 6 [[02-09-2023]]
	- DONE Rivedere sezione 7 [[04-09-2023]]
	- DONE Rivedere sezione 8 [[04-09-2023]]
-