ddiruscio/logseq
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Auto saved by Logseq

Browse Source
This commit is contained in:
Davide Di Ruscio
2025-06-02 17:15:13 +02:00
commit d9ea3d552d
6279 changed files with 711145 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
pages/(17) (PDF) Machine Learning Pipelines_ Provenance, Reproducibility and FAIR Data Principles--@17PDFMachine.md
View File
pages/--author.md
+1
View File
@@ -0,0 +1 @@
alias:: author
pages/10-12-SFI-Ireland.md
+67
View File
@@ -0,0 +1,67 @@
tags:: #lowcode
external-links:: http://s.diruscio.org/DjlmD
type:: #SERVICES/REVIEWS
-
- # Documents
- ![_LoS-R@ISE Official Collaborators.pdf](../assets/_LoS-R@ISE_Official_Collaborators_1665238102344_0.pdf)
- ![2022-20 A Rensink Letter of Support R@ISE project proposal.pdf](../assets/2022-20_A_Rensink_Letter_of_Support_R@ISE_project_proposal_1665238107579_0.pdf)
- ![Proposal_Document.pdf](../assets/Proposal_Document_1665238115315_0.pdf) **MAIN DOCUMENT**
- # Notes
- #+BEGIN_IMPORTANT
**MAIN GOAL OF THE PROJECT**
#+END_IMPORTANT
- ((634185b1-a131-4cc3-8a29-b46cb52641b0))
((634189c5-2f2d-4c6f-95f6-06fb8aeb5ef8))
((63418a07-ddc0-4a52-9624-ccf05a77971b))
- ((634dcae0-84c6-47b4-ba97-ee7b88f8719d))
- ((63418d6c-06cb-40b1-b6f8-4b62536c850e))
((6341982a-1f92-402d-ad33-53dba4df30fc))
((6341987a-5a08-4f47-96f9-dfad0d44110d))
-
- #+BEGIN_CAUTION
**ASPECTS TO BE CLARIFIED**
#+END_CAUTION
- ((63418497-1e8e-4ac6-bbe5-c7e8972a0081))
- What's immersive???
- ((6341994e-6c9b-49f1-adf3-d42ef9556f1d))
- I don't fully agree. What about the cloud-nature of low-code platforms?
- **How to prove that! Interesting statements, even though it is not clear yet how to support / achieve them**
- ((634185da-62a3-45ae-9239-213edb9813ad))
- ((63418666-5167-4628-b208-57d5035b7dad))
- ((63418712-8525-4dc5-92dc-3f30c54d329a))
- A lot of bla-bla-bla
- ((634f2bd1-17ec-4acb-9a31-b40649d22fc5))
- The project has the risk of being too broad. It is unclear if the final goal is to create a set of tools for developing bespoke low-code environments, or a one-fit-all low-code environment, which can be used to create, potentially, any kind of system.
- ((63419b87-ed22-4642-b09c-a77a9f8f460c))
- Is it always the case that code needs to be generated? It is important to avoid doing the same mistake we had decades ago with UML promising that users can get automatically generated functionig code out of source models
- ((63419ca8-6a7b-4dfc-a629-eef0fa27eb11))
- How?
- Promise, how to meet it?
- ((6341a20b-3f29-4ccd-b8a7-96bf80fd84df))
- ((6341a345-ef0f-483c-be18-a6d0fe2cd686))
- What't the difference of what you are proposing with such platforms?
- ((6341a3d5-afd3-4d81-ba7b-62f0acb1ca33))
- Very generic output
- ((6341a3fb-4626-435c-95bc-0ddf17cf2b60))
- What does it mean? What lowcode approaches?
- ((6341a464-3349-484d-ad6b-c21a4f639719))
- I think some related work (look at the paper from Benoit) are missing here
- ((6341a5e4-19e4-4f38-b4c8-7b02a3ce0cdb))
- Very generic risks in my opinion.
-
- #+BEGIN_PINNED
**INTERESTING FIGURES ON #lowcode**
#+END_PINNED
-
- ((6341933c-8eab-4296-b1b6-18dd5b2533af)) #card
id:: 65c8d44f-23de-4809-90c4-1a74f10857a6
:LOGBOOK:
CLOCK: [2022-10-08 Sat 17:17:09]
:END:
((63419390-203c-4605-8262-f8171f006314)) #card
((6341946d-fdb6-46d1-bd2c-96c989a22eed))
((63419d35-496b-4264-8888-7ad88feee32a)) #card
- ## Footnotes
- ((63418cbc-0bfc-43f6-8cc7-0879da4c54d9))
- {{embed ((634184dc-a3c1-4816-8b77-af9e091bcc64))}}
pages/101 eBook gratis-1638139768991.md
+30
View File
@@ -0,0 +1,30 @@
---
kindle-sync:
bookId: '64308'
title: 101 eBook gratis (oltre questo) (Italian Edition)
author: Gianluigi Bonanomi
asin: B00IMJYPNE
lastAnnotatedDate: '2015-05-26'
bookImageUrl: 'https://m.media-amazon.com/images/I/71noiW+0W8L._SY160.jpg'
highlightsCount: 4
---
# 101 eBook gratis
## Metadata
* Author: [Gianluigi Bonanomi](https://www.amazon.comundefined)
* ASIN: B00IMJYPNE
* Reference: https://www.amazon.com/dp/B00IMJYPNE
* [Kindle link](kindle://book?action=open&asin=B00IMJYPNE)
## Highlights
“Every company is a media company” dice Tom Foremski, sintetizzando con la formuletta EC=MC — location: [79](kindle://book?action=open&asin=B00IMJYPNE&location=79) ^ref-38212
---
Per fortuna, poi, i casi di progetti di “open culture”, come i titoli distribuiti con licenza copyleft (l’antitesi del copyright) o Creative commons (che non vuol dire necessariamente gratis: trovate un intero libro al riguardo nei saggi) sono sempre di più. Deo gratis (non è un refuso). — location: [90](kindle://book?action=open&asin=B00IMJYPNE&location=90) ^ref-35329
---
Meglio, di gran lunga, l’ePub: uno standard aperto. L’ePub può essere letto ovunque: su PC (grazie per esempio all’ottimo programma Calibre, che tra l’altro permette di effettuare conversioni da un formato all’altro), oppure nativamente su iOS (con l’app preinstallata iBooks) o su dispositivi Android (per esempio con Alkido) e Windows Phone (con ePub Reader). — location: [122](kindle://book?action=open&asin=B00IMJYPNE&location=122) ^ref-10079
---
Il problema è che l’ePub non è compatibile con l’eReader più diffuso: il Kindle di Amazon (ormai ve lo tirano dietro, a poche decine di euro). Questo usa un formato proprietario, AZW3, che però è una variante del Mobi (il Kindle legge tranquillamente i Mobi). Per fortuna gli eBook di Amazon possono essere letti ovunque, grazie alle applicazioni Kindle, gratis per tutte le piattaforme. — location: [127](kindle://book?action=open&asin=B00IMJYPNE&location=127) ^ref-2849
---
pages/2021 02%3A30PM.md
+3
View File
@@ -0,0 +1,3 @@
title:: 2021 02:30PM
-
pages/23-08-2022-Meetings-crossminer.md
+3
View File
@@ -0,0 +1,3 @@
type:: [[meeting]] external-link:: [176 - Meeting 23/08/2022](onenote:%5BOneDrive%5D(https://d.docs.live.net/a33324427a144a54/Documenti/CROSSMINER/MEETINGS/Internal%20Meetings.one#176%20-%20Meeting%2023/08/2022&section-id=%7B98E19AF8-5A76-4F4A-B1FE-AE643744BAE7%7D&page-id=%7B2D918718-900A-48F2-AF20-47D407101B9C%7D&end))  ([visualizzazione Web](https://onedrive.live.com/view.aspx?resid=A33324427A144A54%211622&id=documents&wd=target%28MEETINGS%2FInternal%20Meetings.one%7C98E19AF8-5A76-4F4A-B1FE-AE643744BAE7%2F176%20-%20Meeting%2023%5C%2F08%5C%2F2022%7C2D918718-900A-48F2-AF20-47D407101B9C%2F%29)) tags:: people:: #people/crossminer areas:: date:: [[23-08-2022]]
*
pages/2817_Anisetti(et.l)_89187712_Security Certification of Cloud-Edge Distributed Systems.md
+20
View File
@@ -0,0 +1,20 @@
type:: [[REVIEWS]]
tags::
year:: 2023
venue:: [[Springer Books]]
full-title:: Security Certification of Modern Distributed Systems
date-start:: [[20-07-2023]] - 17:26
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission:: [[21-07-2023]]
file:: ![Book_Springer_forReview-2023.pdf](../assets/Book_Springer_forReview-2023_1689866773410_0.pdf)
- [[Highlights]]
- ((64bb7dc5-a7aa-45a2-bd06-14d9f6507a0d))
- ((64bb7dec-8b31-4734-878b-d9e5d4010423))
- ((64bb7fb0-9d7b-45a5-bf83-2cd1fedb2074))
- [[Comments]]
- The book focuses on security certification of distributed systems, and its organization comprises four main parts. The first part provides a concise historical overview of software security certification. The second part gives an overview of relevant certification schemes, with a specific focus on evidence-based certifications. Moving on to the third part, the book delves into certification characteristics of modern composed systems, which encompass multiple micro/nano services. Finally, the fourth part concentrates on certification issues related to cloud-edge continuum infrastructures.
- Overall, the book exhibits a well-structured and organized approach, addressing various aspects concerning security certification of distributed systems. The flow of the presentation is suitable, although it may benefit from additional explanatory examples throughout the chapters. For example, chapters 4 and 5 could be enhanced with references to concrete technologies that developers need to master when supporting DevOps processes or managing the deployment of developed distributed systems on Cloud-Edge Continuum infrastructures. Including more illustrative examples would significantly improve the book's readability, especially for readers who are not experts in the field and seek an introduction to it, such as bachelor/master students or even PhD students.
- Apart from that suggestion, I believe the book is of high quality and well-crafted.
pages/29 Strategie da Genio-1638139755294.md
+29
View File
@@ -0,0 +1,29 @@
---
kindle-sync:
bookId: '59403'
title: >-
29 Strategie da Genio: Corso concentrato di mnemotecniche, lettura veloce e
studio efficace (Italian Edition)
author: Yamada Takumi
asin: B00BWNN4HK
lastAnnotatedDate: '2019-12-03'
bookImageUrl: 'https://m.media-amazon.com/images/I/91SGl0dxDvL._SY160.jpg'
highlightsCount: 2
---
# 29 Strategie da Genio
## Metadata
* Author: [Yamada Takumi](https://www.amazon.com/Yamada-Takumi/e/B00DU008AO/ref=dp_byline_cont_ebooks_1)
* ASIN: B00BWNN4HK
* ISBN: 1549710311
* Pages: 154 pages
* Publication: January 1, 2014
* Reference: https://www.amazon.com/dp/B00BWNN4HK
* [Kindle link](kindle://book?action=open&asin=B00BWNN4HK)
## Highlights
è di focalizzarsi contemporaneamente innanzitutto sui compiti più importanti e su quelli più brevi. — location: [239](kindle://book?action=open&asin=B00BWNN4HK&location=239) ^ref-5924
---
più tempo mettiamo a disposizione per un compito e più ne sprecheremo. — location: [246](kindle://book?action=open&asin=B00BWNN4HK&location=246) ^ref-21076
---
pages/518-Article Text-1147-1-18-20231023.md
+43
View File
@@ -0,0 +1,43 @@
type:: [[REVIEWS]]
tags::
year:: 2023
venue:: [[JOT]]
full-title:: An Overview of the Declarative Programming Languages for the IoT Domain
date-start:: [[26-11-2023]] - 19:18
date-submitted::
external-links::
status:: [[DONE]]
deadline-submission::
file:: ![518-Article Text-1147-1-18-20231023 (2).pdf](../assets/518-Article_Text-1147-1-18-20231023_(2)_1701022738869_0.pdf)
parent:: [[JOT-2019-20518]]
- The authors submitted many files:
- ![518-Cover letter-1148-1-18-20231023 (2).pdf](../assets/518-Cover_letter-1148-1-18-20231023_(2)_1701022765092_0.pdf)
- [518-Source Texts-1149-1-18-20231023 (1).txt](../assets/518-Source_Texts-1149-1-18-20231023_(1)_1701022769457_0.txt)
- ![518-Other-1150-1-18-20231023 (2).pdf](../assets/518-Other-1150-1-18-20231023_(2)_1701022774923_0.pdf)
- [[Highlights]]
- ((656391c6-bef8-4abc-ba0f-b2ca8b99cc49))
- Really?
- ((65639275-d053-4ca4-880e-62fa957e59c6))
- Programming language for doing what?
- ((656392b4-8333-41b1-890a-05962a0b0006))
- How can you discuss declarative languages without considering the software solutions or platforms they will be consumed?
- ((656392f2-267f-4a7e-b72a-7d3511183da8))
- See my previous comment.
- ((656395bb-d77c-4273-a0d5-f34815709932))
- The paper over-simplify the problem and it turns out to be too narrow by limiting the usefulness of the results
- ((6563a989-dd52-449f-8ead-b34b8f249cb2))
- How is this assessment done in the paper?
- ((6563a9ed-4480-48ee-8753-854648522409))
- How are we supposed to use this?
- ((6563aa39-64b9-4159-a0d8-578a39c99eeb))
- This is a very simplified view of IoT systems that can encompass different components ranging from data sources, gateways, edge devices, cloud components, user applications for instance to show dedicated dashboards etc.
- [[Comments]]
- I appreciate the effort the authors have put into revising the paper. Unfortunately, the revised version still falls short of the necessary details required for a journal publication. As noted by the authors themselves, "this initial exercise offers an initial glimpse into the languages' ease of use and foundational constructs. Further in-depth evaluation and testing would be necessary for a comprehensive assessment of their suitability for IoT applications."
- Despite the multiple iterations, I must express that the paper, in its current state, cannot be accepted as a contribution to the journal. It is deemed premature and lacks the in-depth and rigorous evaluations needed for the considered domain-specific languages. The evaluations are conducted without sufficient consideration for the software solutions or platforms that consume these languages.
- I acknowledge the attempt to analyze different languages using a common example, as suggested in the previous review. However, the chosen "Hello World" example provides a very simplified view of IoT systems. Real-world IoT systems encompass diverse components, including data sources, gateways, edge devices, cloud components, and user applications (such as dedicated dashboards). The conclusions drawn from the given examples remain at a surface level and lack the necessary depth for a comprehensive understanding of the problem.
- In light of these considerations, I recommend reconsidering the paper with a focus on conducting more thorough evaluations and providing detailed insights into the domain-specific languages, considering their applications in real-world scenarios. This would enhance the paper's suitability for a journal publication.
-
-
- [[REVIEWS/Notes]]
-
pages/@02-16-JSSOFTWARE-D-23-01182.md
+90
View File
@@ -0,0 +1,90 @@
institution:: SSRN
tags:: [[#zotero]]
date:: 2024
report-type:: preprint
extra:: DOI: 10.2139/ssrn.4686181
title:: @02-16-JSSOFTWARE-D-23-01182
item-type:: [[report]]
access-date:: 2024-02-26T21:05:30Z
original-title:: 02-16-JSSOFTWARE-D-23-01182
language:: en
url:: https://www.ssrn.com/abstract=4686181
short-title:: Bit
authors:: [[Xiao He]], [[Tao Zan]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/6LRHKSQJ), [Web library](https://www.zotero.org/users/1039502/items/6LRHKSQJ)
-
- [[Abstract]]
- Model-driven development is a model-centric software development paradigm that automates the development process by converting high-level models into low-level code and documents. To maintain synchronization between models and code/documents—which can evolve independently—this paper introduces BIT, a bidirectional language that can serve as a conventional template language for model-to-text transformations. However, a BIT program can function as both a printer, generating text by filling template holes with values from the input model, and a parser, putting parsed values back into the model. BIT comprises a surface language for better usability and a core language for formal definition. We define the semantics of the core language based on the theory of bidirectional transformation, and provide the translation from the surface to the core. We present the proof sketch of the well behavedness of BIT as a formal evidence of soundness. We also conduct two preliminary case studies to empirically demonstrate the expressiveness of BIT. Based on the proof and the case studies, BIT covers the major features of existing template languages, and offers sufficient expressiveness to define real-world model-to-text transformations that can be executed bidirectionally and incrementally.
- ### Attachments
- [He e Zan - 2024 - Bit A Template-Based Approach to Incremental and .pdf](zotero://select/library/items/Y5NSDNBL) {{zotero-imported-file Y5NSDNBL, "He e Zan - 2024 - Bit A Template-Based Approach to Incremental and .pdf"}}
- institution:: SSRN
tags:: [[#zotero]]
date:: 2024
report-type:: preprint
extra:: DOI: 10.2139/ssrn.4686181
title:: @02-16-JSSOFTWARE-D-23-01182
item-type:: [[report]]
access-date:: 2024-02-26T21:05:30Z
original-title:: 02-16-JSSOFTWARE-D-23-01182
language:: en
url:: https://www.ssrn.com/abstract=4686181
short-title:: Bit
authors:: [[Xiao He]], [[Tao Zan]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/6LRHKSQJ), [Web library](https://www.zotero.org/users/1039502/items/6LRHKSQJ)
- [[Abstract]]
- Model-driven development is a model-centric software development paradigm that automates the development process by converting high-level models into low-level code and documents. To maintain synchronization between models and code/documents—which can evolve independently—this paper introduces BIT, a bidirectional language that can serve as a conventional template language for model-to-text transformations. However, a BIT program can function as both a printer, generating text by filling template holes with values from the input model, and a parser, putting parsed values back into the model. BIT comprises a surface language for better usability and a core language for formal definition. We define the semantics of the core language based on the theory of bidirectional transformation, and provide the translation from the surface to the core. We present the proof sketch of the well behavedness of BIT as a formal evidence of soundness. We also conduct two preliminary case studies to empirically demonstrate the expressiveness of BIT. Based on the proof and the case studies, BIT covers the major features of existing template languages, and offers sufficient expressiveness to define real-world model-to-text transformations that can be executed bidirectionally and incrementally.
- ### Attachments
- [He e Zan - 2024 - Bit A Template-Based Approach to Incremental and .pdf](zotero://select/library/items/R695QDD8) {{zotero-imported-file R695QDD8, "He e Zan - 2024 - Bit A Template-Based Approach to Incremental and .pdf"}}
- Notes
- “To maintain synchronization between models and code/documents—which can evolve independently—this paper introduces BIT, a bidirectional language that can serve as a conventional template language for modelto-text transformations.” (He e Zan, 2024, p. 0) #f0ff00
*Does it solve the problem with target protected areas?*
- “However, a BIT program can function as both a printer, generating text by filling template holes with values from the input model, and a parser, putting parsed values back into the model.” (He e Zan, 2024, p. 1) #f0ff00
*Is TCS in the related work?*
- “very few solutions for synchronizing models and text.” (He e Zan, 2024, p. 2) #f0ff00
*what about boomerang? And TCS? I would have introduced a motivating example to show when and how existing works fall short.*
- “Bidirectional transformation (BX) [22, 23, 24, 25, 26, 27, 28] can serve as the foundation of data synchronization. A BX program is a single specification that can be consistently evaluated in” (He e Zan, 2024, p. 3) #f0ff00
*have you considered JTL, QVT relation, etc.?*
- “their approach is limited code generation from Ecore models and is not generally applicable.” (He e Zan, 2024, p. 3) #f0ff00
*do you plan to propose an approach that works on any ecosystem further than Ecore?*
- “two challenges” (He e Zan, 2024, p. 3) #f0ff00
*it is nessary to give evidence of such issues by showing an explanatory examples that cannot be managed by existing appoaches.*
- “As for control directives, Xtend templates support loops (e.g., lines 6–14), conditions (e.g., lines 7–10), and assignments (e.g., lines 5 and 8). Within an Xtend template, other templates may be invoked.” (He e Zan, 2024, p. 5) #00b036
- “Figure 3: Demonstration of BIT template (colored background shows the changed text layout)” (He e Zan, 2024, p. 6) #f0ff00
*what about the attribute no? I think it should be in the parsed output, isn't it?*
- “with a lexical rule that guides our approach in the parsing mode. For example, «no|INT» in line 10 indicates that this hole will be filled with a string that is produced by the expression no and conforms to lexical rule INT, where the rule is defined by regular expression -?[0-9]+” (He e Zan, 2024, p. 6) #00b036
- “infer a lexical rule.” (He e Zan, 2024, p. 6) #f0ff00
*how? Is there any default rule that is applied?*
- “of the third paragraph will be "Appreciation", rather than "appreciation", because the first character in the old head is capitalized as "S"” (He e Zan, 2024, p. 7) #f0ff00
*that's not clear. What about the "Some text" that is ignored and "Thanks" is instead in the output.
Moreover the management of capital letters is not clear.*
- “The BIT approach” (He e Zan, 2024, p. 7) #f0ff00
*very much similar to QVT relation and QVT Core. It is necessary to discuss and compare BIT with respect to QVT technologies.*
- “Figure 5: Essential grammar of the surface language” (He e Zan, 2024, p. 8) #f0ff00
*the full grammar is not needed here. You can move it as an appendix and instead you can discuss in this section the peculiar aspects of the language by means of representative and illustrative cases.*
- “LexRule is a regular expression or a rule name bound to a regular expression, e.g., ID refers to [_a-zA-Z][_a-zA-Z0-9]*” (He e Zan, 2024, p. 9) #f0ff00
*it is necessary to make explicit what's the relation of what you specify with rules and the corresponding metaclasses, which are supposed to type the instances that can be created by parsing elements with respect to such rules.*
- “Case studies” (He e Zan, 2024, p. 26) #f0ff00
*This section needs to be improved by presenting a proper evaluation section, which starts by describing the research questions that the authors want to answer by mens of the performed evaluation. The way related works have been identified is also important. For instance, I don't see among them existing works like QVT, JTL, TCS.*
- “General information of the benchmark examples” (He e Zan, 2024, p. 29) #f0ff00
*Instead of presenting the table in terms of examples, I suggest to reorganise the table and thus, the corresponding text, by making explicit the peculiar cases that existing approach have issues in supporting them. Talking about examples is not a proper way to sustain a strong and organized discussion. Thus the examples column needs to be properly refined and decomposed with respect to their peculiar characteristcs.
Moreover, I would define a conceptual framework to compare existing approach by identifying peculiar features and discussing their support by the analysed approaches. Such an analysis should be presented earlier in the paper, when motivating the needs for a novel BX template language.
I don't see in the table Boomerang neither. If it is because it is not Ecore based, then "Platform" is one of the different dimensions that should be considered for the comparison.*
- “major features of” (He e Zan, 2024, p. 30) #f0ff00
*what are they? see my previous comments about the conceptual framework for comparison.*
- “Left Recursions. Parsers derived from BIT templates cannot handle left recursions. Figure 14 shows a concrete example template containing left recursion. Currently, the tool support of BIT cannot check left recursion statically. It will be our future work to investigate how to detect left recursions in templates by adopting existing techniques in the field of compilers. #[[ #foreach ($woogie in $boogie) nothing will happen to $woogie” (He e Zan, 2024, p. 31) #f0ff00
*left recursion is another dimension.*
- “Efficiency” (He e Zan, 2024, p. 31) #f0ff00
*this is another possible dimension but needs to be elaborated more in order to present the problems related to efficiency, and talk existing works also with respect to such a dimension.*
- “Specifically” (He e Zan, 2024, p. 32) #f0ff00
*what about Epsilon ECL?*
- “Our previous work [20] on bidirectional model transformation proposed a putback-based language which enabled us to define a backward transformation from which a well-behaved BX can be derived.” (He e Zan, 2024, p. 32) #f0ff00
*have you compared with your previous work?*
- “a template language for code matching and rewriting. In matching process, Comby interprets a code template and” (He e Zan, 2024, p. 33) #f0ff00
- “verbose text and template extension.” (He e Zan, 2024, p. 34) #f0ff00
*see the comparison comment above.*
pages/@02-23-TOSEM-2024-0012.pdf.md
+19
View File
@@ -0,0 +1,19 @@
tags:: [[⛔ No INSPIRE recid found]], [[#zotero]]
title:: @02-23-TOSEM-2024-0012.pdf
item-type:: [[document]]
original-title:: 02-23-TOSEM-2024-0012.pdf
links:: [Local library](zotero://select/library/items/BCYRLKCX), [Web library](https://www.zotero.org/users/1039502/items/BCYRLKCX)
-
- ### Attachments
- [02-23-TOSEM-2024-0012.pdf](zotero://select/library/items/I879APBF) {{zotero-imported-file I879APBF, "02-23-TOSEM-2024-0012.pdf"}}
- ### Notes
- * *
- # Annotazioni
(6/4/2024, 01:00:37)
- “In this paper, we propose DDASR, a framework for recommending API sequences containing both popular and tail APIs.” (“02-23-TOSEM-2024-0012.pdf”, p. 3) #00b036
- this is related to #bias *
- “DDASR clusters tail APIs with similar functionality and replaces them with cluster centers to produce a pseudo ground truth. Moreover,” (“02-23-TOSEM-2024-0012.pdf”, p. 3) #f0ff00
*this is not clear*
- “rReview53545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031042 Nan et al.API sequence:① Robot.init ② Robot.mousePress ③ Robot.mouseRelease ④ Robot.mouseWheelCode snippet: public class MouseActionsExample { public static void main(String[] args) { Robot robot = new Robot(); robot.mousePress(InputEvent.BUTTON1_MASK); robot.mouseRelease(InputEvent.BUTTON1_MASK); robot.mouseWheel(3);}}Query: Simulate mouse wheel scrolling to control the scrolling of a webpage.Fig. 1. An example query that needs to be addressed using an API sequence in Java.Moreover, fulfilling user requirements often necessitates more than just a single API. Developers typically need to look up API sequences to solve tasks. For instance, to address a query like ‘simulating mouse wheel scrolling to control the scrolling of a webpage,’ as shown in Fig. 1, a sequence of four APIs, including ‘Robot.init,’ ‘Robot.mousePress,’ ‘Robot.mouseRelease,’ and ‘Robot.mouseWheel,’ needs to be invoked. It is a challenging problem to find appropriate API sequences from the vast array of APIs according to developer requirements [50]. Recently, several approaches have been proposed to recommend APIs for developers. These approaches fall into two major categories: information retrieval-based approaches [24, 48, 62] that search for the most relevant solutions from the historical question repository, and deep learning-based approaches [12, 19, 40] that adopt the sequence-to-sequence (Seq2Seq) model to recommend API sequences generatively. Gu et al. [19] adopt an RNN encoder-decoder and Elnaggar et al. [12] adopt a Transformer encoder-decoder to obtain the results of the API sequence. Martin and Guo [40] apply CodeBERT [14] for the task due to the improved performance of Large Language Models (LLMs). However, existing API recommendation approaches usually recommend popular APIs, neglecting less frequently used ones. For example, deep learning-based approaches [12, 19, 40] remove infrequently appearing words from the vocabulary or treat them as <UNK> tags, making it challenging to recommend infrequently occurring APIs to developers.” (“02-23-TOSEM-2024-0012.pdf”, p. 4) #00b036
-
pages/@11697_106776-Adopting MDE for specifying and executing civilian missions of mobile multi-robot systems.md
View File
pages/@11697_111455-A family of domain-specific languages for specifying civilian missions of multi-robot systems.md
View File
pages/@11697_19479.md
+22
View File
@@ -0,0 +1,22 @@
tags:: [[#nosource]]
date:: 2012
extra:: Citation Key: 11697_19479
doi:: 10.1007/s10270-011-0193-0
title:: @11697_19479
pages:: 1-31
volume:: 12
item-type:: [[journalArticle]]
original-title:: Managing the evolution of data-intensive Web applications by model-driven techniques
url:: http://www.springerlink.com/content/3560j06140344197/
publication-title:: SOFTWARE AND SYSTEMS MODELING
authors:: [[A Cicchetti]], [[Davide DI RUSCIO]], [[L Iovino]], [[Alfonso Pierantonio]]
links:: [Local library](zotero://select/library/items/75UQ3XYG), [Web library](https://www.zotero.org/users/1039502/items/75UQ3XYG)
- [[Abstract]]
- The adoption of Model-Driven Engineering (MDE) in the development of Web Applications permitted to decouple the functional description of applications from the underlying implementation platform. This is of paramount relevance for preserving the intellectual property encoded in models and making applications, languages and processes resilient to technological changes. This paper proposes a model-driven approach for supporting the migration and evolution of data-intensive Web applications. In particular, model differencing techniques are considered to realize a migration facility capable of detecting the modifications a model underwent during its lifecycle and to automatically derive from them the programs that are capable of migrating/adapting also those aspects which are not directly derivable from the source models, as for instance the data persistently stored in a database and the page layout usually written using graphic templates. The approach is validated by considering applications described with the beContent and WebML modeling languages.
- [[readingnotes]]
- Citations depend on the citations of our EDOC paper
- The sosym paper was a concrete application or application domain where the problem of (co-)evolution is evident. In the sosym paper we applied the model difference representation metamodel, which is also another paper very cited.
- I think the impact of the sosym paper is also related to the impact of the JOT and EDOC papers.
- [[Attachments]]
- [Cicchetti et al_2012_Managing the evolution of data-intensive Web applications by model-driven.pdf](zotero://select/library/items/L26Q4DJX) {{zotero-imported-file L26Q4DJX, "Cicchetti et al_2012_Managing the evolution of data-intensive Web applications by model-driven.pdf"}}
pages/@11697_89209-Engineering a platform for mission planning of autonomous and resilient quadrotors.md
View File
pages/@2nd international workshop on sustainability and modeling (SusMod’25).md
+19
View File
@@ -0,0 +1,19 @@
tags:: [[#zotero]]
title:: @2nd international workshop on sustainability and modeling (SusMod’25)
item-type:: [[journalArticle]]
original-title:: 2nd international workshop on sustainability and modeling (SusMod’25)
language:: en
authors:: [[Istvan David]], [[Arianna Fedeli]], [[Vincenzo Stoico]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/LGNUD5JX), [Web library](https://www.zotero.org/users/1039502/items/LGNUD5JX)
- [[Abstract]]
- Sustainability is becoming a key characteristic of modern systems. While this trend has been long recognized, rigorous formal methods for assessing sustainability, reasoning about often contradicting sustainability properties, and involving the human in this process are missing. This workshop aims to unearth visceral links between sustainability and MDE, and that, in both directions: MDE in support of sustainable systems engineering, and sustainability of MDE techniques.
- ### Attachments
- [PDF](zotero://select/library/items/Y37PMUI5) {{zotero-imported-file Y37PMUI5, "David et al. - 2nd International Workshop on Sustainability and Modeling (SusMod’25).pdf"}}
- ### Notes
- **REVIEW**
**(1. Workshop title, 2. Motivation, 3. Organization, 4. Workshop format, 5. Additional material).**
The workshop is about a relevant topic. The event is properly motivated, and the proponents have the required expertise to organize a potentially successful workshop. I like the proposed topics of interest. The number of submissions that have been received for the SoSym journal issue on the same theme as the workshop is a sign of the growing interest in the topic of sustainability by the modeling community.
pages/@A Conversation with Barry Boehm%253A Recollections from 50 Years of Software Engineering.md
View File
pages/@A Model Is Not Built By A Single Prompt%3A LLM-Based Conceptual Modeling With Question Decomposition.md
+76
View File
@@ -0,0 +1,76 @@
tags:: [[#zotero]]
date:: 2024
title:: @A Model Is Not Built By A Single Prompt: LLM-Based Conceptual Modeling With Question Decomposition
item-type:: [[journalArticle]]
original-title:: A Model Is Not Built By A Single Prompt: LLM-Based Conceptual Modeling With Question Decomposition
language:: en
authors:: [[Anonymous Author]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/CJQAHLZ5), [Web library](https://www.zotero.org/users/1039502/items/CJQAHLZ5)
- [[Abstract]]
- Conceptual modeling plays a crucial role in model-driven engineering. When the system description is highly complicated or the modelers lack sufficient domain knowledge, the task can become particularly challenging. Large language models (LLMs) can facilitate the task by automatically generating an initial conceptual model from the system description. Nevertheless, model generation is more complex than code generation, and a single prompt to LLMs cannot solve the problem well. This paper proposes an LLMbased conceptual modeling approach via question decomposition. Following conventional modeling guidelines, we divide the model generation task into several sub-problems, i.e., class generation, association and aggregation generation, and inheritance generation. For each sub-problem, we carefully design the prompt by choosing more efficient query words and providing essential modeling knowledge to unlock the modeling potential of LLMs. Finally, we sum up the answers of all the sub-problems and programmatically create a conceptual model to avoid trivial syntactic model errors. We evaluate our approach with 10 systems from different application domains. The preliminary results show that our approach outperforms the singe-prompt-based baseline by improving recall values and F1 scores in most systems.
- ### Attachments
- [Author - 2024 - A Model Is Not Built By A Single Prompt LLM-Based Conceptual Modeling With Question Decomposition.pdf](zotero://select/library/items/7RYW5ZW3) {{zotero-imported-file 7RYW5ZW3, "Author - 2024 - A Model Is Not Built By A Single Prompt LLM-Based Conceptual Modeling With Question Decomposition.pdf"}}
- ### Notes
- # Annotazioni
(19/4/2024, 22:17:28)
- “Large language models (LLMs) can facilitate the task by automatically generating an initial conceptual model from the system description.” (Author, 2024, p. 1) #00b036
- “singe-prompt-” (Author, 2024, p. 1) #ff4400
- “Step3. Semantically check and remove the associations relationships···” (Author, 2024, p. 4) #f0ff00
*This is not clear.*
- “choose a default type.” (Author, 2024, p. 5) #f0ff00
*Can this be a bias or source of error?*
- “default multiplicity,” (Author, 2024, p. 5) #f0ff00
*See my previous comment.*
- “4” (Author, 2024, p. 6) #f0ff00
*Maybe it is too short to justify a separate section. You can merge it with previous section.*
- “with a 1-gram similarity higher than 0.9)” (Author, 2024, p. 6) #f0ff00
*What's the encoding that you have used?*
- “their types are equal,” (Author, 2024, p. 6) #f0ff00
*Can you also identify those that have been killed due to the default type?*
- “-shot version” (Author, 2024, p. 7) #f0ff00
*What's the difference with the baseline?*
- “For our approach, we choose temperature 0.6 for class/attribute generation and 0.3 for relationship generation (see Section 5.6 for the details about temperature selection).” (Author, 2024, p. 7) #f0ff00
*It is necessary to discuss the temperature definition*
- “manually examined the relationships generated by the baseline and strictly followed R3 to fill the” (Author, 2024, p. 7) #f0ff00
*This is a threat to validity. Check if it has been discussed.*
- “Table” (Author, 2024, p. 8) #f0ff00
*Please put in bold the highest values for each metric/approach pair.*
- “Answer.” (Author, 2024, p. 8) #f0ff00
- “two parallel tasks enhance” (Author, 2024, p. 8) #f0ff00
*Why parallel?*
- “baseline” (Author, 2024, p. 9) #f0ff00
*The baseline is your approach here, isn't it?*
- “temperature 0.3” (Author, 2024, p. 9) #f0ff00
*How is it defined?*
- “send the classes in Oracle models to our prompts. We” (Author, 2024, p. 9) #f0ff00
*What does it mean?*
- “11a” (Author, 2024, p. 9) #f0ff00
- “we ignore the internal validity.” (Author, 2024, p. 10) #f0ff00
*I'm not sure this makes sense.*
- “refers to the degree to which the metrics used in a study measures the performance of our approach.” (Author, 2024, p. 10) #f0ff00
*Not sure*
- “Conclusion validity refers to the reliability and accuracy of the conclusions drawn from a study. To avoid a threat to conclusion validity, all results and answers to the research questions in our evaluation were thoroughly discussed until the authors reached an agreement.” (Author, 2024, p. 10) #f0ff00
*Not sure*
pages/@A Survey of Large Language Models.md
+14
View File
@@ -0,0 +1,14 @@
links:: [Local library](zotero://select/library/items/JIJ7DH3Q), [Web library](https://www.zotero.org/users/1039502/items/JIJ7DH3Q)
authors:: [[Wayne Xin Zhao]], [[Kun Zhou]], [[Junyi Li]], [[Tianyi Tang]], [[Xiaolei Wang]], [[Yupeng Hou]], [[Yingqian Min]], [[Beichen Zhang]], [[Junjie Zhang]], [[Zican Dong]], [[Yifan Du]], [[Chen Yang]], [[Yushuo Chen]], [[Zhipeng Chen]], [[Jinhao Jiang]], [[Ruiyang Ren]], [[Yifan Li]], [[Xinyu Tang]], [[Zikang Liu]], [[Peiyu Liu]], [[Jian-Yun Nie]], [[Ji-Rong Wen]]
tags:: [[Computer Science - Artificial Intelligence]], [[Computer Science - Computation and Language]], [[#zotero]]
date:: [[24-09-2024]]
item-type:: [[preprint]]
title:: @A Survey of Large Language Models
- [[Abstract]]
- Language is essentially a complex, intricate system of human expressions governed by grammatical rules. It poses a significant challenge to develop capable AI algorithms for comprehending and grasping a language. As a major approach, language modeling has been widely studied for language understanding and generation in the past two decades, evolving from statistical language models to neural language models. Recently, pre-trained language models (PLMs) have been proposed by pre-training Transformer models over large-scale corpora, showing strong capabilities in solving various NLP tasks. Since researchers have found that model scaling can lead to performance improvement, they further study the scaling effect by increasing the model size to an even larger size. Interestingly, when the parameter scale exceeds a certain level, these enlarged language models not only achieve a significant performance improvement but also show some special abilities that are not present in small-scale language models. To discriminate the difference in parameter scale, the research community has coined the term large language models (LLM) for the PLMs of significant size. Recently, the research on LLMs has been largely advanced by both academia and industry, and a remarkable progress is the launch of ChatGPT, which has attracted widespread attention from society. The technical evolution of LLMs has been making an important impact on the entire AI community, which would revolutionize the way how we develop and use AI algorithms. In this survey, we review the recent advances of LLMs by introducing the background, key findings, and mainstream techniques. In particular, we focus on four major aspects of LLMs, namely pre-training, adaptation tuning, utilization, and capacity evaluation. Besides, we also summarize the available resources for developing LLMs and discuss the remaining issues for future directions.
- ### Attachments
- [Snapshot](https://arxiv.org/abs/2303.18223) {{zotero-imported-file AIGC3JGB, "2303.html"}}
- [Preprint PDF](http://arxiv.org/pdf/2303.18223v14) {{zotero-imported-file MJPU5RR4, "Zhao et al. - 2024 - A Survey of Large Language Models.pdf"}}
- [[Highlights]]
-
pages/@A Survey on Bias and Fairness in Machine Learning.md
+48
View File
@@ -0,0 +1,48 @@
tags:: [[readingnotes]] #bias #fairness #machinelearning
date:: [[31-07-2022]]
issn:: "0360-0300, 1557-7341"
issue:: 6
doi:: 10.1145/3457607
title:: @A Survey on Bias and Fairness in Machine Learning
pages:: 1-35
volume:: 54
item-type:: [[journalArticle]]
access-date:: 2023-02-18T07:10:49Z
original-title:: A Survey on Bias and Fairness in Machine Learning
language:: en
url:: https://dl.acm.org/doi/10.1145/3457607
publication-title:: ACM Computing Surveys
journal-abbreviation:: ACM Comput. Surv.
authors:: [[Ninareh Mehrabi]], [[Fred Morstatter]], [[Nripsuta Saxena]], [[Kristina Lerman]], [[Aram Galstyan]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/8LT96USW), [Web library](https://www.zotero.org/users/1039502/items/8LT96USW)]
-
- [[Abstract]]
- With the widespread use of artificial intelligence (AI) systems and applications in our everyday lives, accounting for fairness has gained significant importance in designing and engineering of such systems. AI systems can be used in many sensitive environments to make important and life-changing decisions; thus, it is crucial to ensure that these decisions do not reflect discriminatory behavior toward certain groups or populations. More recently some work has been developed in traditional machine learning and deep learning that address such challenges in different subdomains. With the commercialization of these systems, researchers are becoming more aware of the biases that these applications can contain and are attempting to address them. In this survey, we investigated different real-world applications that have shown biases in various ways, and we listed different sources of biases that can affect AI applications. We then created a taxonomy for fairness definitions that machine learning researchers have defined to avoid the existing bias in AI systems. In addition to that, we examined different domains and subdomains in AI showing what researchers have observed with regard to unfair outcomes in the state-of-the-art methods and ways they have tried to address them. There are still many future directions and solutions that can be taken to mitigate the problem of bias in AI systems. We are hoping that this survey will motivate researchers to tackle these issues in the near future by observing existing work in their respective fields.
- [[Attachments]]
- [Mehrabi et al. - 2022 - A Survey on Bias and Fairness in Machine Learning.pdf](zotero://select/library/items/VHPDAFE3) {{zotero-imported-file VHPDAFE3, "Mehrabi et al. - 2022 - A Survey on Bias and Fairness in Machine Learning.pdf"}}
- [[Highlights]]
- ((6449054a-bea4-4b8c-9878-d490a823bb9f))
- In the context of **decision-making** fairness is:
- ((64490984-7bb9-4f37-acc7-a0e9b92755af)) [[definition]]
- Potential sources of unfairness in machine learning outcomes arise from ==biases in the data== and ==those that arise from algorithms==.
- #+BEGIN_IMPORTANT
((64490b15-3caf-43ed-8eb9-5a097962942d))
#+END_IMPORTANT
- #+BEGIN_QUOTE
((64491040-2bef-4c75-ac2c-24a4375dc08e))
#+END_QUOTE
- ((644913fd-f97d-46cc-94ae-504f5d4cdfbb))
- Reference papers to see:
- ((64491361-223a-4d46-b120-9e81f0226d1e))
- ((6449137d-1640-497d-86be-184627860674))
- #+BEGIN_IMPORTANT
Possiamo dire quindi che bias e' una motivazione/source di unfairness
Noi ci focalizziamo sulla definizione di fairness focalizzandoci su biases in data
#+END_IMPORTANT
- ((64491956-8fb9-45f0-8472-81aaafe147f5))
- ((64491a84-f0c7-4bbc-af7c-2c8fc605f702))
- ((644a347e-bcf2-4675-8d5e-6e86cbc7b9d9))
-
-
pages/@An Empirical Study of Pre-Trained Model Reuse in the Hugging Face Deep Learning Model Registry.md
+52
View File
@@ -0,0 +1,52 @@
links:: [Local library](zotero://select/library/items/VVIQAVNB), [Web library](https://www.zotero.org/users/1039502/items/VVIQAVNB)
authors:: [[Wenxin Jiang]], [[Nicholas Synovic]], [[Matt Hyatt]], [[Taylor R. Schorlemmer]], [[Rohan Sethi]], [[Yung-Hsiang Lu]], [[George K. Thiruvathukal]], [[James C. Davis]]
tags:: [[Computer Science - Artificial Intelligence]], [[Computer Science - Machine Learning]], [[Computer Science - Software Engineering]], [[#zotero]]
date:: [[04-03-2023]]
item-type:: [[preprint]]
title:: @An Empirical Study of Pre-Trained Model Reuse in the Hugging Face Deep Learning Model Registry
-
- Abstract
- Deep Neural Networks (DNNs) are being adopted as components in software systems. Creating and specializing DNNs from scratch has grown increasingly difficult as state-of-the-art architectures grow more complex. Following the path of traditional software engineering, machine learning engineers have begun to reuse large-scale pre-trained models (PTMs) and fine-tune these models for downstream tasks. Prior works have studied reuse practices for traditional software packages to guide software engineers towards better package maintenance and dependency management. We lack a similar foundation of knowledge to guide behaviors in pre-trained model ecosystems. In this work, we present the first empirical investigation of PTM reuse. We interviewed 12 practitioners from the most popular PTM ecosystem, Hugging Face, to learn the practices and challenges of PTM reuse. From this data, we model the decision-making process for PTM reuse. Based on the identified practices, we describe useful attributes for model reuse, including provenance, reproducibility, and portability. Three challenges for PTM reuse are missing attributes, discrepancies between claimed and actual performance, and model risks. We substantiate these identified challenges with systematic measurements in the Hugging Face ecosystem. Our work informs future directions on optimizing deep learning ecosystems by automated measuring useful attributes and potential attacks, and envision future research on infrastructure and standardization for model registries.
- ### Attachments
- [arXiv.org Snapshot](https://arxiv.org/abs/2303.02552) {{zotero-imported-file JBL2ELEQ, "2303.html"}}
- [Jiang et al_2023_An Empirical Study of Pre-Trained Model Reuse in the Hugging Face Deep Learning.pdf](https://arxiv.org/pdf/2303.02552.pdf) {{zotero-imported-file FC5QI4KB, "Jiang et al_2023_An Empirical Study of Pre-Trained Model Reuse in the Hugging Face Deep Learning.pdf"}}
- ### Notes
- Comment: Proceedings of the ACM/IEEE 45th International Conference on Software Engineering (ICSE) 2023
- [[Highlights]]
- ((65a99501-0072-404d-b1f0-d862178a8a9e))
- DNN
- pre-trained on large datasets
- fine-tuned to solve specialized tasks
- ((65baa9b4-3525-42c9-867a-0fbf563056b1)): a collaborative model hub where teams can share DL moels. Examples are:
- Hugging Face (It offers the largest and most diverse set of pre trained models $\approx$ 60,000 PTMs)
- TensorFlow Hub
- PyTorch Hub
- ONNX Model Zoo
- *DL Traceability* is limited because authors often omit training logs and documentation.
- Interestingly, the work discusses:
- how engineers select PTM
- the PTM attributes that facilitate PTM reuse
- the challenges of PTM reuse
- risks related to the reuse of PTMs
-
- Two main reuse techniques are employed:
- Transfer learning
- Quantization techniques
- Expertes find easier to reuse PTMs from DL model registries than adopting PTMs from GitHub projects. In particular, typically users take PTMs from model registries and apply [[tranfer larning]] techniques to the model. They reuse is performed by fine-tuning an existing PTM by optionally extending the architecture and training on a task-specific dataset, or by building a new model on top of the pre-trained one.
- The **decision-making process** to select PTMs that are more appropriate for the task to be performed typically considers at least the following aspects:
- *Reusability assessment* by considering requirements related to model input and output, latency, size and licensing. The availability of enough computational resources is also an important aspect, which is considering when evaluating PTMs
- *Downstream evaluation*: after selecting candidate PTMs, engineers conduct a downstream evaluation for their rspecific task, thus they finetune them, test them, and compare them. This is a strenuos activity because models might not work tool well directly, and it can happen to miss adequate documantion or observing discrepancies within existing documantions. The effort required to deploy PTMs is also a relevant characteristics, which is considered when selecting them.
- The typical attributes, which are typically considered when **evaluating and comparing PTMs** are:
- Popularity, assessed e.g., by considering the number of download
- Provenance, e.g., information about original paper, dataset, and architecture.
- Reproducibility, it comes from two aspects: (1) the configuration of training (e.g., hardware types, required memory, training scripts, hyperparameters), (2) the understanding of the model (e.g., availability of notebook demo, and documentation)
- Portability, it includes hardware specification and environment.
- The **challenges** of PTM reuse
- Missing attributes in the model registries including datasets, licensing, and model details. For instance, Hugging Face does not enforce any form of documentation. In any case, model registries, do not provide automated approaches to measure model attributes.
- Descrepancies, e.g., models are over-promising, models are not named correctly, or provided scripts are broken. A reasing for this kind of problem is that training configuration details (i.e., hyper-parameters) are hard to find.
- Model risks including privacy and ethics aspects. In particular, users can be reluctant to send their sensitive dataset to Hugging Face. Moreover, if a model is trained with malicious intents, it could have a lot of consequences. This indicates the potential risks of a malicious model being uploaded to model registries.
-
-
- Summary for the SOTA of the [[PROJECTS/MOSAICO]] project proposal:
- DNNs are often pre-trained on large datasets and fine-tuned for specialized tasks. Model registries like Hugging Face, TensorFlow Hub, and PyTorch Hub serve as collaborative hubs for sharing DNN models. In [X] authors explore how engineers select Pre-Trained Models (PTMs), emphasizing PTM attributes that facilitate reuse, challenges, and associated risks. In the performed investigation, the preference for reusing PTMs from model registries over GitHub projects is noted. The decision-making process for selecting PTMs considers factors like reusability, downstream evaluation, and deployment effort. Attributes like popularity, provenance, reproducibility, and portability are crucial in evaluating and comparing PTMs. The mains challenges in PTM reuse include missing attributes in registries, discrepancies in model promises, and potential risks related to privacy and ethics, emphasizing the need for robust documentation and governance in collaborative model sharing platforms.
pages/@Analyzing business process management capabilities of low-code development platforms.md
+24
View File
@@ -0,0 +1,24 @@
tags:: [[business process management]], [[low-code development platforms]], [[model-driven engineering]]
date:: 2023
issn:: 1097-024X
issue:: 4
extra:: _eprint: https://onlinelibrary.wiley.com/doi/pdf/10.1002/spe.3177
doi:: 10.1002/spe.3177
title:: @Analyzing business process management capabilities of low-code development platforms
pages:: 1036-1060
volume:: 53
item-type:: [[journalArticle]]
access-date:: 2023-05-17T09:54:52Z
original-title:: Analyzing business process management capabilities of low-code development platforms
language:: en
url:: https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.3177
publication-title:: Software: Practice and Experience
authors:: [[Apurvanand Sahay]], [[Davide Di Ruscio]], [[Ludovico Iovino]], [[Alfonso Pierantonio]]
library-catalog:: Wiley Online Library
links:: [Local library](zotero://select/library/items/YIEZY5SN), [Web library](https://www.zotero.org/users/1039502/items/YIEZY5SN)
-
- [[Abstract]]
- Low-code development platforms (LCDPs) aim to simplify software systems' development by providing easy-to-use graphical interfaces and drag-and-drop facilities. The system behaviors are defined through available data handling and workflow mechanisms enabling the specification of business processes from users that do not have strong programming skills. However, the number of LCDPs has grown significantly over the last few years. Consequently, it is not easy for inexpert users to understand their differences, especially in terms of provided modeling constructs. In this article, we analyze and compare eight low-code development platforms by focusing on their capabilities for specifying business processes. The analysis exploits business process modeling and notation (BPMN) as a reference modeling language. Thus, the core elements of BPMN are leveraged to analyze the workflow mechanisms provided by each of the analyzed LCDP. The article explains different types of process flows and data handling means of the different LCDPs aiming to give potential users objective elements that can be used to make educated decisions when selecting LCDPs.
- [[Attachments]]
- [Sahay et al_2023_Analyzing business process management capabilities of low-code development.pdf](https://onlinelibrary.wiley.com/doi/pdfdirect/10.1002/spe.3177) {{zotero-imported-file U5IDWZXP, "Sahay et al_2023_Analyzing business process management capabilities of low-code development.pdf"}}
pages/@Application of Large Language Models to Software Engineering Tasks%3A Opportunities, Risks, and Implications.md
+25
View File
@@ -0,0 +1,25 @@
date:: 5/2023
issn:: "0740-7459, 1937-4194"
issue:: 3
doi:: 10.1109/MS.2023.3248401
title:: @Application of Large Language Models to Software Engineering Tasks: Opportunities, Risks, and Implications
pages:: 4-8
volume:: 40
item-type:: [[journalArticle]]
access-date:: 2023-09-18T09:53:52Z
original-title:: "Application of Large Language Models to Software Engineering Tasks: Opportunities, Risks, and Implications"
language:: en
url:: https://ieeexplore.ieee.org/document/10109345/
short-title:: Application of Large Language Models to Software Engineering Tasks
publication-title:: IEEE Software
journal-abbreviation:: IEEE Softw.
authors:: [[Ipek Ozkaya]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/DY4XFZG6), [Web library](https://www.zotero.org/users/1039502/items/DY4XFZG6)
-
- [[Highlights]]
- ((65082b88-cec6-4393-af1d-3f5b933fac38)) #LLMs #card
id:: 65c8d450-b6f8-42ac-b445-1d51468be72c
- [[Attachments]]
- [Ozkaya - 2023 - Application of Large Language Models to Software E.pdf](zotero://select/library/items/WHX3PLDV) {{zotero-imported-file WHX3PLDV, "Ozkaya - 2023 - Application of Large Language Models to Software E.pdf"}}
pages/@Asleep at the Keyboard%3F Assessing the Security of GitHub Copilot's Code Contributions.md
+15
View File
@@ -0,0 +1,15 @@
links:: [Local library](zotero://select/library/items/5PK7X33X), [Web library](https://www.zotero.org/users/1039502/items/5PK7X33X)
authors:: [[Hammond Pearce]], [[Baleegh Ahmad]], [[Benjamin Tan]], [[Brendan Dolan-Gavitt]], [[Ramesh Karri]]
tags:: [[Computer Science - Artificial Intelligence]], [[Computer Science - Cryptography and Security]], [[readingnotes]]
date:: [[16-12-2021]]
item-type:: [[preprint]]
title:: @Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions
- [[Abstract]]
- There is burgeoning interest in designing AI-based systems to assist humans in designing computing systems, including tools that automatically generate computer code. The most notable of these comes in the form of the first self-described `AI pair programmer', GitHub Copilot, a language model trained over open-source GitHub code. However, code often contains bugs - and so, given the vast quantity of unvetted code that Copilot has processed, it is certain that the language model will have learned from exploitable, buggy code. This raises concerns on the security of Copilot's code contributions. In this work, we systematically investigate the prevalence and conditions that can cause GitHub Copilot to recommend insecure code. To perform this analysis we prompt Copilot to generate code in scenarios relevant to high-risk CWEs (e.g. those from MITRE's "Top 25" list). We explore Copilot's performance on three distinct code generation axes -- examining how it performs given diversity of weaknesses, diversity of prompts, and diversity of domains. In total, we produce 89 different scenarios for Copilot to complete, producing 1,689 programs. Of these, we found approximately 40% to be vulnerable.
- [[Attachments]]
- [arXiv.org Snapshot](https://arxiv.org/abs/2108.09293) {{zotero-imported-file TUD3FF8G, "2108.html"}}
- [Pearce et al_2021_Asleep at the Keyboard.pdf](https://arxiv.org/pdf/2108.09293.pdf) {{zotero-imported-file K48J8CSX, "Pearce et al_2021_Asleep at the Keyboard.pdf"}}
- [[readingnotes]]
- Comment: Accepted for publication in IEEE Symposium on Security and Privacy 2022
- ((64468be5-de8e-46a4-9373-96158417ab31))
pages/@Attention Is All You Need.md
+15
View File
@@ -0,0 +1,15 @@
links:: [Local library](zotero://select/library/items/SFU9SM2B), [Web library](https://www.zotero.org/users/1039502/items/SFU9SM2B)
authors:: [[Ashish Vaswani]], [[Noam Shazeer]], [[Niki Parmar]], [[Jakob Uszkoreit]], [[Llion Jones]], [[Aidan N. Gomez]], [[Lukasz Kaiser]], [[Illia Polosukhin]]
tags:: [[Computer Science - Computation and Language]], [[Computer Science - Machine Learning]], [[#zotero]] [[AI/Attention]]
date:: [[05-12-2017]]
item-type:: [[preprint]]
title:: @Attention Is All You Need
-
- [[Abstract]]
- The dominant sequence transduction models are based on complex recurrent or convolutional neural networks in an encoder-decoder configuration. The best performing models also connect the encoder and decoder through an attention mechanism. We propose a new simple network architecture, the Transformer, based solely on attention mechanisms, dispensing with recurrence and convolutions entirely. Experiments on two machine translation tasks show these models to be superior in quality while being more parallelizable and requiring significantly less time to train. Our model achieves 28.4 BLEU on the WMT 2014 English-to-German translation task, improving over the existing best results, including ensembles by over 2 BLEU. On the WMT 2014 English-to-French translation task, our model establishes a new single-model state-of-the-art BLEU score of 41.8 after training for 3.5 days on eight GPUs, a small fraction of the training costs of the best models from the literature. We show that the Transformer generalizes well to other tasks by applying it successfully to English constituency parsing both with large and limited training data.
- ### Attachments
- [arXiv.org Snapshot](https://arxiv.org/abs/1706.03762) {{zotero-imported-file ID22NYCU, "1706.html"}}
- [Vaswani et al_2017_Attention Is All You Need.pdf](https://arxiv.org/pdf/1706.03762.pdf) {{zotero-imported-file YMLJF6I7, "Vaswani et al_2017_Attention Is All You Need.pdf"}}
- ### Notes
- Comment: 15 pages, 5 figures
pages/@AutoEmbed%3A towards automated software development for generic embedded IoT systems via LLMs.md
+184
View File
@@ -0,0 +1,184 @@
tags:: [[#zotero]]
title:: @AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs
item-type:: [[journalArticle]]
original-title:: AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs
language:: en
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/G8G3WY38), [Web library](https://www.zotero.org/users/1039502/items/G8G3WY38)
- [[Abstract]]
- Embedded Internet of Things (IoT) system development is crucial for enabling seamless connectivity and functionality across a wide range of applications. However, such a complex process requires cross-domain knowledge of hardware and software and hence often necessitates direct developer involvement, making it labor-intensive, time-consuming, and error-prone. To address this challenge, this paper introduces AutoEmbed, the first fully automated software development platform for general-purpose embedded IoT systems. The key idea is to leverage the reasoning ability of Large Language Models (LLMs) and embedded system expertise to automate the hardware-in-the-loop development process. The main methods include a component-aware library resolution method for addressing hardware dependencies, a library knowledge generation method that injects utility domain knowledge into LLMs, and an auto-programming method that ensures successful deployment. We evaluate AutoEmbed’s performance across 71 modules and four mainstream embedded development platforms with over 350 IoT tasks. Experimental results show that AutoEmbed can generate codes with an accuracy of 95.7% and complete tasks with a success rate of 86.5%, surpassing human-in-the-loop baselines by 15.6%–37.7% and 25.5%–53.4%, respectively. We also show AutoEmbed ’s potential through case studies in environmental monitoring and remote control systems development.
- ### Attachments
- [PDF](zotero://select/library/items/3MGT3I8L) {{zotero-imported-file 3MGT3I8L, "AutoEmbed Towards Automated Software Development for Generic Embedded IoT Systems via LLMs.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotazioni
(6/5/2025, 15:15:36)
- “AutoEmbed: Towards Automated Software Development for Generic Embedded IoT Systems via LLMs” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #ffd400
*Overall it is an interesting paper about a relevant topic. In my opinion there are some presentation issues, which affect the quality of the paper, which requires improvements to better present the approach and to be more convincing from the evaluation point of view.*
- “this paper introduces AutoEmbed, the first fully automated software development platform for general-purpose embedded IoT systems.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #a28ae5
- “automate the hardware-in-the-loop development process” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #a28ae5
- “We evaluate AutoEmbed’s performance across 71 modules and four mainstream embedded development platforms with over 350 IoT tasks.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #a28ae5
- “accuracy of 95.7%” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #e56eee
- “We also show AutoEmbed ’s potential through case studies in environmental monitoring and remote control systems development.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #a28ae5
- “For example, in a smart city [34, 42], embedded systems control street lighting and traffic signals based on sensor data to optimize energy use and traffic flow.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #5fb236
- “understanding” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #5fb236
- “how devices interact with the physical world” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #5fb236
- “Initially, developers must manually address dependencies by installing and configuring the essential libraries for hardware modules.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #5fb236
- “Keil μVision, and IAR” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #ffd400
*what are these? To check*
- “A fully automated platform for developing embedded IoT systems” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #ffd400
*Let's see. but I expect a strong evaluation consisting of IoT systems developed with AutoEmbed as promised/described in the paper.*
- “diversity” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #5fb236
- “hardware modules” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #5fb236
- “ncreases the complexity” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #5fb236
- “the traditional embedded IoT system development process is labor-intensive, time-consuming, and error-prone” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #5fb236
- “Large Language Models (LLMs) to streamline embedded IoT system development.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #a28ae5
- “harness their capabilities to simplify the development process by automating processes such as dependency-solving, coding, and deployment.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #e56eee
- “they fall short in driving specific hardware devices (e.g., microcontrollers and sensors) due to a lack of hardware-specific knowledge in embedded systems, such as peripheral interface configurations and library dependencies.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #e56eee
- “LLM-powered automation system that streamlines the dependency-solving, programming, and deployment processes in embedded system development, resulting in fully-developed embedded systems for various IoT applications as illustrated in Fig. 1.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #e56eee
- “Challenge 1: Diversity in Hardware Dependency” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #2ea8e5
- “Each component relies on specific library dependencies to function effectively, leading to unique challenges in dependency resolution.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 1) #a28ae5
- “accurately identifying and selecting the essential libraries for different hardware components is a significant challenge.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #e56eee
- “ibrary selection, revealing that different libraries exhibit distinct compatibility with specific models and varying support for development board architectures” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #a28ae5
- “we propose an automated dependency solving method that can efficiently identify the most suitable libraries for specific hardware components.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #e56eee
- “Challenge 2: Lack of Library Knowledge” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #2ea8e5
- “knowledge generation method that extracts and injects library API and utility knowledge into the LLM’s memory, enabling syntactically and contextually appropriate solutions.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #a28ae5
- “Challenge 3: Complexity of Embedded System Programming.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #2ea8e5
- “In general-purpose programming, the workflow typically involves coding, debugging, and deployment. In contrast, embedded system programming introduces additional steps such as compiling and flashing, which require specialized configurations and are particularly error-prone” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #ffd400
*Compilation can occur also in general-purpose programming and not only in embedded system programming!*
- “compile loop” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #2ea8e5
- “Figure 3: Programming pipeline comparison.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #ffd400
*I would improve Fig. 3.b with a loop involving Compiling->Flashing->Debugging->Compiling .... because otherwise it seems that the typical pipeline involve only two flashing stepts, whcih of course it is not what the authors meant.*
- “flash loop” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #2ea8e5
- “we design and implement AutoEmbed, a comprehensive framework that fully automates the dependency-solving, programming, and deployment processes for embedded system development.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #e56eee
- “Our extensive evaluation, involving over 70 hardware modules, four development platforms, and over 350 IoT tasks, demonstrates that AutoEmbed achieves an average coding accuracy of 95.7% and an average completion rate of 86.5%, highlighting the effectiveness of AutoEmbed.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #e56eee
*Interesting to see how these configurations have been actually checked (see the evaluation section later in the paper).*
- “library resolution method for hardware dependency solving” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #2ea8e5
- “knowledge generation method that enhances LLMs with specialized library knowledge” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #2ea8e5
- “auto-programming method to ensure successful deployment” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #2ea8e5
- “EmbedTask dataset” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #2ea8e5
- “which will be made publicly available upon paper acceptance.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #ffd400
*This poses some issues concerning the reproducibility of the approach during the review phase.*
- “95.7% across various IoT tasks” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #5fb236
- “Es = g(D, M)” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #5fb236
- “development platform” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #2ea8e5
- “connected modules” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 2) #2ea8e5
- “Figure 4:” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 3) #ffd400
*This looks like Fig. 3.b. I suggest to remove one of them.*
- “Solving Dependencies.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 3) #ffd400
*Why not putting in the formalization, Ls directly in Es? Ls should be found depending on the modules building up the system being developed.*
- “probability is computed using a softmax function” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 3) #5fb236
- “memory-augmented LLMs to generate task prompts and automate system programming” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 3) #5fb236
- “3.1.1 Hardware Configuration” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 3) #2ea8e5
- “3.1.2 Solving Library Dependencies” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 3) #2ea8e5
- “The score is based on the number of available library versions, normalized between 0 and 1” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 4) #ffd400
*Why between 0 and 1? This is not clear. Many versions of the same library might be available, isn't it?*
- “3.2.1 Library Knowledge Extraction” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 4) #2ea8e5
- “This involves two main steps: API extraction and obtaining API usage information” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 4) #5fb236
- “searches for example (.ino) files within the same library and extracts knowledge on how to use the extracted APIs (e.g., orders, parameters, and return values).” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 4) #5fb236
- “3.2.2 Functionality Knowledge Understanding” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 4) #2ea8e5
- “functionality” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 4) #ffd400
*What do you mean with functionality here? The given formalizations (equations) do not add more. I would replace them with some concrete examples, to complement the graphical representation given in Fig. 7. Without concrete examples, terms like function or functionality might be understood differently by reviewers.*
- “Hence, we opt to incorporate only the most crucial information necessary for accomplishing the user’s task.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 4) #5fb236
- “Knowledge Extraction” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 5) #ffd400
*This does not mach with Fig. 8. There is not steps in the figure that refers knowledge extraction phases.*
- “2) API Table Lookup: Next, we look up the API table to retrieve usage information about the matched APIs. This information AT is then incorporated into the prompt, allowing for more accurate and relevant code generation” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 5) #ffd400
*Again, there is some mismatch with Fig. 8. In paragraph 3.3.1 we are missing an explicit reference to the "Insert Memory into Prompt" phase shown in Fig. 8.*
- “3.4.1 Coder” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 5) #2ea8e5
- “P (G |xT ; θ ) = T Ö t =1 P (Gt |G<t , x; θ ),” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 5) #ffd400
*See my previous comment related to the opportunity of putting of not equations that do not add clarifications. They stay at a too high level of details and as a such they do not contribute too much to the presentation. I would replace them with some concrete and explanatory example.*
- “3.4.2 Compile Loop” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 5) #2ea8e5
- “3.4.3 Flash Loop.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 5) #2ea8e5
- “The Coder generates the initial code G with embedded DEBUG INFO statements D (G) (step 1 ).” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 6) #ffd400
*What's the input of the process? How are the requirements of the wanted system given?*
- “If the code is not ready, the Compile Validator identifies the issues and prompts corrections.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 6) #ffd400
*What if the code compiles correctly but the system does not implement all the wanted functionalities or none of them at all?*
- “Flash Validator identifies a logical error where the LED is incorrectly turned off when the temperature exceeds 30°C.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 6) #ffd400
*Related to the previous comment, it is not clear how the set of validations that get executed are obtained from the initial input. In other words, it is not clear how the set of validations are derived from the input.*
- “modifications. (step 4 )” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 6) #ff6666
*Move the point after ")".*
- “Prompt design:” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 6) #ff6666
*I think this can be dropped from the text.*
- “EmbedTask includes 355 tasks, covering different modules and varying complexity levels.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 6) #ffd400
*Are these tasks kinds of requirements of different applications? What's the granularity of the task description?*
- “EmbedTask classifies tasks into three difficulty levels:” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 6) #ffd400
*It's not clear how this can work in general. How these three level have been decided? It's alway three levels? It's difficult to distinguish the steps that are example specific from those that are supposed to be generic.*
- “Figure 10: Experimental devices.” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 7) #ffd400
*The experimental settings involving all these different platforms and devises should be better described especially concerning the level of human involvement in the evaluation process.*
- “Library Solving” (“AutoEmbed: towards automated software development for generic embedded IoT systems via LLMs”, p. 7) #ffd400
*It's not clear how the library solving problem has been investigated by using the "coding accuracy" and "completion rate" metrics that seem to work at a different level of abstraction (more at code level). Isn't it?*
COnsider that those that are tagget with #5fb236 are just highlights, those that are tagged with #e56eee and #a28ae5 are imporant 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 sentence to summarize the work COMMENTS: Organize the notes especially those that contain issues or typos.
pages/@Automated Integration of Safety Mechanisms into Functional Software for Safety-relevant Systems.md
+224
View File
@@ -0,0 +1,224 @@
tags:: [[#zotero]]
title:: @Automated Integration of Safety Mechanisms into Functional Software for Safety-relevant Systems
item-type:: [[journalArticle]]
original-title:: Automated Integration of Safety Mechanisms into Functional Software for Safety-relevant Systems
language:: en
authors:: [[Rolf Schmedes]], [[Gregor Nitsche]], [[Kim Grüttner]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/G63N5AJQ), [Web library](https://www.zotero.org/users/1039502/items/G63N5AJQ)
- [[Abstract]]
- Embedded systems have become indispensable in areas such as aerospace, the automotive industry, medical technology, and industrial control. Ensuring their reliable and safe operation is crucial for safeguarding human life and valuable assets. Software safety mechanisms play a key role in ensuring safety in these safety-relevant systems. International standards, such as IEC 61508, define necessary safety mechanisms to mitigate risks and achieve certification. This circumstance leads to an unchanging and recurring set of safety mechanisms that are manually re-implemented again and again from project to project. To make this software development process more efficient, this paper presents a model-based approach that utilizes a strict separation between functional and safety software to integrate safety mechanisms automatically into functional software for safety-related systems. An automated analysis of existing functional source code and the targeted hardware platform identifies possible integration points for safety mechanisms. A configuration a safety engineer creates is then used to integrate safety mechanisms from existing libraries through code generation. In addition to this approach, a prototypical implementation and its exemplary application are also described in this paper.
- ### Attachments
- [Schmedes et al. - Automated Integration of Safety Mechanisms into Functional Software for Safety-relevant Systems.pdf](zotero://select/library/items/SJVW878V) {{zotero-imported-file SJVW878V, "Schmedes et al. - Automated Integration of Safety Mechanisms into Functional Software for Safety-relevant Systems.pdf"}}
- ### Notes
- # Annotazioni
(22/6/2024, 10:19:57)
- “Ensuring their reliable and safe operation is crucial for safeguarding human life and valuable asset” (Schmedes et al., p. 1) #5fb236
* *
- “safety mechanisms that are manually re-implemented again and again from project to project” (Schmedes et al., p. 1) #a28ae5
* *
- “model-based approach that utilizes a strict separation between functional and safety software to integrate safety mechanisms automatically into functional software for safety-related systems” (Schmedes et al., p. 1) #a28ae5
* *
- “identifies possible integration points for safety mechanisms.” (Schmedes et al., p. 1) #ffd400
*Interesting to see how!!! *
- “software that is designed and implemented to ensure that it operates correctly and reliably, particularly in critical or hazardous situations where failures could lead to harm, injury, or damag” (Schmedes et al., p. 1) #5fb236
* *
- “Functionally safe software is the combination of functional software and safety software” (Schmedes et al., p. 1) #a28ae5
* *
- “systematic and rigorous process that considers the software’s functional and safety-related aspects.” (Schmedes et al., p. 1) #a28ae5
* *
- “Following those standards, the software design includes both the design of the functional software and the design of the safety software” (Schmedes et al., p. 1) #a28ae5
* *
- “integration of safety mechanisms increases the complexity of the overall code base” (Schmedes et al., p. 1) #5fb236
* *
- “no clear separation between functional and safety software.” (Schmedes et al., p. 1) #a28ae5
* *
- “Modifications to functional code may impact safety mechanisms and vice versa” (Schmedes et al., p. 1) #a28ae5
* *
- “Changes must be carefully analyzed to ensure they do not compromise safety requirements or introduce new risks.” (Schmedes et al., p. 1) #5fb236
* *
- “This tight coupling makes it more challenging to implement changes without affecting other aspects of the system.” (Schmedes et al., p. 1) #a28ae5
* *
- “assumption that a set of unchanging safety mechanisms must be implemented for the software system of a safety-relevant product.” (Schmedes et al., p. 1) #ffd400
*How strong/realistic is this assumption? IN the previous paragraphs authors have stressed the fact that software systems evolve and the coupled evolution of functionalities and software mechanisms occurs and it has to be properly managed. *
- “his work presents a semi-automated process for integrating safety software mechanisms for safety-relevant systems.” (Schmedes et al., p. 1) #a28ae5
* *
- “weaving that is as automated as possible.” (Schmedes et al., p. 1) #a28ae5
*This reminds me generative programming and aspect oriented programming...... *
- “The subsequent demonstration section shows the results using the example of an adaptive cruise controller.” (Schmedes et al., p. 2) #5fb236
* *
- “chapter” (Schmedes et al., p. 2) #ff6666
*SECTION *
- “unctionally safe software” (Schmedes et al., p. 2) #5fb236
* *
- “software safety mechanisms required by common standard” (Schmedes et al., p. 2) #5fb236
* *
- “guidelines for designing, implementing, and maintaining systems intended for safety-relevant applications” (Schmedes et al., p. 2) #5fb236
* *
- “in [8]” (Schmedes et al., p. 2) #ffd400
*What's the novelty with respect to this work? *
- “IEC 61508 is based on the principle that any safety-related system should either function correctly or fail predictably and safely under all possible stated conditions” (Schmedes et al., p. 2) #a28ae5
* *
- “the safety life cycle, consisting of 16 phases to achieve this objective.” (Schmedes et al., p. 2) #5fb236
* *
- “probabilistic failure approach to categorize the safety implications of a component’s failure” (Schmedes et al., p. 2) #5fb236
* *
- “hazard identification, analysis, and risk assessment” (Schmedes et al., p. 2) #5fb236
* *
- “Quantification of risk can be achieved through either qualitative or quantitative analysis techniques” (Schmedes et al., p. 2) #a28ae5
* *
- “safety integrity level (SIL)” (Schmedes et al., p. 2) #5fb236
* *
- “Safety integrity is defined as the likelihood that the safety-related system will effectively execute the necessary safety functions under all specified conditions” (Schmedes et al., p. 2) #5fb236
* *
- “Four distinct safety integrity levels outline the requirements for a particular function” (Schmedes et al., p. 2) #a28ae5
* *
- “to achieve a higher risk reduction, the safetyrelated system must have a higher reliability, which requires a correspondingly higher target SIL” (Schmedes et al., p. 2) #a28ae5
* *
- “The compatibility of those mechanisms with the presented approach will be discussed in the concluding section of this paper.” (Schmedes et al., p. 2) #ffd400
*Their compatibility with the proposed approach has been something consedered by design, or it happend "by accidence"? *
- “Safety Mechanisms” (Schmedes et al., p. 2) #5fb236
* *
- “Contracts” (Schmedes et al., p. 2) #5fb236
* *
- “Dual Modular Redundancy” (Schmedes et al., p. 3) #5fb236
* *
- “safeguarded function is initially executed redundantly” (Schmedes et al., p. 3) #5fb236
* *
- “If the results match, there is no error.” (Schmedes et al., p. 3) #a28ae5
* *
- “even an external monitoring facility, depending on the actual implementation of the mechanism.” (Schmedes et al., p. 3) #5fb236
* *
- “Time Measurement and Control Blocks” (Schmedes et al., p. 3) #5fb236
* *
- “However, the complexity compared to AOP is reduced by limiting it to the two basic types of safety mechanisms,” (Schmedes et al., p. 6) #5fb236
* *
- “better compromise between complexity and effectiveness.” (Schmedes et al., p. 7) #5fb236
* *
- “However, the main distinction from AOP is the combined, holistic view of functional source code, safety mechanisms, and the targeted hardware platform.” (Schmedes et al., p. 7) #5fb236
* *
pages/@Battle of the Wordsmiths%3A Comparing ChatGPT, GPT-4, Claude, and Bard.md
+22
View File
@@ -0,0 +1,22 @@
tags:: [[#zotero]]
date:: 2023
issn:: 1556-5068
doi:: 10.2139/ssrn.4476855
title:: @Battle of the Wordsmiths: Comparing ChatGPT, GPT-4, Claude, and Bard
item-type:: [[journalArticle]]
access-date:: 2024-01-17T23:15:23Z
original-title:: "Battle of the Wordsmiths: Comparing ChatGPT, GPT-4, Claude, and Bard"
language:: en
url:: https://www.ssrn.com/abstract=4476855
short-title:: Battle of the Wordsmiths
publication-title:: SSRN Electronic Journal
journal-abbreviation:: SSRN Journal
authors:: [[Ali Borji]], [[Mehrdad Mohammadian]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/SG494NLL), [Web library](https://www.zotero.org/users/1039502/items/SG494NLL)
-
- [[Abstract]]
- Although informal evaluations of modern LLMs can be found on social media, blogs, and news outlets, a formal and comprehensive comparison among them has yet to be conducted. In response to this gap, we have undertaken an extensive benchmark evaluation of LLMs and conversational bots. Our evaluation involved the collection of 1002 questions encompassing 27 categories, which we refer to as the “Wordsmiths dataset.” These categories include reasoning, logic, facts, coding, bias, language, humor, and more. Each question in the dataset is accompanied by an accurate and verified answer. We meticulously assessed four leading chatbots: ChatGPT, GPT-4, Bard, and Claude, using this dataset. The results of our evaluation revealed the following key findings: a) GPT-4 emerged as the top-performing chatbot across almost all categories, achieving a success rate of 84.1%. On the other hand, Bard faced challenges and achieved a success rate of 62.4%. b) Among the four models evaluated, one of them responded correctly approximately 93% of the time. However, all models were correct only about 44%. c) Bard is less correlated with other models while ChatGPT and GPT-4 are highly correlated in terms of their responses. d) Chatbots demonstrated proficiency in language understanding, facts, and self-awareness. However, they encountered difficulties in areas such as math, coding, IQ, and reasoning. e) In terms of bias, discrimination, and ethics categories, models generally performed well, suggesting they are relatively safe to utilize. To make future model evaluations on our dataset easier, we also provide a multiple-choice version of it (called Wordsmiths-MCQ). Dataset link: [MASKED].
- ### Attachments
- [Borji e Mohammadian - 2023 - Battle of the Wordsmiths Comparing ChatGPT, GPT-4.pdf](https://openreview.net/pdf?id=sTr11zs10n) {{zotero-imported-file YA2FUYV7, "Borji e Mohammadian - 2023 - Battle of the Wordsmiths Comparing ChatGPT, GPT-4.pdf"}}
pages/@Benchmarking Machine Learning Solutions in Production.md
+23
View File
@@ -0,0 +1,23 @@
tags:: [[#readingnotes]]
date:: 12/2020
publisher:: IEEE
place:: "Miami, FL, USA"
conference-name:: 2020 19th IEEE International Conference on Machine Learning and Applications (ICMLA)
proceedings-title:: 2020 19th IEEE International Conference on Machine Learning and Applications (ICMLA)
isbn:: 978-1-72818-470-8
doi:: 10.1109/ICMLA51294.2020.00104
title:: @Benchmarking Machine Learning Solutions in Production
pages:: 626-633
item-type:: [[ConferencePaper]]
access-date:: 2023-04-25T15:45:14Z
original-title:: Benchmarking Machine Learning Solutions in Production
url:: https://ieeexplore.ieee.org/document/9356298/
authors:: [[Lucas Cardoso Silva]], [[Fernando Rezende Zagatti]], [[Bruno Silva Sette]], [[Lucas Nildaimon Dos Santos Silva]], [[Daniel Lucredio]], [[Diego Furtado Silva]], [[Helena De Medeiros Caseli]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/GRX3SXPG), [Web library](https://www.zotero.org/users/1039502/items/GRX3SXPG)
- [[Attachments]]
- [Cardoso Silva et al_2020_Benchmarking Machine Learning Solutions in Production.pdf](zotero://select/library/items/3MB7DRV3) {{zotero-imported-file 3MB7DRV3, "Cardoso Silva et al_2020_Benchmarking Machine Learning Solutions in Production.pdf"}}
- [[Highlights]]
- ((6447f5fb-1e12-4e25-b9d4-54e8d188ba81))
-
pages/@Berkhin2006.md
+13
View File
@@ -0,0 +1,13 @@
tags:: [[duplicate-citation-key]], [[readingnotes]]
date:: 2019
title:: @Berkhin2006
pages:: 25-71
volume:: 7
item-type:: [[magazineArticle]]
original-title:: A software exoskeleton to protect and support citizen's ethics and privacy in the digital world
url:: https://ieeexplore.ieee.org/document/8712524/
publication-title:: Grouping multidimensional data: Recent advances in clustering
authors:: [[Marco Autili]], [[Davide Di Ruscio]], [[Paola Inverardi]], [[Patrizio Pelliccione]], [[Massimo Tivoli]]
links:: [Local library](zotero://select/library/items/2U9TKR52), [Web library](https://www.zotero.org/users/1039502/items/2U9TKR52)
-
pages/@Big Data Pipelines on the Computing Continuum%3A Ecosystem and Use Cases Overview.md
+58
View File
@@ -0,0 +1,58 @@
tags:: [[readingnotes]]
date:: [[05-09-2021]]
publisher:: IEEE
place:: "Athens, Greece"
conference-name:: 2021 IEEE Symposium on Computers and Communications (ISCC)
proceedings-title:: 2021 IEEE Symposium on Computers and Communications (ISCC)
isbn:: 978-1-66542-744-9
doi:: 10.1109/ISCC53001.2021.9631410
title:: @Big Data Pipelines on the Computing Continuum: Ecosystem and Use Cases Overview
pages:: 1-4
item-type:: [[ConferencePaper]]
access-date:: 2023-01-17T09:22:48Z
original-title:: Big Data Pipelines on the Computing Continuum: Ecosystem and Use Cases Overview
language:: en
url:: https://ieeexplore.ieee.org/document/9631410/
short-title:: Big Data Pipelines on the Computing Continuum
authors:: [[Dumitru Roman]], [[Nikolay Nikolov]], [[Ahmet Soylu]], [[Brian Elvesaeter]], [[Hui Song]], [[Radu Prodan]], [[Dragi Kimovski]], [[Andrea Marrella]], [[Francesco Leotta]], [[Mihhail Matskin]], [[Giannis Ledakis]], [[Konstantinos Theodosiou]], [[Anthony Simonet-Boulogne]], [[Fernando Perales]], [[Evgeny Kharlamov]], [[Alexandre Ulisses]], [[Arnor Solberg]], [[Raffaele Ceccarelli]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/GR5MNWMN), [Web library](https://www.zotero.org/users/1039502/items/GR5MNWMN)
- [[Abstract]]
- Organisations possess and continuously generate huge amounts of static and stream data, especially with the proliferation of Internet of Things technologies. Collected but unused data, i.e., Dark Data, mean loss in value creation potential. In this respect, the concept of Computing Continuum extends the traditional more centralised Cloud Computing paradigm with Fog and Edge Computing in order to ensure low latency pre-processing and filtering close to the data sources. However, there are still major challenges to be addressed, in particular related to management of various phases of Big Data processing on the Computing Continuum. In this paper, we set forth an ecosystem for Big Data pipelines in the Computing Continuum and introduce five relevant real-life example use cases in the context of the proposed ecosystem.
- [[Attachments]]
- [Roman et al. - 2021 - Big Data Pipelines on the Computing Continuum Eco.pdf](https://oda.oslomet.no/oda-xmlui/bitstream/handle/11250/2986343/DataCloud_DistInSys2021.pdf?sequence=4&isAllowed=y) {{zotero-imported-file TVIRF2SK, "Roman et al. - 2021 - Big Data Pipelines on the Computing Continuum Eco.pdf"}}
- [[Highlights]] [[PROJECTS/PODIUM]]
- ((63c66be1-9c35-4c36-afcb-e8cde7371892))
- ((63c676b9-3c80-453e-8e82-888a24d62550))
- ((63c677a1-f70a-45e8-a2bd-7915bf68a9e5))
- [[@The rise of serverless computing]]
- **Pipeline at**
- **DESIGN-TIME**: ((63c6a293-9c12-4bb2-a9f1-8a74cbfd15c2))
- **RUN-TIME**: ((63c6a2c1-766b-4738-8569-cdf9613db539))
- [[question]] Is it possible to change the deploymend at run-time depending on the characteristis of the input data?
- ((63c6a527-ff3b-4b40-801c-8987d9f17400)) [[New Motivations]]
- ((63c6a57c-4b14-4a25-9bc9-3e49467e37c1)) [[New Motivations]]
- ((63c6a5be-1031-4248-8a92-5c52da5182f4)) [[New Motivations]]
- ((63c6a81d-8ab4-4044-8313-8213b8248625)) [[New Motivations]]
- ((63c6a855-718c-47b7-b5ed-92c8f647615d))
- [[question]] What kind of intelligent resource management do they employ?
- ((63c6a95e-4e60-47b3-a529-23ca0f4ee525))
- ((63c6a98a-46f9-4642-9c5d-ff1dc1ccf7a8)) [[New Motivations]] **Very good example.**
- ((63c6abbb-f2be-4c69-aa2c-9bae5f2281e9))
-
- **STAKEHOLDERS** covered by the project:
- Data Providers
- Business domain experts
- Data scientists
- Resource providers
- DataOps operators
- Data consumers
- **[[PIPELINE LIFECYCLE]]** supported by the project:
- Pipeline discovery
- Pipeline definition
- Pipeline simulation
- Resource provisioning
- Pipeline deployment
- Pipeline adaptations
-
pages/@CEPEDALoCo%3A An event-driven architecture for integrating Complex Event Processing and blockchain through low-code.md
+17
View File
@@ -0,0 +1,17 @@
-
- date:: [[01-05-2023]]
doi:: 10.1016/j.iot.2023.100802
title:: @CEPEDALoCo: An event-driven architecture for integrating Complex Event Processing and blockchain through low-code
pages:: 100802
volume:: 22
item-type:: [[journalArticle]]
original-title:: CEPEDALoCo: An event-driven architecture for integrating Complex Event Processing and blockchain through low-code
short-title:: CEPEDALoCo
publication-title:: Internet of Things
journal-abbreviation:: Internet of Things
authors:: [[Jesús Rosa-Bilbao]], [[Juan Boubeta-Puig]], [[Adrian Rutle]]
library-catalog:: ResearchGate
links:: [Local library](zotero://select/library/items/6SG8JQ8J), [Web library](https://www.zotero.org/users/1039502/items/6SG8JQ8J)
- [[Attachments]]
- [Rosa-Bilbao et al_2023_CEPEDALoCo.pdf](https://www.researchgate.net/profile/Jesus-Rosa-Bilbao/publication/370477600_CEPEDALoCo_An_event-driven_architecture_for_integrating_Complex_Event_Processing_and_blockchain_through_low-code/links/645a22804af78873526a9944/CEPEDALoCo-An-event-driven-architecture-for-integrating-Complex-Event-Processing-and-blockchain-through-low-code.pdf) {{zotero-imported-file E8N8I7HH, "Rosa-Bilbao et al_2023_CEPEDALoCo.pdf"}}
- [ResearchGate Link](https://www.researchgate.net/profile/Jesus-Rosa-Bilbao/publication/370477600_CEPEDALoCo_An_event-driven_architecture_for_integrating_Complex_Event_Processing_and_blockchain_through_low-code/links/645a22804af78873526a9944/CEPEDALoCo-An-event-driven-architecture-for-integrating-Complex-Event-Processing-and-blockchain-through-low-code.pdf)
pages/@COLA-D-24-00156.PDF.md
+9
View File
@@ -0,0 +1,9 @@
tags:: [[#zotero]]
title:: @COLA-D-24-00156.PDF
item-type:: [[document]]
original-title:: COLA-D-24-00156.PDF
language:: en
links:: [Local library](zotero://select/library/items/VLJ6RUW2), [Web library](https://www.zotero.org/users/1039502/items/VLJ6RUW2)
- ### Attachments
- [PDF](zotero://select/library/items/BT72DCNF) {{zotero-imported-file BT72DCNF, "Cola-d-24-00156.pdf"}}
pages/@Can ChatGPT Reproduce Human-Generated Labels - A Study of Social Computing Tasks.md
+12
View File
@@ -0,0 +1,12 @@
links:: [Local library](zotero://select/library/items/U6SSJ8YM), [Web library](https://www.zotero.org/users/1039502/items/U6SSJ8YM)
authors:: [[Yiming Zhu]], [[Peixian Zhang]], [[Ehsan-Ul Haq]], [[Pan Hui]], [[Gareth Tyson]]
tags:: [[Computer Science - Artificial Intelligence]], [[Computer Science - Computation and Language]], [[readingnotes]]
date:: [[20-04-2023]]
item-type:: [[preprint]]
title:: @Can ChatGPT Reproduce Human-Generated Labels - A Study of Social Computing Tasks
- [[Abstract]]
- The release of ChatGPT has uncovered a range of possibilities whereby large language models (LLMs) can substitute human intelligence. In this paper, we seek to understand whether ChatGPT has the potential to reproduce human-generated label annotations in social computing tasks. Such an achievement could significantly reduce the cost and complexity of social computing research. As such, we use ChatGPT to re-label five seminal datasets covering stance detection (2x), sentiment analysis, hate speech, and bot detection. Our results highlight that ChatGPT does have the potential to handle these data annotation tasks, although a number of challenges remain. ChatGPT obtains an average precision 0.609. Performance is highest for the sentiment analysis dataset, with ChatGPT correctly annotating 64.9% of tweets. Yet, we show that performance varies substantially across individual labels. We believe this work can open up new lines of analysis and act as a basis for future research into the exploitation of ChatGPT for human annotation tasks.
- [[Attachments]]
- [arXiv.org Snapshot](https://arxiv.org/abs/2304.10145) {{zotero-imported-file W8RRXH59, "2304.html"}}
- [Zhu et al_2023_Can ChatGPT Reproduce Human-Generated Labels.pdf](https://arxiv.org/pdf/2304.10145.pdf) {{zotero-imported-file YX5QGHEF, "Zhu et al_2023_Can ChatGPT Reproduce Human-Generated Labels.pdf"}}
pages/@Can ChatGPT Reproduce Human-Generated Labels%3F A Study of Social Computing Tasks.md
+13
View File
@@ -0,0 +1,13 @@
links:: [Local library](zotero://select/library/items/U6SSJ8YM), [Web library](https://www.zotero.org/users/1039502/items/U6SSJ8YM)
authors:: [[Yiming Zhu]], [[Peixian Zhang]], [[Ehsan-Ul Haq]], [[Pan Hui]], [[Gareth Tyson]]
tags:: [[Computer Science - Artificial Intelligence]], [[Computer Science - Computation and Language]], [[#zotero]]
date:: [[20-04-2023]]
item-type:: [[preprint]]
title:: @Can ChatGPT Reproduce Human-Generated Labels? A Study of Social Computing Tasks
-
- [[Abstract]]
- The release of ChatGPT has uncovered a range of possibilities whereby large language models (LLMs) can substitute human intelligence. In this paper, we seek to understand whether ChatGPT has the potential to reproduce human-generated label annotations in social computing tasks. Such an achievement could significantly reduce the cost and complexity of social computing research. As such, we use ChatGPT to re-label five seminal datasets covering stance detection (2x), sentiment analysis, hate speech, and bot detection. Our results highlight that ChatGPT does have the potential to handle these data annotation tasks, although a number of challenges remain. ChatGPT obtains an average precision 0.609. Performance is highest for the sentiment analysis dataset, with ChatGPT correctly annotating 64.9% of tweets. Yet, we show that performance varies substantially across individual labels. We believe this work can open up new lines of analysis and act as a basis for future research into the exploitation of ChatGPT for human annotation tasks.
- [[Attachments]]
- [arXiv.org Snapshot](https://arxiv.org/abs/2304.10145) {{zotero-imported-file W8RRXH59, "2304.html"}}
- [Zhu et al_2023_Can ChatGPT Reproduce Human-Generated Labels.pdf](https://arxiv.org/pdf/2304.10145.pdf) {{zotero-imported-file YX5QGHEF, "Zhu et al_2023_Can ChatGPT Reproduce Human-Generated Labels.pdf"}}
pages/@Characteristics and Challenges of Low-Code Development%3A The Practitioners' Perspective.md
+21
View File
@@ -0,0 +1,21 @@
date:: [[11-10-2021]]
publisher:: ACM
place:: Bari Italy
conference-name:: ESEM '21: ACM / IEEE International Symposium on Empirical Software Engineering and Measurement
proceedings-title:: Proceedings of the 15th ACM / IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)
isbn:: 978-1-4503-8665-4
doi:: 10.1145/3475716.3475782
title:: @Characteristics and Challenges of Low-Code Development: The Practitioners' Perspective
pages:: 1-11
item-type:: [[ConferencePaper]]
access-date:: 2023-05-17T09:22:46Z
original-title:: Characteristics and Challenges of Low-Code Development: The Practitioners' Perspective
language:: en
url:: https://dl.acm.org/doi/10.1145/3475716.3475782
short-title:: Characteristics and Challenges of Low-Code Development
authors:: [[Yajing Luo]], [[Peng Liang]], [[Chong Wang]], [[Mojtaba Shahin]], [[Jing Zhan]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/EBNKRJC5), [Web library](https://www.zotero.org/users/1039502/items/EBNKRJC5)
- [[Attachments]]
- [Luo et al. - 2021 - Characteristics and Challenges of Low-Code Develop.pdf](zotero://select/library/items/TL56IGYJ) {{zotero-imported-file TL56IGYJ, "Luo et al. - 2021 - Characteristics and Challenges of Low-Code Develop.pdf"}}
pages/@ChatGPT in software modeling.md
+34
View File
@@ -0,0 +1,34 @@
tags:: [[#zotero]]
date:: [[11-05-2023]]
issn:: "1619-1366, 1619-1374"
doi:: 10.1007/s10270-023-01106-4
title:: @ChatGPT in software modeling
pages:: s10270-023-01106-4
item-type:: [[journalArticle]]
access-date:: 2023-05-16T11:37:30Z
original-title:: ChatGPT in software modeling
language:: en
url:: https://link.springer.com/10.1007/s10270-023-01106-4
publication-title:: Software and Systems Modeling
journal-abbreviation:: Softw Syst Model
authors:: [[Benoit Combemale]], [[Jeff Gray]], [[Bernhard Rumpe]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/AIPH9AXG), [Web library](https://www.zotero.org/users/1039502/items/AIPH9AXG)
- ![Combemale et al_2023_ChatGPT in software modeling.pdf](../assets/Combemale_et_al_2023_ChatGPT_in_software_modeling_1705998816068_0.pdf)
- ((65af7b99-3ba1-4625-b805-414bcc932e61))
- ((65af7bb5-c411-4791-9b9f-08eaee9a70c6))
- ((65af7c0b-8050-4c56-ae40-15f213763e98))
- ((65af7bd4-d1da-437c-b45b-1604f6b08809))
- ((65af7c56-1d49-46fe-aeb4-a714b24a1d61))
- ((65af7c64-f09a-4691-8f2f-0054383e7b6b))
- ((65af7d26-e77c-4861-ae47-72e65e3aee27))
- ((65af7d5c-3995-4e41-8619-31dc4ecc29af))
- LACK OF THE CREATIVE ELEMENT!!!
- ((65af7d78-d5f0-4a65-8cf1-6e792b58309f))
- ((65af7dac-da46-4fda-83a0-54ef3c21eb90))
-
-
-
-
-
pages/@Collaborative Model-Driven Software Engineering%3A A Classification Framework and a Research Map.md
+25
View File
@@ -0,0 +1,25 @@
links:: [Local library](zotero://select/library/items/HMR5QHZ3), [Web library](https://www.zotero.org/users/1039502/items/HMR5QHZ3)
library-catalog:: DOI.org (Crossref)
authors:: Mirco Franzago, Davide Di Ruscio, Ivano Malavolta, Henry Muccini
journal-abbreviation:: IIEEE Trans. Software Eng.
publication-title:: IEEE Transactions on Software Engineering
short-title:: Collaborative Model-Driven Software Engineering
url:: https://ieeexplore.ieee.org/document/8047991/
language:: en
original-title:: Collaborative Model-Driven Software Engineering: A Classification Framework and a Research Map
access-date:: 2022-09-08T16:21:53Z
item-type:: [[journalArticle]]
volume:: 44
pages:: 1146-1175
title:: @Collaborative Model-Driven Software Engineering: A Classification Framework and a Research Map
doi:: 10.1109/TSE.2017.2755039
issue:: 12
issn:: "0098-5589, 1939-3520, 2326-3881"
date:: [[01-12-2018]]
tags:: #Highlights
- [[Abstract]]
- Context: Collaborative Model-Driven Software Engineering (MDSE) consists of methods and techniques where multiple stakeholders manage, collaborate, and are aware of each others’ work on shared models. Objective: Collaborative MDSE is attracting research efforts from different areas, resulting in a variegated scientific body of knowledge. This study aims at identifying, classifying, and understanding existing collaborative MDSE approaches. Method: We designed and conducted a systematic mapping study. Starting from over 3,000 potentially relevant studies, we applied a rigorous selection procedure resulting in 106 selected papers, further clustered into 48 primary studies along a time span of 19 years. We rigorously defined and applied a classification framework and extracted key information from each selected study for subsequent analysis. Results: Our analysis revealed the following main fidings: (i) there is a growing scientific interest on collaborative MDSE in the last years; (ii) multi-view modeling, validation support, reuse, and branching are more rarely covered with respect to other aspects about collaborative MDSE; (iii) different primary studies focus differently on individual dimensions of collaborative MDSE (i.e., model management, collaboration, and communication); (iv) most approaches are language-specific, with a prominence of UML-based approaches; (v) few approaches support the interplay between synchronous and asynchronous collaboration. Conclusion: This study gives a solid foundation for classifying existing and future approaches for collaborative MDSE. Researchers and practitioners can use our results for identifying existing research/technical gaps to attack, better scoping their own contributions, or understanding existing ones.
- [[Attachments]]
- [Franzago et al. - 2018 - Collaborative Model-Driven Software Engineering A.pdf](zotero://select/library/items/FDGY7LII) {{zotero-imported-file FDGY7LII, "Franzago et al. - 2018 - Collaborative Model-Driven Software Engineering A.pdf"}}
-
pages/@Comparing the efficiency of semantic code clones.md
+158
View File
@@ -0,0 +1,158 @@
tags:: [[#zotero]]
date:: 2017
title:: @Comparing the efficiency of semantic code clones
item-type:: [[journalArticle]]
original-title:: Comparing the efficiency of semantic code clones
language:: en
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/KGWIP4TS), [Web library](https://www.zotero.org/users/1039502/items/KGWIP4TS)
- [[Abstract]]
- Two programs are said to be semantic code clones if they produce the same output for all inputs. But there is far more to code than its semantics; for instance a pair of semantic code clones can have more or fewer vulnerabilities, can be more or less readable, or can be more or less efficient with respect to run time, memory usage, etc. In this paper, we propose a framework and approach to systematically and automatically compare the efficiency of such semantic code clones. Our approach distills program inputs into multiple numeric input properties, leverages statistical and numerical methods to model and analyze the relationships between these inputs and various efficiency metrics related to program execution, and finally reports the best performing clones w.r.t. all efficiency metrics on the studied ranges of property values, as well as the models and visualizations of efficiency as it relates to the input properties. We implement this approach in a tool called PMA (for Property/Metric Analyzer), with support for programs written in Python, JavaScript, Rust, and R, and evaluate PMA in 8 subject areas, showing that PMA generates useful and sometimes surprising insights about semantic code clones across many languages and applications; insights that we believe developers could leverage to better understand and improve the efficiency of their applications.
- ### Attachments
- [PDF](zotero://select/library/items/MFEDET3D) {{zotero-imported-file MFEDET3D, "2017 - Comparing the efficiency of semantic code clones.pdf"}}
- ### Notes
collapsed:: true
- I'm reviewing a research paper and I took the following notes:
# Annotazioni
(17/5/2025, 10:05:19)
- “Two programs are said to be semantic code clones if they produce the same output for all inputs.” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #5fb236
- “In this paper, we propose a framework and approach to systematically and automatically compare the efficiency of such semantic code clones.” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #5fb236
- “Our approach distills program inputs into multiple numeric input properties, leverages statistical and numerical methods to model and analyze the relationships between these inputs and various efficiency metrics related to program execution, and finally reports the best performing clones w.r.t. all efficiency metrics on the studied ranges of property values, as well as the models and visualizations of efficiency as it relates to the input properties” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #5fb236
- “PMA (for Property/Metric Analyzer)” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #5fb236
- “Two programs are said to be semantic code clones if they produce the same output for all inputs, and semantic code clones are everywhere.” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #5fb236
- “These kinds of clones appear frequently in the context of differential testing, a strategy to test some program P by also executing other, semantically-equivalent programs, e.g., P′, with the same inputs as P and using the other executions as oracles.” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #5fb236
- “if for some input i, P (i) crashes but P′ (i) does not, there is probably an issue with P.” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #ffd400
*or the other way round.... the issue might be with P' and not with P*
- “in this work we present an approach that automatically and systematically compares the efficiency of semantic code clones by exercising them with the same inputs and observing efficiency metrics related to execution.” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #a28ae5
- “the approach can automatically generate inputs and distills them into multiple numeric input properties in order to relate them to the collected efficiency metrics.” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #a28ae5
- “our approach can leverage statistical and numerical methods to build, analyze, and compare models of program efficiency, and we develop novel modeling and analysis techniques that account for the probabilistic nature of recording the efficiency of code.” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #a28ae5
- “PMA (for Property/Metric Analyzer), and evaluate it on 20 subject applications spanning eight application areas and four programming languages.” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #a28ae5
- “PMA can discover which input properties contribute to efficiency and which do not, and find which application is most efficient on which ranges of input property values, as well as overall.” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #5fb236
- “an approach for profiling and analyzing the efficiency of semantic code clones, w.r.t. several properties of inputs;” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #2ea8e5
- “a prototype implementation of this approach in a tool called PMA,” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #2ea8e5
- “evaluation where we applied PMA in various domains” (“Comparing the efficiency of semantic code clones”, 2017, p. 1) #2ea8e5
- “quicksort, mergesort” (“Comparing the efficiency of semantic code clones”, 2017, p. 2) #5fb236
- “bubblesort, and insertionsort” (“Comparing the efficiency of semantic code clones”, 2017, p. 2) #5fb236
- “there’s quite a bit of variability in both runtime and memory consumed for lists of the same length, which implies that another property of the input lists may be playing a role in the efficiency of the algorithms;” (“Comparing the efficiency of semantic code clones”, 2017, p. 2) #5fb236
- “sortedness”, which we compute as the % of adjacent elements in the list that are out of order.” (“Comparing the efficiency of semantic code clones”, 2017, p. 2) #5fb236
- “considering sortedness explains the anomalous extremely high run time and peak memory values for quicksort:” (“Comparing the efficiency of semantic code clones”, 2017, p. 2) #ffd400
*I appreciate the effort of producing Fig. 1b. However, it is not clear for some of the situations. For instance, quicksort is not visible for sotedness values <0.8 Thus the message that authrors want to convey at the end of Sec 2.2 is not fully clear.*
- “At its core, our approach aims to investigate the relationship between inputs and various efficiency metrics related to program execution” (“Comparing the efficiency of semantic code clones”, 2017, p. 2) #a28ae5
- “computing numeric properties of inputs” (“Comparing the efficiency of semantic code clones”, 2017, p. 2) #5fb236
- “Input Properties.” (“Comparing the efficiency of semantic code clones”, 2017, p. 2) #2ea8e5
- “In the sorting example, these are the length of the input list, as well as the % of adjacent pairs of elements in the list that are out-of-order; length is a default property, and the latter is a custom property. Our approach also makes the distinction between primary and other input properties; by default the primary input property is the first supplied by the user, and forms the basis of the initial exploratory data analysis which will, among other things, determine which other properties are significant predictors of efficiency.” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #ffd400
*These properties are very specific to the program at hand. Who is going to define them? Still not clear at this stage the automation level of the proposed approach.*
- “Efficiency Metrics.” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #2ea8e5
- “during the execution of a program.” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #5fb236
- “observing with some observer M the execution of a program S on some inputs i0, ..., in, i.e., M (S (i0, ..., in)) = m” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #5fb236
- “profile the programs under test S0, ..., Sk , collecting various metrics m0, ..., m j by observing them during program execution” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #5fb236
- “every input” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #ffd400
*Every input needs to be further elaborated! Every is strong.*
- “Profiling produces a summary containing b entries for each of the k programs, and each entry contains the values of all r input properties and j metrics. This summary serves as the basis for all future analysis steps, which are discussed next.” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #5fb236
- “to identify and discard true clones, which we define as clones with identical observable semantics and observable efficiency” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #ffd400
*Why discard?*
- “statistically significant differences between the programs for each metric.” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #5fb236
- “t x1 ∈ X1 will be greater than an element x2 ∈ X2” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #5fb236
- “hen the programs are determined to be equivalent and one of the clones is discarded at random.” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #ffd400
*Why is it discarded? It's not clear the discarding phase with respect to the overall goal of the approach as presented in the introduction "....compares the efficiency of semantic code clones...."*
- “In this stage, the analysis determines and reports all significant differences between the remaining “false clones”.” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #ffd400
*Now it becoming a bit clear. So essentially during the profiling phase you aim at removing all the programs that according to the £detect true clones" phase are confirmed to be clones. This needs to be clearly stated. Why do you need to do so? It is necessary to introduce early in Section 3 a figure depicting all the phases of the proposed approach so that the reader can have a high level view of the approach and better follow the details.*
- “3.3.1 Relative Efficiency Analysis.” (“Comparing the efficiency of semantic code clones”, 2017, p. 3) #2ea8e5
- “in Section 2 we find the turning range where insertionsort and mergesort are equally efficient is [108, 140], while [0, 108] is optimal for insertionsort and [140, 500] is optimal for mergesort.” (“Comparing the efficiency of semantic code clones”, 2017, p. 4) #5fb236
- “3.3.2 Anomaly Investigation.” (“Comparing the efficiency of semantic code clones”, 2017, p. 4) #2ea8e5
- “20 subject applications across eight subject areas spanning four programming languages.” (“Comparing the efficiency of semantic code clones”, 2017, p. 5) #5fb236
- “Setup. We aim to find the optimal list length at which to switch between quicksort and insertion sort, and see if the developers were correct in setting it to 20.” (“Comparing the efficiency of semantic code clones”, 2017, p. 5) #ffd400
- “For our input properties, we chose the length of the list, since this is the metric over which the sorting algorithm switch threshold is computed, and also sortedness (recall that sortedness referes to the % of adjacent elements that are in order).” (“Comparing the efficiency of semantic code clones”, 2017, p. 5) #ffd400
*I'm not convinced about the generalizability of the work. Moreover, the paper is related to many works on non-functional aspects of software systems, including performance analysis that are completely neglected in the paper. The focus of the paper is not clear. In the end it seems that the work is on supporting the analysis of alternative implementations of similar tasks with respect to efficiency criteria. Programs under analysis that are supposed to be clones, might be not and the different on performance might due on several aspects that might go beyond the given input and on characteristics that might even be related to the execution environment.*
- “It is possible that our evaluation is not representative of real-world scenarios.” (“Comparing the efficiency of semantic code clones”, 2017, p. 9) #ffd400
*Exactly. See my previous comment.*
- “Efficiency metrics are tied to the system on which a program is being run, and so it is possible that running our evaluation on a different system would yield different results.” (“Comparing the efficiency of semantic code clones”, 2017, p. 9) #ffd400
*This is also related to my previous points. In my opinion the considered settings for comparison makes semplifications that need to be convincingly supported!*
- “The approach proposed in this paper automatically builds and analyzes performance profiles of the programs under test, closely related to profiling” (“Comparing the efficiency of semantic code clones”, 2017, p. 10) #ffd400
*There is no comparison of the proposed approach with existing profiling mechanisms and tools.*
- “In contrast, our approach systematically compares multiple equivalent implementations of a function or system, rather than focusing only on one, and incorporates multiple input properties in its analysis.” (“Comparing the efficiency of semantic code clones”, 2017, p. 10) #ffd400
*This is said in the related work and claimed to highlight the difference with respect to existing work. This is not convincing in my opinion. First of all because the definition of code clones is blurred in my opinion. There are theoretical limitation on identifying clones. The proposed approach is kind of approximation, and as a such it is necessary to consider potential errors while discussing the subsequent phases of the process that rely on such approximations.*
- “Typically, these tools are complex to use, in contrast to our approach. Their goal is also complementary as they are designed to operate at a huge scale; in contrast, our method can be applied at a small scale” (“Comparing the efficiency of semantic code clones”, 2017, p. 10) #ffd400
*This is also a claim in the related work section. This is a critical point for comparison. To make the paper strong it is required to demonstrate that the proposed approach is on the one hand easier than existing approaches and on the other hand demonstrate that existing tools cannot be operated at small scale.*
- “we proposed a novel automated profiling and analysis approach that leverages multiple input properties and models and analyzes their relationship with efficiency metrics related to the execution of multiple semantically equivalent programs” (“Comparing the efficiency of semantic code clones”, 2017, p. 10) #5fb236
- “With this approach, developers can compare functionally-equivalent programs in a single framework, visually examine the relative effects of multiple input properties on a given efficiency metric, and automated statistical and numerical analysis determines optimal ranges for programs and builds multi-dimensional models of efficiency.” (“Comparing the efficiency of semantic code clones”, 2017, p. 10) #5fb236
- “we implemented our approach in a tool called PMA, and evaluated its ability to discern efficiency differences in eight subject areas across four programming languages.” (“Comparing the efficiency of semantic code clones”, 2017, p. 10) #5fb236
COnsider that those that are tagget with #5fb236 are just highlights, those that are tagged with #e56eee and #a28ae5 are imporant 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 sentence to summarize the work
STRENGHTS:
WEAKNESSES:
COMMENTS: Organize the notes with respect to the following criteria:
-
`Novelty`
-
`Rigor`
-
`Relevance (of the contribution)`
-
`Verifiability and Transparency`
-
`Presentation`
And then add a Detailed Comments section to report the notes that contain issues or typos.
Can you also formulate three explicit questions by considering the comments above?
pages/@Computing in the Continuum%3A Combining Pervasive Devices and Services to Support Data-Driven Applications.md
+24
View File
@@ -0,0 +1,24 @@
tags:: [[readingnotes]]
date:: 6/2017
publisher:: IEEE
place:: "Atlanta, GA, USA"
conference-name:: 2017 IEEE 37th International Conference on Distributed Computing Systems (ICDCS)
proceedings-title:: 2017 IEEE 37th International Conference on Distributed Computing Systems (ICDCS)
isbn:: 978-1-5386-1792-2
doi:: 10.1109/ICDCS.2017.323
title:: @Computing in the Continuum: Combining Pervasive Devices and Services to Support Data-Driven Applications
pages:: 1815-1824
item-type:: [[ConferencePaper]]
access-date:: 2023-01-07T18:27:02Z
original-title:: Computing in the Continuum: Combining Pervasive Devices and Services to Support Data-Driven Applications
url:: http://ieeexplore.ieee.org/document/7980120/
short-title:: Computing in the Continuum
authors:: [[Moustafa AbdelBaky]], [[Mengsong Zou]], [[Ali Reza Zamani]], [[Eduard Renart]], [[Javier Diaz-Montes]], [[Manish Parashar]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/DAU2LU9E), [Web library](https://www.zotero.org/users/1039502/items/DAU2LU9E)
- [[Attachments]]
- [AbdelBaky et al_2017_Computing in the Continuum.pdf](zotero://select/library/items/33BF2A43) {{zotero-imported-file 33BF2A43, "AbdelBaky et al_2017_Computing in the Continuum.pdf"}}
- [[Highlights]]
- ((63bbd10d-e68c-4ede-947f-524e8ec9ad98))
-
pages/@Conceptualization and scalable execution of big data workflows using domain-specific languages and software containers.md
+37
View File
@@ -0,0 +1,37 @@
tags:: [[readingnotes]]
date:: 12/2021
issn:: 25426605
doi:: 10.1016/j.iot.2021.100440
title:: @Conceptualization and scalable execution of big data workflows using domain-specific languages and software containers
pages:: 100440
volume:: 16
item-type:: [[journalArticle]]
access-date:: 2023-01-18T12:07:58Z
original-title:: Conceptualization and scalable execution of big data workflows using domain-specific languages and software containers
language:: en
url:: https://linkinghub.elsevier.com/retrieve/pii/S2542660521000834
publication-title:: Internet of Things
journal-abbreviation:: Internet of Things
authors:: [[Nikolay Nikolov]], [[Yared Dejene Dessalk]], [[Akif Quddus Khan]], [[Ahmet Soylu]], [[Mihhail Matskin]], [[Amir H. Payberah]], [[Dumitru Roman]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/9WPJ3Y5N), [Web library](https://www.zotero.org/users/1039502/items/9WPJ3Y5N)
- [[Abstract]]
- Big Data processing, especially with the increasing proliferation of Internet of Things (IoT) technologies and convergence of IoT, edge and cloud computing technologies, involves handling massive and complex data sets on heterogeneous resources and incorporating different tools, frameworks, and processes to help organizations make sense of their data collected from various sources. This set of operations, referred to as Big Data workflows, requires taking advantage of Cloud infrastructures’ elasticity for scalability. In this article, we present the design and prototype implementation of a Big Data workflow approach based on the use of software container technologies, message-oriented middleware (MOM), and a domain-specific language (DSL) to enable highly scalable workflow execution and abstract workflow definition. We demonstrate our system in a use case and a set of experiments that show the practical applicability of the proposed approach for the specification and scalable execution of Big Data workflows. Furthermore, we compare our proposed approach’s scalability with that of Argo Workflows – one of the most prominent tools in the area of Big Data workflows – and provide a qualitative evaluation of the proposed DSL and overall approach with respect to the existing literature.
- [[Attachments]]
- [Nikolov et al. - 2021 - Conceptualization and scalable execution of big da.pdf](zotero://select/library/items/QYUBVQAD) {{zotero-imported-file QYUBVQAD, "Nikolov et al. - 2021 - Conceptualization and scalable execution of big da.pdf"}}
- [[Highlights]]
- ((63c906c7-b466-43a5-b10f-60888e50c43b))
- ((63c9067a-740c-4655-87e3-5b3bd74dac41))
- ((63c906ee-8b20-4a86-977d-ae6227effaa5)) [[New Motivations]]
- ((63c9073e-b5ea-489d-a7c7-073fc7f42ade)) [[New Motivations]]
- ((63c90746-161a-4dff-a651-0e37cd1bdd6d)) [[New Motivations]]
- ((63c913c2-8cb1-4b36-8a39-9d871c440104)) [[New Motivations]]
- ((63c91a5f-d65f-4093-bd68-857ebf016a2d)) [[New Motivations]]
- ((63c91ab8-3355-4a4b-bb07-0833b5c5f506))
- **GOAL OF THE APPROACH**
- ((63c913e1-53f6-4423-a3a1-2c73281aeed6))
- ((63c913e6-9a90-4d8b-a6a6-6094b67725ca))
- ((63c91848-d3d0-47cb-93e2-61070479dc67))
- We could be container technology independent? (aka TYPHONDL???)
- ((63ca5656-a823-48d9-a94a-b150c12863fe))
pages/@Dandelion%3A A scalable, cloud-based graphical language workbench for industrial low-code development.md
+22
View File
@@ -0,0 +1,22 @@
date:: 5/2023
issn:: 25901184
doi:: 10.1016/j.cola.2023.101217
title:: @Dandelion: A scalable, cloud-based graphical language workbench for industrial low-code development
pages:: 101217
item-type:: [[journalArticle]]
access-date:: 2023-05-26T07:58:51Z
original-title:: "Dandelion: A scalable, cloud-based graphical language workbench for industrial low-code development"
language:: en
url:: https://linkinghub.elsevier.com/retrieve/pii/S2590118423000278
short-title:: Dandelion
publication-title:: Journal of Computer Languages
journal-abbreviation:: Journal of Computer Languages
authors:: [[Francisco Martínez-Lasaca]], [[Pablo Díez]], [[Esther Guerra]], [[Juan De Lara]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/F28IQLEK), [Web library](https://www.zotero.org/users/1039502/items/F28IQLEK)
-
- [[Abstract]]
- There is an increasing demand nowadays for low-code development platforms (LCDPs). As they rely heavily on graphical languages rather than writing code, these platforms enable citizen developers to participate in software development. However, creating new LCDPs is very costly, since it requires building support for graphical modelling and its integration with services like model validation, recommendation systems, or code generation. While Model-driven Engineering (MDE) has developed technologies to create these components, most of them are not cloud-based, as required by LCDPs. In particular, a cloud-based graphical workbench capable of providing the scalability required by industrial applications and adequately supporting technological heterogeneity is currently missing.
- [[Attachments]]
- [Martínez-Lasaca et al. - 2023 - Dandelion A scalable, cloud-based graphical langu.pdf](https://pdf.sciencedirectassets.com/320563/AIP/1-s2.0-S2590118423000278/main.pdf?X-Amz-Security-Token=IQoJb3JpZ2luX2VjEO%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaCXVzLWVhc3QtMSJIMEYCIQCyAZpo9MBFf5sLyJqqNvU0lqKymlOFgwduQB6xjF1O1QIhAParKq5TXptbHkWm0BtsfbXXNt1HJL%2F4hm%2BCyoBCTf72KrIFCCgQBRoMMDU5MDAzNTQ2ODY1IgxQQoNAsnI9IQ24jJsqjwVlRIyGFSknmSay0CPa8TY2Z9fIHupLBqri9ypwZYa1vstJSoBkaQ7EMbu%2B3gElqKyogKT9%2FHNk6yhpWZmpY%2F%2FG3CdwNy1Rdv1MYexNS2cfJA0Zax%2FXWrouy7XyevGlNZkUzBbhPwDFWMKTUiXB%2FbpAwLMlNNROOEnbgXB3EwzczANW3SEDicvpBXoqgoCOG05fxu5Yv5SyJL9X01Z6KOw5r0bcFSvm1N3n4vmN9IRsAYwQVgRdOCBtX6153h6PoBV6rQWDWiRy%2BZk%2BZMtjJ54Z1ScNwAULoRVgIuIdlxjGXawixcQBmYo4rGuYSFcG0Zs0O5KNLS4dxGGm9f%2BIuDo%2BiqK3keo627fqwC0R6XbMv5CGTpseKZIMzzY8QhUuszrtmFOZvBe38lxLCG78W%2F6MJkLUIpUlb69p2Q%2FHNv6U9SbqfSV5gTLWTQHjvBnWFQs5vA00xRs7sw%2B4zFwHAYnsyt%2FHtDVlKHL1reaAZ0Q9WwVqJ6xXwZNUrF9b3B3CAcp02o9AGYB%2FCGLfD3haqONKenszrwjGzSxKJ8Ds8prYN6AfspNGL7XkPO02nlpShLKJ5hM1MC3c8ERLNiNfCtkKJDBELqEu6vM1thg5Km%2B%2BuUOVyd04NjAotC0mFENrHdZEvtlgthpCyC12YaaWU3CIPY%2B8qSzpJfylKTStLpdd5ADv0KM%2BVij1WeGcywXg1nXYJnrL8e%2Fivg82JRH0D5J%2B76r33dK7DEBUZGmYLCYWmYjpa5ptHVaIi%2F2aXciw5xY3wo6LN7ixu6jdM3ewvYznnj%2FMr30lAva8PtlrnRTpYW14YKgJnIJA9VU01EyA%2F5NwrWz2geBK%2FgTA5W0VMxq2ZUk2vj93wookKPq8CFOFMM%2BswaMGOrABKzsU57HkHWrVf8AF%2BQjAzFOtTm05eN1Zte6Yj7DbIEuNaxAlk3e%2BMbvm19Ej9AK3gg3pnVOSNsWwHsBGyqXQ8dGRUYj1aDafuiGRLHSlQ2K1IvO%2BMimOgUCTwKjUf5RgRNtE%2BYO7Jx6T%2BB3Qx9rpgajzmft4JjURBejF2x3cT9F2x6v%2BcCKlrq92SK2G9p3vGEv3%2BL5i7tG69kh4nLZto8BtiB4ddh1JboFYYOc3r7w%3D&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20230526T075835Z&X-Amz-SignedHeaders=host&X-Amz-Expires=300&X-Amz-Credential=ASIAQ3PHCVTY4YWA7OCD%2F20230526%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=0507f0f2f8d153be5f87fb1e19211bc4adc01b06317f8e70ac4c52bbfbc1574d&hash=81513d4c3cca19f8421e58387d6ad5ab9daf13421b311652af90484204da2df9&host=68042c943591013ac2b2430a89b270f6af2c76d8dfd086a07176afe7c76c2c61&pii=S2590118423000278&tid=spdf-961146d4-82aa-45ba-9325-6dfbc325d16a&sid=90ece2f21f00e2429a090fa013824472b90fgxrqb&type=client&tsoh=d3d3LXNjaWVuY2VkaXJlY3QtY29tLnVuaXZhcS5pZG0ub2NsYy5vcmc%3D&ua=0f1c56040254585a51&rr=7cd4794c99fa0c25&cc=us) {{zotero-imported-file ETGC53JJ, "Martínez-Lasaca et al. - 2023 - Dandelion A scalable, cloud-based graphical langu.pdf"}}
pages/@Data Poisoning in LLMs.md
+11
View File
@@ -0,0 +1,11 @@
tags:: [[#zotero]]
title:: @Data Poisoning in LLMs
item-type:: [[journalArticle]]
original-title:: Data Poisoning in LLMs
language:: en
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/SZ7XFBU7), [Web library](https://www.zotero.org/users/1039502/items/SZ7XFBU7)
-
- ### Attachments
- [Data Poisoning in LLMs.pdf](zotero://select/library/items/AI9H8P3A) {{zotero-imported-file AI9H8P3A, "Data Poisoning in LLMs.pdf"}}
pages/@Data Science and Machine Learning%3A Mathematical and Statistical Methods.md
+21
View File
@@ -0,0 +1,21 @@
date:: [[23-01-2021]]
issn:: "0300-5771, 1464-3685"
issue:: 6
doi:: 10.1093/ije/dyaa111
title:: @Data Science and Machine Learning: Mathematical and Statistical Methods
pages:: 2096-2096
volume:: 49
item-type:: [[journalArticle]]
access-date:: 2023-09-07T14:30:33Z
original-title:: Data Science and Machine Learning: Mathematical and Statistical Methods
language:: en
url:: https://academic.oup.com/ije/article/49/6/2096/5864489
short-title:: Data Science and Machine Learning
publication-title:: International Journal of Epidemiology
authors:: [[Joacim Rocklöv]], [[Albert A Gayle]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/H3QPAZFT), [Web library](https://www.zotero.org/users/1039502/items/H3QPAZFT)
-
- [[Attachments]]
- [Rocklöv e Gayle - 2021 - Data Science and Machine Learning Mathematical an.pdf](zotero://select/library/items/UBBJVB8C) {{zotero-imported-file UBBJVB8C, "Rocklöv e Gayle - 2021 - Data Science and Machine Learning Mathematical an.pdf"}}
pages/@Democratizing artificial intelligence%3A How no-code AI can leverage machine learning operations.md
+21
View File
@@ -0,0 +1,21 @@
date:: 4/2023
issn:: 00076813
doi:: 10.1016/j.bushor.2023.04.003
title:: @Democratizing artificial intelligence: How no-code AI can leverage machine learning operations
pages:: S0007681323000502
item-type:: [[journalArticle]]
access-date:: 2023-05-17T09:30:33Z
original-title:: Democratizing artificial intelligence: How no-code AI can leverage machine learning operations
language:: en
url:: https://linkinghub.elsevier.com/retrieve/pii/S0007681323000502
short-title:: Democratizing artificial intelligence
publication-title:: Business Horizons
journal-abbreviation:: Business Horizons
authors:: [[Leif Sundberg]], [[Jonny Holmström]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/GL2TZIAY), [Web library](https://www.zotero.org/users/1039502/items/GL2TZIAY)
- [[Abstract]]
- Organizations are increasingly seeking to generate value and insights from their data by integrating advances in artificial intelligence (AI) such as machine learning (ML) systems into their operations. However, there are several managerial challenges associated with ML operations (MLOps). In this article we outline three key challenges and discuss how an emerging form of AI platforms – ‘no-code AI’ – may help organizations to address and overcome them. We outline how no-code AI can leverage MLOps by closing the gap between business and technology experts, enabling faster iterations between problems and solutions, and aiding infrastructure management. After outlining important remaining challenges associated with no-code AI and MLOps we propose three managerial Journal Pre-proof recommendations. By doing so, we provide insights into an important novel, emerging phenomenon in AI software and set the stage for further research in the area.
- [[Attachments]]
- [Sundberg e Holmström - 2023 - Democratizing artificial intelligence How no-code.pdf](https://pdf.sciencedirectassets.com/272044/AIP/1-s2.0-S0007681323000502/main.pdf?X-Amz-Security-Token=IQoJb3JpZ2luX2VjEBkaCXVzLWVhc3QtMSJHMEUCIQCFFNdLgNvR6srn5p6hJxuflzJrF%2FbzJQscFhQJ%2FQwSfAIgUuX4ok40%2BJTcaxn9hvflLZPU2w%2FjJwlqRLiPKcTk0BwqsgUIQhAFGgwwNTkwMDM1NDY4NjUiDFtczZ2By2MYpHazcSqPBYX6t9Axoib2KWYGsM%2BWIMKlCxrruCNS3HxGaw0OpEoVMQZ1le46fmJmjDe%2Bd48Tnh8zu6dewAMJUXfesuZS2g%2Bo%2Fvy3IqCQhs%2F9KTDdg71UCr1OSTkQwGcHiKyyV2w73F5ZpeoC2%2Bzq3ZtoPjV6ECa1Rkh9Lk%2BrDvKASW44sEp5sJbeLCaejyU20HGMOF7%2FZv%2Fw%2FNUwMK4hCRTXZkkRNUE0qyiDyxHGJOIQ%2FFHXStjc2Kf9tPAi%2F%2FePFoWePLkdb2GfHAVEUsYoQWhCcYs7WnNRzwSH8PHqBW8jplSXAEx04LoHAUcwNFFGBQBImEhX9M6Fc6JZOfmwA6SS8tBPM3k%2FsL8FltKAZH5LM7wkCRzF4HDQgGvBKHmdB%2FphHF1oiP%2FZ9RZZHDIoYBfc7B9wQMvM8WafedJmD%2FQs0eM9zPXTBZzNLN%2B5rixYbGLnFMtyaon3cc8wBwY3ExgT6OgbfdYC%2FkFUWPf6FlwsQjn9zAIpWG8Em2GpVYbwuFIf0tkVXETSkOO9grJV4473pED0cRPJBrU5FZwrbpTNijJvUO5CDXW8RbItVTefvG%2B1tA67D6jbWcbuIWFCe%2FgSPNpgy6cfIXpRprT8u%2FmWA7I3eXK%2BJg4LG0H2HOO8MRnygINynLtMPtn%2BCgBs01oCOl%2F%2FkBNMtn77HiN8PaXzef7eVkIPzgEQGpWu%2FI9te3jSIg33omWwZn7LFOAZzB4yNtqLeZryocxlrK82l03qH%2BbIR862vz7rjWNZmLKo3I3STMOvvSOlD3z5JyuytqG3Ov1V2YeKcZSfF1o5Z4qUjN0SQhKXgUHGKfMk1f4FQP4Ua7WFgFgG39zSKLA8ZkoIoVzSebwRTOePPachsmbjPF8NN7ow%2B6GSowY6sQHpGKJkgiLFWO6nFbOF%2BgGqL2AXJ0oc9H7e%2ByEbaPYmnccGrS5C1FXlktHuQApixiP5YMOv94xQFRGaia%2FHK98TVWlRL2Aj2Ghuz3JS%2FUC5RriJ2utAocZz2G9cD0FW7njbZGovt%2FfbZnNWFqniqM9D35k%2BNzzSbnJoI2vMEraP71vQRU4TXhmXqv4XkTLVUt7%2FbtQZjJ4%2FjI1F1xdcA%2FaG3euqyrYP2ygRUao%2FuIWQ0aY%3D&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20230517T092953Z&X-Amz-SignedHeaders=host&X-Amz-Expires=300&X-Amz-Credential=ASIAQ3PHCVTY4P2KHNZM%2F20230517%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Signature=7f136e69d6719113a9e59ac323d85651b3c22bc72ed0adb8a8dda7380466d82a&hash=9de78a2d6b56b429e8f7068e2da49b62c7e2d9490537db3064ccffefa0b7db3f&host=68042c943591013ac2b2430a89b270f6af2c76d8dfd086a07176afe7c76c2c61&pii=S0007681323000502&tid=spdf-04d8039d-8a75-4638-8d7b-c86cd13b3856&sid=830aafc790baa4419988e23-37d1ed07dddcgxrqb&type=client&tsoh=d3d3LXNjaWVuY2VkaXJlY3QtY29tLnVuaXZhcS5pZG0ub2NsYy5vcmc%3D&ua=0f1c56045e010b5607&rr=7c8ad6ac89cc0a65&cc=us&chk=1&fr=RR-17) {{zotero-imported-file GCSEEXQP, "Sundberg e Holmström - 2023 - Democratizing artificial intelligence How no-code.pdf"}}
pages/@Democratizing the development of recommender systems by means of low-code platforms.md
+22
View File
@@ -0,0 +1,22 @@
date:: [[16-10-2020]]
publisher:: ACM
place:: Virtual Event Canada
conference-name:: MODELS '20: ACM/IEEE 23rd International Conference on Model Driven Engineering Languages and Systems
proceedings-title:: Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings
isbn:: 978-1-4503-8135-2
doi:: 10.1145/3417990.3420202
title:: @Democratizing the development of recommender systems by means of low-code platforms
pages:: 1-9
item-type:: [[ConferencePaper]]
access-date:: 2023-05-17T09:27:46Z
original-title:: Democratizing the development of recommender systems by means of low-code platforms
language:: en
url:: https://dl.acm.org/doi/10.1145/3417990.3420202
authors:: [[Claudio Di Sipio]], [[Davide Di Ruscio]], [[Phuong T. Nguyen]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/6XPRI6KG), [Web library](https://www.zotero.org/users/1039502/items/6XPRI6KG)
- [[Abstract]]
- In recent years, recommender systems have gained an increasingly crucial role in software engineering. Such systems allow developers to exploit a plethora of reusable artifacts, including source code and documentation, which can support the development activities. However, recommender systems are complex tools that are difficult to personalize or fine-tune if developers want to improve them for increasing the relevance of the retrievable recommendations.
- [[Attachments]]
- [Di Sipio et al. - 2020 - Democratizing the development of recommender syste.pdf](zotero://select/library/items/2KD47JMP) {{zotero-imported-file 2KD47JMP, "Di Sipio et al. - 2020 - Democratizing the development of recommender syste.pdf"}}
pages/@Designing and testing systems of systems%3A From variability models to test cases passing through desirability assessment.md
+30
View File
@@ -0,0 +1,30 @@
links:: [Local library](zotero://select/library/items/KAWWWTUX), [Web library](https://www.zotero.org/users/1039502/items/KAWWWTUX)
library-catalog:: DOI.org (Crossref)
authors:: Francesca Lonetti, Vânia Oliveira Neves, Antonia Bertolino
journal-abbreviation:: J Software Evolu Process
publication-title:: Journal of Software: Evolution and Process
short-title:: Designing and testing systems of systems
url:: https://onlinelibrary.wiley.com/doi/10.1002/smr.2427
language:: en
original-title:: Designing and testing systems of systems: From variability models to test cases passing through desirability assessment
access-date:: 2022-09-06T12:25:30Z
item-type:: [[journalArticle]]
title:: @Designing and testing systems of systems: From variability models to test cases passing through desirability assessment
doi:: 10.1002/smr.2427
issn:: "2047-7473, 2047-7481"
date:: [[17-01-2022]]
tags:: #Highlights
- [[Abstract]]
- In the early stages of a system of systems (SoS) conception, several constituent systems could be available that provide similar functionalities. An SoS design methodology should provide adequate means to model variability in order to support the opportunistic selection of the most desirable SoS configuration. We propose the VANTESS approach that (i) supports SoS modeling taking into account the variation points implied by the considered constituent systems; (ii) includes a heuristics to weight benefits and costs of potential architectural choices (called as SoS variants) for the selection of the constituent systems; and finally (iii) also helps test planning for the selected SoS variant by deriving a simulation model on which test objectives and scenarios can be devised. We illustrate an application example of VANTESS to the “educational” SoS and discuss its pros and cons within a focus group.
- [[Attachments]]
- [Lonetti et al. - 2022 - Designing and testing systems of systems From var.pdf](zotero://select/library/items/7JDWT9U8) {{zotero-imported-file 7JDWT9U8, "Lonetti et al. - 2022 - Designing and testing systems of systems From var.pdf"}}
- #focusgroup
- It's a method in software engineering to get expert opinions and qualitative feedback from a group of researchers and / or practitioners about a defined area of interest.
- The focus group consists of a carefully planned discussion performed with a limited number of participants, who are asked during the intereview a predifined list of questions about the research of interest.
- No quantitative assessments can be obtained with focus groups
- So, it can provide fast and cost-effective means to obtain initial feedback on new concepts or ideas, by leveraging the experiences of the group members.
- ((63173dfa-f96e-4db7-aa9c-448e8f9b8e3b))
- In a recemt EMSE paper
- {{embed ((63173d17-7b54-4df0-badf-e1e051814392))}}
-
pages/@DevOpsML%3A towards modeling DevOps processes and platforms.md
+23
View File
@@ -0,0 +1,23 @@
date:: [[16-10-2020]]
publisher:: ACM
place:: Virtual Event Canada
conference-name:: MODELS '20: ACM/IEEE 23rd International Conference on Model Driven Engineering Languages and Systems
proceedings-title:: Proceedings of the 23rd ACM/IEEE International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings
isbn:: 978-1-4503-8135-2
doi:: 10.1145/3417990.3420203
title:: @DevOpsML: towards modeling DevOps processes and platforms
pages:: 1-10
item-type:: [[ConferencePaper]]
access-date:: 2023-05-17T09:27:08Z
original-title:: DevOpsML: towards modeling DevOps processes and platforms
language:: en
url:: https://dl.acm.org/doi/10.1145/3417990.3420203
short-title:: DevOpsML
authors:: [[Alessandro Colantoni]], [[Luca Berardinelli]], [[Manuel Wimmer]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/PWP8IBBC), [Web library](https://www.zotero.org/users/1039502/items/PWP8IBBC)
- [[Abstract]]
- DevOps and Model Driven Engineering (MDE) provide differently skilled IT stakeholders with methodologies and tools for organizing and automating continuous software engineering activities–from development to operations, and using models as key engineering artifacts, respectively. Both DevOps and MDE aim at shortening the development life-cycle, dealing with complexity, and improve software process and product quality.
- [[Attachments]]
- [Colantoni et al. - 2020 - DevOpsML towards modeling DevOps processes and pl.pdf](zotero://select/library/items/32332MP9) {{zotero-imported-file 32332MP9, "Colantoni et al. - 2020 - DevOpsML towards modeling DevOps processes and pl.pdf"}}
pages/@Developing Self-Adaptive Microservice Systems%3A Challenges and Directions.md
+22
View File
@@ -0,0 +1,22 @@
date:: 3/2021
issn:: "0740-7459, 1937-4194"
issue:: 2
extra:: 00019
doi:: 10.1109/MS.2019.2955937
title:: @Developing Self-Adaptive Microservice Systems: Challenges and Directions
pages:: 70-79
volume:: 38
item-type:: [[journalArticle]]
access-date:: 2021-03-26T08:19:37Z
original-title:: Developing Self-Adaptive Microservice Systems: Challenges and Directions
language:: en
url:: https://ieeexplore.ieee.org/document/8913688/
short-title:: Developing Self-Adaptive Microservice Systems
publication-title:: IEEE Software
journal-abbreviation:: IEEE Softw.
authors:: [[Nabor C. Mendonca]], [[Pooyan Jamshidi]], [[David Garlan]], [[Claus Pahl]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/FJUJ6G3T), [Web library](https://www.zotero.org/users/1039502/items/FJUJ6G3T)
- [[Attachments]]
- [Mendonca et al. - 2021 - Developing Self-Adaptive Microservice Systems Cha.pdf](zotero://select/library/items/RPFVN45Z) {{zotero-imported-file RPFVN45Z, "Mendonca et al. - 2021 - Developing Self-Adaptive Microservice Systems Cha.pdf"}}
pages/@Domain-specific languages for the design, deployment and manipulation of heterogeneous databases.md
+14
View File
@@ -0,0 +1,14 @@
tags:: [[#nosource]], [[#readingnotes]]
date:: 2019
doi:: 10.1109/MiSE.2019.00021
title:: @Domain-specific languages for the design, deployment and manipulation of heterogeneous databases
pages:: 89-92
item-type:: [[journalArticle]]
original-title:: "Domain-specific languages for the design, deployment and manipulation of heterogeneous databases"
url:: https://www.scopus.com/inward/record.uri?eid=2-s2.0-85074891966&doi=10.1109%2fMiSE.2019.00021&partnerID=40&md5=b2db10132458ac9da2617f79f0ab6ff9
publication-title:: "Proceedings - 2019 IEEE/ACM 11th International Workshop on Modelling in Software Engineering, MiSE 2019"
authors:: [[D. Kolovos]], [[F. Medhat]], [[R. Paige]], [[D. Di Ruscio]], [[T. Van Der Storm]], [[S. Scholze]], [[A. Zolotas]]
links:: [Local library](zotero://select/library/items/W7K7JPK6), [Web library](https://www.zotero.org/users/1039502/items/W7K7JPK6)
- [[readingnotes]]
- cited By 8
pages/@Domain-specific semantic-rich software knowledge graph construction through human-LLM team working.md
+217
View File
@@ -0,0 +1,217 @@
tags:: [[#zotero]]
date:: 2026
title:: @Domain-specific semantic-rich software knowledge graph construction through human-LLM team working
item-type:: [[journalArticle]]
original-title:: Domain-specific semantic-rich software knowledge graph construction through human-LLM team working
language:: en
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/GFVMQWJV), [Web library](https://www.zotero.org/users/1039502/items/GFVMQWJV)
- [[Abstract]]
- In software engineering (SE), while graph-based tools such as user models and control flow graphs effectively capture behavioral and structural aspects of systems, they inadequately represent the semantic information essential for discerning complex relationships within software artifacts. Recognizing that Knowledge Graphs (KGs) excel in modeling semantic data, we introduce the Software Knowledge Graph (SKG), which adapts KGs to encapsulate entities, relationships, and categories pertinent to SE. Conventional KG construction approaches fall into two primary paradigms: the first one is the predefined-schema-guided method, which achieves high precision through strict adherence to established schema, but suffers from limited completeness, as such predefined schema often fail to capture all relevant entities and relationships; the second one is schema-free method, which leverages Large Language Models (LLMs) to enhance completeness but consequently introduces noise and inconsistency in the absence of schematic constraints. To reconcile these inherent trade-offs, this paper introduces the Do-While Human-LLM Team Working (DHTW) method, an evolutionary schema exploration paradigm that integrates LLM-driven autonomy with expert validation to balance precision and completeness in KG construction. In the “Do” phase, LLMs autonomously extract candidate schema elements, such as entity classes, attributes, and relationships, from domain-specific corpora based on learned user preferences rather than rigid predefined schema, thereby fostering expansive knowledge discovery. Subsequently, in the “While” phase, domain experts iteratively refine and validate these elements to ensure semantic consistency and precise alignment with domain requirements; this process continues until the corpus is exhaustively explored. By synergistically combining LLM-driven exploration with human-guided validation, the DHTW method effectively overcomes the rigidity and incompleteness of predefinedschema-guided methods while mitigating the noise and irrelevance of schema-free approaches. The comprehensive experimental evaluations underscore the effectiveness of the DHTW method. Furthermore, the generality of this method provides a blueprint for Human-LLM interaction in complex domains.
- ### Attachments
- [PDF](zotero://select/library/items/GH84YKWC) {{zotero-imported-file GH84YKWC, "2026 - Domain-Specific Semantic-Rich Software Knowledge Graph Construction through Human-LLM Team Working.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotazioni
(17/5/2025, 15:28:22)
- “Software Knowledge Graph Constructio” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 1) #ffd400
*Software Knowledge Graphs should be constructed with a goal in mind, isn't it? How the goal is given and taken into account during the graph construction process?*
- “Human-LLM Team Working” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 1) #5fb236
- “Recognizing that Knowledge Graphs (KGs) excel in modeling semantic data, we introduce the Software Knowledge Graph (SKG), which adapts KGs to encapsulate entities, relationships, and categories pertinent to SE.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 1) #5fb236
- “predefined-schema-guided method, which achieves high precision through strict adherence to established schema, but suffers from limited completeness, as such predefined schema often fail to capture all relevant entities and relationships” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 1) #5fb236
- “schema-free method, which leverages Large Language Models (LLMs) to enhance completeness but consequently introduces noise and inconsistency in the absence of schematic constraints” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 1) #5fb236
- “Do-While Human-LLM Team Working (DHTW) method, an evolutionary schema exploration paradigm that integrates LLM-driven autonomy with expert validation to balance precision and completeness in KG construction” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 1) #5fb236
- “These traditional graph representations primarily focus on capturing the behavioral and structural properties of systems” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 1) #5fb236
- “represent entities, their relationships, and categorical information pertinent to SE.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 1) #ffd400
*How do you embed or take into account the goal of the encoding of software systems in terms of KG? Knowledge Graphs can be done to capture different levels of abstraction!*
- “Do-While Human-LLM” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 1) #5fb236
- “Team Working (DHTW)” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #5fb236
- “In the "Do" phase, LLMs autonomously explore candidate schema elements, such as entity classes, attributes, and relationships, from specific corpora, guided by learned user preferences rather than rigid, predefined schema, thus facilitating expansive domain knowledge acquisition with LLM’s inherent divergence.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #5fb236
- “"While" phase, users, typically domain experts, iteratively refine, validate, and adjust these elements, ensuring semantic consistency, domain alignment, and fidelity to user-specified requirements through targeted corrections and adjustments.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #5fb236
- “To evaluate the effectiveness of the proposed DHTW method, we conducted experiments in two domains, focusing first on the API” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #ffd400
*It's not clear if the API domain is just a domain that has been used to evaluate the approach or if it is the main target of the work. This is not clarified in the paper. It seems that the approach is API domain specific.*
- “API domain, where extensive schema can be derived from the widely adopted Unified Modeling Language (UML)” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #5fb236
- “but also precisely aligned with the specific requirements of the domain.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #ffd400
*How is this given to the elicitation process? This is not clear to me.*
- “balancing completeness, precision, and contextual relevance.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #ffd400
*Exaclty, these are all relevant characteristics even though it is not clear at this stage how they are managed and given as input to the elicitation process.*
- “the absence of guidance frequently generates noise and leads to deviations from domain-specific standards, undermining the precision and alignment of the resulting KGs with user requirements” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #5fb236
- “DHTW method presents a disciplined yet flexible alternative, leveraging an iterative process to address these limitations.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #5fb236
- “In the method, the "Do" phase employs LLMs to identify and extract diverse schema elements from heterogeneous data sources, while the "While" phase incorporates expert validation to refine and organize these elements, ensuring iterative improvement.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #ffd400
*This is a repetition. This concept has been already said earlier in the paper.*
- “This work introduces the DHTW method for implementing "Human-in-the-Loop" by decomposing tasks into iterative cycles.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #a28ae5
- “In each iteration, LLMs execute subtasks (Do phase) using human-derived feedback (e.g., operational optimizations, clarified requirements), while domain experts refine outputs (While phase) to ensure precision and inject actionable guidance for subsequent rounds.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #a28ae5
- “This closedloop process harmonizes human expertise with LLM ability, fostering continuous improvement in both precision and completeness.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #ffd400
*This is a kind of chain of thoughts process, isn't it?*
- “DHTW method take the advantages of both predefinedschema-guided method and schema-free method, through Do-While schema exploration and schema-guided KG construction.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #a28ae5
- “The former iteratively discovers schema that adheres to domain standards while transcending predefined schema” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #5fb236
- “the latter leverages refined schema to construct KG from large-scale data, resolving the tension between rigidity and over-generalization in traditional approaches” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #5fb236
- “KGs for APIs (Application Programming Interface) can capture complex relationships and dependencies among large number of APIs, which can help developers better manage, optimize, and automate within API ecosystems” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #5fb236
- “reflecting domainspecific nuance” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #a28ae5
- “Figure 1 illustrates their differences, highlighting limitations and the need for a new approach.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #5fb236
- “KW&H, by Huang et al. [13], is a rule-based method with a predefined schema. It achieves high precision by analyzing software documentation but struggles with evolving needs, missing relationships outside predefined rules” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #5fb236
- “Reflecting on these methods, KW&H ensures precision but sacrifices completeness, while GraphRAG and EDC excel in completeness but compromise precision and semantic richness.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 2) #ffd400
*It's still vague.*
- “o API functional dependencies or interactions,” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 3) #ffd400
*If this is the interest of the study, it has to be clearly stated upfront in the paper.*
- “Figure 1: Comparison of Knowledge Graph Construction Methods in the API Domain” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 3) #ffd400
*Why not reusing existing approaches based on static analysis and just filter out those relationship triples that are not relevant for the goal at hand?*
- “Collections.sort(), relies on, Arrays.asList” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 3) #ffd400
*This example gives some hints on the wanted granularity of the poposed approach even though it is not explicitely mentioned. It is important to specify upfront what is the granularity of the proposed approach. Is it at method level?Class level? Component level? What are the entities of interest? What are they relationships of interest?*
- “avoiding pitfalls like (Files.readAllLines(), throws, IOException),” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 3) #ffd400
*Why this case are not of interest at all? It depens of the usage of the KGs, isn't it?*
- “3.1.1 Seed Text Preparation and Data Chunking.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 3) #2ea8e5
- “In the initial phase of schema exploration, we first extract a small but representative set of seed texts (e.g., API documentation, code snippets, or Stack Overflow posts) from the target domain [21]. These seed texts serve as input data, providing domain-specific context for schema exploration” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 3) #ffd400
*Ok this answers my comments about the domain previously given. It's important to add clarifications about this aspect earlier in the paper. By the way it is necessary to clarify what are the characteristics that need to be satisfied by the text and data that need to be prepared at this stage. Is data chunking automated? Depending on it, the subsequent phases are affected.*
- “[specific criteria TBD by user].” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 3) #ff6666
*I guess this is a sentence to be completed. isn't it?*
- “The chunking strategy is based on size, ensuring each chunk is suitable for processing” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 3) #ffd400
*Details are needed here.*
- “3.1.2 Do Phase: LLM-Based Schema Extraction and Definition.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 3) #2ea8e5
- “In the Do phase, the LLM extracts schema from the current data chunk, aiming to ensure the completeness of the generated schema.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 3) #ffd400
*Completeness with respect to what?*
- “The LLM first performs entity extraction to identify domain-related entities in the data chunk, such as a function name or variable from a code snippet.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 3) #ffd400
*Again, it is necessary to clarify what's the target domain of the approach. Is it for generating KGs for APIs? Can it be applied to other kinds of artifacts? The envisioned target use of the approach is not clear to me.*
- “Subsequently, the LLM inputs the extracted entities into the entity type labeling unit, which aggregates entities into preliminary labels, for example, grouping function-related terms under a “function” category. These labels are then input into the entity type fusion unit, which further abstracts low-dimensional entity types into high-dimensional types, such as combining “function” and “procedure” into a broader “callable” type. Relation types are abstracted through the relation type fusion unit, such as merging “calls” and “invokes” into a “call” category. Through this fusion mechanism, the method unifies and standardizes diverse entity and relation types, ensuring higher abstraction and consistency in the generated schema, unlike purely automated methods that may lack such refinement.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 3) #ffd400
*This is related to my previous points. Authors seem to have specific categories of interest that should be enumerated and justified in the paper.*
- “3.1.3 While Phase: Human Review and Feedback.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #2ea8e5
- “LLM generates two types of suggestions to optimize the next iteration. First, the LLM generates operational suggestions, such as suggesting not to extract temporary variables in the next iteration if the user does not need them,” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #5fb236
- “Second, the LLM generates clarification suggestions, such as suggesting to clarify if the user needs dependency relations, ensuring the schema meets specific needs.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #5fb236
- “3.1.4 Iterative Loop (Do-While Loop).” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #2ea8e5
- “until all chunks are processed” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #5fb236
- “which involves extracting API KGs from large-scale data based on validated schema.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #5fb236
- “the LLM identifies domainrelated entities in the data based on the entity types defined in the schema, such as functions or classes.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #5fb236
- “LLM identifies relationships between entities based on the predefined relation types in the schema, such as a “call” relation.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #5fb236
- “Through schema constraints, strict quality control is implemented, filtering out noise and correcting inconsistencies.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #5fb236
- “The final output of high-quality API KGs can be directly applied to practical domain tasks, such as code generation, code search, and vulnerability detection [25].” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #ffd400
*This statement needs to be substantiated.*
- “code generation, code search, and vulnerability detection” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #5fb236
- “balance precision, adaptability, and completeness,” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #ffd400
*I expect to see an experiment section that clearly show how the approach outperforms existing techniques with respect to three peculiar characteristics.*
- “we designed the method of DHTW which combines human expertise with the scalability of LLMs to deliver a KG that captures accurate relationships while avoiding noise and errors.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 4) #5fb236
- “alignment with user needs and domainspecific nuances.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 5) #5fb236
- “For instance, they assess whether “NullPointerException” is relevant to the user’s goals, and if deemed redundant, revise the schema by marking triples like “(Arrays.asList, throws, NullPointerException)” for exclusion.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 5) #ffd400
*I?m wondering how scalable is this manual process with respect to the size of the input data. Indeed this can be an error-prone and strenuous task.*
- “Predefined-schema-guided methods ensure precision but often lack completeness, as predefined schemas may miss relevant entities and relationships, leading to incomplete domain representations.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 5) #ffd400
*This is not properly supported. At the end, with the proposed approach, human implicitely defines the schema of interest. Why not giving this upfront to an algortihmic approach?*
- “Our research questions aim to investigate the indispensable role of Do-While schema exploration and definition coupled with the Human-LLM team working mechanism, in enhancing the applicability of constructed KGs.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 5) #ffd400
*Repeated manh times.*
- “thereby establishing a robust framework for effectively capturing the intricate semantics inherent in SE artifacts.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 6) #ffd400
*Te paper is missing an explicit definition of the SE artifact of interest or in other words that are managed by the proposed approach.*
- “RQ1: How does DHTW method outperform predefinedschema-guided and schema-free methods in constructing domain-specific KGs?” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 6) #2ea8e5
- “RQ2: How does Human-LLM team working mechanism enhance the precision and completeness of the constructed domain-specific KGs?” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 6) #2ea8e5
- “RQ3: How does KG schema exploration and definition strategy enhance the precision and completeness of the constructed domain-specific KGs?” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 6) #ffd400
*This seems to be covered by the previous two RQs, isn't it?*
- “There are two datasets used in the experiments” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 6) #5fb236
- “The first dataset focuses on the API domain. It includes two parts, the first part includes 206 Stack Overflow texts about Java obtained from work [13] (via GitHub [1]), which were used to summarize API entities and relationship types. The second part comprises 32,505 Java tutorial documents [14] provided by the same work [13]. However, not all Java tutorial documents contain relevant API entities and relationships. For example, some documents discuss general programming concepts without specific API references, such as: "This article focuses on two common operations: adding/removing elements...".” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 6) #ffd400
*The usage of the term domain is not clear. Both datasets are for creating KGs related to APIs. What do you mean with domain?  #question*
- “Applying these criteria, we extracted API entities and relationships from 5,047 texts to construct the API KG” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 6) #ffd400
*Right, it seems your goal is generating API KGs. Do you support other kinds of software artifacts? #question*
- “The second dataset is the WebNLG+2020 (v3.0) [5] semantic parsing task test set, which is also used in the EDC method [31]. WebNLG+2020 includes 1,165 pairs of texts and triplets, focusing on urban information, with reference triplet patterns covering 159 unique relationship types. We sampled 333 texts from the WebNLG+2020 training set to construct seed texts. However, we observed that the reference triplets in WebNLG+2020 are often non-exhaustive and may include information external to the text. This issue may lead to inaccuracies in evaluation results. To address this problem, we arranged for annotators to construct reference answers for 367 sampled data points in the urban information domain, following the same method as the first dataset, as an additional test set. The Cohen’s Kappa coefficients for this annotation process were 0.83 and 0.81, demonstrating high inter-annotator agreement.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 6) #ffd400
*What is the wanted KG supposed to represent with this dataset?*
- “4.4 Experimental Evaluation Metrics” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 7) #ffd400
*The confusion about the scope of the paper is also testified in this section. Even though in the previous section mentions that two different "domains" are considered, the evaluation metrics that are presented in section 4.4. all refer ti the API knowledge extraction problem.*
- “5.1 Evaluation of RQ1” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 7) #ffd400
*Also in this section, only the API KG extraction problem is considered. No trace about the second application domain mentioned in section 4.3. Actually the same problem occurs for the whole experimental evaluation section.*
- “While they excel in breadth, they fall short in delivering a semantic-rich schema.” (“Domain-specific semantic-rich software knowledge graph construction through human-LLM team working”, 2026, p. 7) #ffd400
*Can you elaborate more on this? It is not clear the problem that  you want to address. The challenges that are caused  by existing approaches and that this paper aims to address are not clear #question*
COnsider that those that are tagget with #5fb236 are just highlights, those that are tagged with #e56eee and #a28ae5 are imporant 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 sentence to summarize the work
STRENGHTS:
WEAKNESSES:
COMMENTS: Organize the notes with respect to the following criteria:
-
`Novelty`
-
`Rigor`
-
`Relevance (of the contribution)`
-
`Verifiability and Transparency`
-
`Presentation`
And then add a Detailed Comments section to report the notes that contain issues or typos.
Can you also formulate three explicit questions by considering the comments that are tagged with #question ?
pages/@ESEM24_paper_205.pdf.md
+8
View File
@@ -0,0 +1,8 @@
tags:: [[#zotero]]
title:: @ESEM24_paper_205.pdf
item-type:: [[document]]
original-title:: ESEM24_paper_205.pdf
links:: [Local library](zotero://select/library/items/HISLHCJC), [Web library](https://www.zotero.org/users/1039502/items/HISLHCJC)
- ### Attachments
- [ESEM24_paper_205](zotero://select/library/items/3DRA2NCJ) {{zotero-imported-file 3DRA2NCJ, "ESEM24_paper_205.pdf"}}
pages/@ESEM24_paper_220.pdf.md
+8
View File
@@ -0,0 +1,8 @@
tags:: [[#zotero]]
title:: @ESEM24_paper_220.pdf
item-type:: [[document]]
original-title:: ESEM24_paper_220.pdf
links:: [Local library](zotero://select/library/items/33T6XVEN), [Web library](https://www.zotero.org/users/1039502/items/33T6XVEN)
- ### Attachments
- [ESEM24_paper_220](zotero://select/library/items/2TVISAU2) {{zotero-imported-file 2TVISAU2, "ESEM24_paper_220.pdf.pdf"}}
pages/@Efficient Data Streaming Analytic Designs for Parallel and Distributed Processing.md
+30
View File
@@ -0,0 +1,30 @@
tags:: [[readingnotes]]
title:: @Efficient Data Streaming Analytic Designs for Parallel and Distributed Processing
item-type:: [[journalArticle]]
original-title:: Efficient Data Streaming Analytic Designs for Parallel and Distributed Processing
language:: en
authors:: [[Hannaneh Najdataei]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/I82KJNLV), [Web library](https://www.zotero.org/users/1039502/items/I82KJNLV)
- [[Abstract]]
- Today, ubiquitously sensing technologies enable inter-connection of physical objects, as part of Internet of Things (IoT), and provide massive amounts of data streams. In such scenarios, the demand for timely analysis has resulted in a shift of data processing paradigms towards continuous, parallel, and multitier computing. However, these paradigms are followed by several challenges especially regarding analysis speed, precision, costs, and deterministic execution. This thesis studies a number of such challenges to enable efficient continuous processing of streams of data in a decentralized and timely manner. In the first part of the thesis, we investigate techniques aiming at speeding up the processing without a loss in precision. The focus is on continuous machine learning/data mining types of problems, appearing commonly in IoT applications, and in particular continuous clustering and monitoring, for which we present novel algorithms; (i) Lisco, a sequential algorithm to cluster data points collected by LiDAR (a distance sensor that creates a 3D mapping of the environment), (ii) p-Lisco, the parallel version of Lisco to enhance pipeline- and data-parallelism of the latter, (iii) pi-Lisco, the parallel and incremental version to reuse the information and prevent redundant computations, (iv) g-Lisco, a generalized version of Lisco to cluster any data with spatio-temporal locality by leveraging the implicit ordering of the data, and (v) Amble, a continuous monitoring solution in an industrial process.
- [[Attachments]]
- [Najdataei - Efficient Data Streaming Analytic Designs for Para.pdf](https://research.chalmers.se/publication/531736/file/531736_Fulltext.pdf) {{zotero-imported-file THKTVIBT, "Najdataei - Efficient Data Streaming Analytic Designs for Para.pdf"}}
- [[Highlights]]
- ((63b98c01-8b4d-4f37-9346-f1d2c0fdcde3))
id:: 63b98746-230b-4f4a-976d-650d4fce5e7d
- ((63b98c4b-d05a-443e-879d-7a7d4628e438))
id:: 63b98818-0835-4dfb-97ac-14d06beef911
- ((63b98c76-74e4-4db5-b675-73032e781ef1))
- ((63b9963c-7fa3-49c5-aefd-0edf30f50aea))
- How would also add **how data mining/analysis tasks are specified/developed**
- #+BEGIN_IMPORTANT
((63b99873-26f0-4e2d-ad9a-f5b9addda8f9))
((63b9987c-3d40-46ae-8eff-e9aee9ef0481))
#+END_IMPORTANT
- Example
- ((63b998ec-5b05-4ea1-b75a-8d870292da65))
- ((63b998db-4004-4323-9087-af18f15fafd9))
-
pages/@Encoding Conceptual Models for Machine Learning%3A A Systematic Review.md
+37
View File
@@ -0,0 +1,37 @@
date:: 2021
publisher:: IEEE
place:: "Fukuoka, Japan"
conference-name:: 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)
proceedings-title:: 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)
isbn:: 978-1-66542-484-4
title:: @Encoding Conceptual Models for Machine Learning: A Systematic Review
item-type:: [[conferencePaper]]
original-title:: Encoding Conceptual Models for Machine Learning: A Systematic Review
language:: en
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/YCK2H4FE), [Web library](https://www.zotero.org/users/1039502/items/YCK2H4FE)
-
- [[Abstract]]
- Conceptual models are essential in Software and Information Systems Engineering to meet many purposes since they explicitly represent the subject domains. Machine Learning (ML) approaches have recently been used in conceptual modeling to realize, among others, intelligent modeling assistance, model transformation, and metamodel classification. These works encode models in various ways, making the encoded models suitable for applying ML algorithms. The encodings capture the models’ structure and/or semantics, making this information available to the ML model during training. Therefore, the choice of the encoding for any ML-driven task is crucial for the ML model to learn the relevant contextual information. In this paper, we report findings from a systematic literature review which yields insights into the current research in machine learning for conceptual modeling (ML4CM). The review focuses on the various encodings used in existing ML4CM solutions and provides insights into i) which are the information sources, ii) how is the conceptual model’s structure and/or semantics encoded, iii) why is the model encoded, i.e., for which conceptual modeling task and, iv) which ML algorithms are applied. The results aim to structure the state of the art in encoding conceptual models for ML.
- [[Attachments]]
- [Encoding Conceptual Models for Machine Learning: A Systematic Review](zotero://select/library/items/3EZ594JB) {{zotero-imported-file 3EZ594JB, "Encoding Conceptual Models for Machine Learning A Systematic Review.pdf"}}
- [[Highlights]]
- ((651a8452-9451-48da-b2c6-9d0ae7257ea7))
-
- date:: 2021
publisher:: IEEE
place:: "Fukuoka, Japan"
conference-name:: 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)
proceedings-title:: 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)
isbn:: 978-1-66542-484-4
title:: @Encoding Conceptual Models for Machine Learning: A Systematic Review
item-type:: [[conferencePaper]]
original-title:: Encoding Conceptual Models for Machine Learning: A Systematic Review
language:: en
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/YCK2H4FE), [Web library](https://www.zotero.org/users/1039502/items/YCK2H4FE)
- [[Abstract]]
- Conceptual models are essential in Software and Information Systems Engineering to meet many purposes since they explicitly represent the subject domains. Machine Learning (ML) approaches have recently been used in conceptual modeling to realize, among others, intelligent modeling assistance, model transformation, and metamodel classification. These works encode models in various ways, making the encoded models suitable for applying ML algorithms. The encodings capture the models’ structure and/or semantics, making this information available to the ML model during training. Therefore, the choice of the encoding for any ML-driven task is crucial for the ML model to learn the relevant contextual information. In this paper, we report findings from a systematic literature review which yields insights into the current research in machine learning for conceptual modeling (ML4CM). The review focuses on the various encodings used in existing ML4CM solutions and provides insights into i) which are the information sources, ii) how is the conceptual model’s structure and/or semantics encoded, iii) why is the model encoded, i.e., for which conceptual modeling task and, iv) which ML algorithms are applied. The results aim to structure the state of the art in encoding conceptual models for ML.
- [[Attachments]]
- [Encoding Conceptual Models for Machine Learning: A Systematic Review](zotero://select/library/items/3EZ594JB) {{zotero-imported-file 3EZ594JB, "Encoding Conceptual Models for Machine Learning A Systematic Review.pdf"}}
pages/@Ensuring the consistency of information between two versions of a mechanical drawing.md
+265
View File
@@ -0,0 +1,265 @@
tags:: [[#zotero]]
date:: 2017
title:: @Ensuring the consistency of information between two versions of a mechanical drawing
item-type:: [[journalArticle]]
original-title:: Ensuring the consistency of information between two versions of a mechanical drawing
language:: en
authors:: [[Alexandre Monnier Weil]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/D8AE4HWY), [Web library](https://www.zotero.org/users/1039502/items/D8AE4HWY)
- [[Abstract]]
- Mechanical drawings are crucial in industry for manufacturing and information retrieval. Companies face a recurring issue with managing their hand-drawn drawings produced in the mid-20th century. To address this, the engineers convert hand-drawn drawings into CAD drawings. This transformation process must be error-free to avoid material waste and significant costs. To ensure this, quality assurance engineers carefully verify the final CAD drawings to ensure all information is preserved. This verification process is time-consuming and laborious, often requiring the dedicated effort of two engineers for an entire week per drawing.
- ### Attachments
- [File PDF](zotero://select/library/items/MDHX56YJ) {{zotero-imported-file MDHX56YJ, "Weil - 2017 - Ensuring the consistency of information between two versions of a mechanical drawing.pdf"}}
- ### Notes
- # Annotazioni
(23/7/2024, 17:32:02)
- “Companies face a recurring issue with managing their hand-drawn drawings produced in the mid-20th century” (Weil, 2017, p. 1) #5fb236
* *
- “This transformation process must be error-free to avoid material waste and significant costs.” (Weil, 2017, p. 1) #5fb236
* *
- “This verification process is time-consuming and laborious, often requiring the dedicated effort of two engineers for an entire week per drawing” (Weil, 2017, p. 1) #5fb236
* *
- “Identifying these dissimilarities will reduce the effort of the engineers to perform the necessary corrections” (Weil, 2017, p. 1) #a28ae5
* *
- “Our approach is divided into two aspects:” (Weil, 2017, p. 1) #5fb236
* *
- “interpreting the drawings to extract information” (Weil, 2017, p. 1) #a28ae5
* *
- “comparing the drawings based on this information” (Weil, 2017, p. 1) #a28ae5
* *
- “formalism to describe the information contained in mechanical drawings” (Weil, 2017, p. 1) #5fb236
* *
- “graph-based structure” (Weil, 2017, p. 1) #5fb236
* *
- “Figure 2.” (Weil, 2017, p. 1) #ffd400
*This should come before Fig. 1, isn't it? *
- “Any mistake can propagate through the production process, resulting in material waste and significant costs” (Weil, 2017, p. 1) #a28ae5
* *
- “This verification process is time-consuming and laborious, often requiring the dedicated effort of two engineers for an entire week per drawing” (Weil, 2017, p. 1) #a28ae5
* *
- “automate this verification step;” (Weil, 2017, p. 1) #5fb236
* *
- “dissimilarity as a divergence of information that leads to inconsistencies in the CAD drawing with respect to the original hand-drawn version.” (Weil, 2017, p. 1) #a28ae5
* *
- “Identifying these dissimilarities will reduce the effort of the engineers to perform the necessary corrections.” (Weil, 2017, p. 1) #a28ae5
* *
- “the placement of annotations is different between the versions” (Weil, 2017, p. 2) #ffd400
*Does this represent a problem? *
- “For example, in Figure 2, the dimension values are not in the same location, and the arrowheads in the hand-drawn drawing point outward, while in the CAD drawing, they point inward.” (Weil, 2017, p. 2) #ffd400
*There are also some values that are different. *
- “This complexity shows that an interpretation step of the drawings is necessary before considering comparison.” (Weil, 2017, p. 2) #a28ae5
* *
- “Graph construction” (Weil, 2017, p. 2) #2ea8e5
* *
- “Drawing interpretation” (Weil, 2017, p. 2) #2ea8e5
* *
- “developing a methodology for segmenting annotations and pure geometry” (Weil, 2017, p. 2) #5fb236
* *
- “incrementally adding new examples to enhance annotation detection.” (Weil, 2017, p. 2) #a28ae5
* *
- “Interpretation-Based comparison” (Weil, 2017, p. 2) #2ea8e5
* *
- “Integrated methodology validation” (Weil, 2017, p. 2) #2ea8e5
* *
- “scanned hand-drawn drawings are algorithmically cleaned of all unwanted information, such as smudges, creases, and the noise often present in scans of hand-drawn mechanical drawings” (Weil, 2017, p. 2) #a28ae5
* *
- “our first three contributions” (Weil, 2017, p. 2) #a28ae5
* *
- “rule-based and heuristic systems” (Weil, 2017, p. 2) #a28ae5
* *
- “advancements in deep learning have shown promise in this field” (Weil, 2017, p. 2) #ffd400
*Are this referred to "modern techniques" previously mentioned? *
- “The focus of our research is to digitize mechanical drawings with the goal of developing a modular interpretation system that can easily incorporate new annotation standards.” (Weil, 2017, p. 2) #e56eee
* *
- “This refinement reduces the number of shapes to describe the drawing.” (Weil, 2017, p. 2) #5fb236
* *
- “Graph matching involves associating one graph with another” (Weil, 2017, p. 3) #a28ae5
* *
- “exact methods” (Weil, 2017, p. 3) #2ea8e5
* *
- “approximate methods, that allow for a certain degree of tolerance [17]” (Weil, 2017, p. 3) #2ea8e5
* *
- “We are particularly interested in the approximate methods as they are easily adaptable and do not require training.” (Weil, 2017, p. 3) #a28ae5
* *
- “This approach involves defining a set of editing rules to transform one graph into another.” (Weil, 2017, p. 3) #5fb236
* *
- “this method calculates a distance between two graphs based on the total cost of actions required for the transformation” (Weil, 2017, p. 3) #5fb236
* *
- “This tracking provides a more detailed understanding of how one graph is transformed into another, which can be particularly useful for explainability.” (Weil, 2017, p. 3) #ffd400
*What is the complexity of this operation? *
- “querying of large databases of such drawings.” (Weil, 2017, p. 3) #a28ae5
* *
- “This method does not enable precise comparison of information nor effectively highlights the differences between the drawings.” (Weil, 2017, p. 3) #ffd400
* *
- “Piping and Instrumentation Diagrams (P&IDs).” (Weil, 2017, p. 3) #5fb236
* *
- “Binarized hand-drawn drawing Image” (Weil, 2017, p. 3) #ffd400
*This is the main issue that I see. How can we be sure that hand-drawn images are correctly vectorized? This is the main shortcomings. *
- “Metamodel” (Weil, 2017, p. 3) #ffd400
*What's the use of this? *
- “annotations are represented geometrically, they should be regarded as metadata.” (Weil, 2017, p. 3) #ffd400
* *
- “The vectorisation algorithm is considered a parameter of our approach, meaning the detected shapes depend on the specific algorithm used.” (Weil, 2017, p. 4) #a28ae5
* *
- “we apply a vectorisation algorithm to raster images, resulting in a list of detected shapes.” (Weil, 2017, p. 4) #5fb236
* *
- “treating each intersection point as vertices in the graph” (Weil, 2017, p. 4) #5fb236
* *
- “segments s1 and s2 and the intersection i1 are grouped into a hyperedge a1.” (Weil, 2017, p. 4) #5fb236
* *
- “4.3 Comparison” (Weil, 2017, p. 5) #ffd400
*All the model comparison work done in the modeling community has been neglected. In the end, once CAD artifacts are represented as graphs, they are models that can be compared by using existing technologhies, that should be considere din the work. *
- “function f that maps a node in the initial graph to a corresponding node in the target graph.” (Weil, 2017, p. 5) #5fb236
* *
- “We will assess whether our comparison method can detect all the dissimilarities that engineers can identify in order to evaluate the comparison approach. We will compare the efficiency of our method with the engineers’ performance to evaluate if our method enhances the overall detection process.” (Weil, 2017, p. 5) #5fb236
* *
pages/@Enterprise Restaurant Compute.pdf.md
+11
View File
@@ -0,0 +1,11 @@
tags:: [[readingnotes]]
title:: @Enterprise Restaurant Compute.pdf
item-type:: [[document]]
original-title:: Enterprise Restaurant Compute.pdf
url:: https://medium.com/chick-fil-atech/enterprise-restaurant-compute-f5e2fd63d20f
links:: [Local library](zotero://select/library/items/D5KB7LRT), [Web library](https://www.zotero.org/users/1039502/items/D5KB7LRT)
- [[Attachments]]
- [Enterprise Restaurant Compute.pdf](zotero://select/library/items/F3CTZD3P) {{zotero-imported-file F3CTZD3P, "Enterprise Restaurant Compute.pdf"}}
- [[Highlights]]
- ((63c6adc9-7b81-4342-98e2-0efc8b42225d))
pages/@Estimation, Impact and Visualization of Schema Evolution in Graph Databases.md
+77
View File
@@ -0,0 +1,77 @@
tags:: [[#zotero]]
date:: 2024
title:: @Estimation, Impact and Visualization of Schema Evolution in Graph Databases
item-type:: [[journalArticle]]
original-title:: "Estimation, Impact and Visualization of Schema Evolution in Graph Databases"
language:: en
authors:: [[Dominique Hausler]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/4PIZV7JR), [Web library](https://www.zotero.org/users/1039502/items/4PIZV7JR)
- [[Abstract]]
- Graph databases offer a flexible storage of interconnected data. Due to NoSQL databases being schemaless, heterogeneous data can occur when performing data changes. Evolution is conducted through so called evolution operations like add, rename, delete, merge, copy, move or split. As a user can not foresee the results of the evolution operation neither the amount of data changes nor the possible schema violations or a relaxed schema, a system to show the impact of evolution is essential. To ensure schema conformity, we present an approach to close the gap of a schema management tool for graph databases in order to estimate and illustrate the impact of evolution on the schema level. To illustrate, explore, evolve and change the schema all required information is handled through a schema management layer. Besides extracting the schema, so called structure profiles are designed for an initial data exploration. The preview of the schema and structure profiles shows the impact of evolution on the data by comparing versions. Moreover, the system uses an intuitive syntax to also enable the usage of graph databases for non-experts.
- ### Attachments
- [File PDF](zotero://select/library/items/9ZGTXUZS) {{zotero-imported-file 9ZGTXUZS, "Hausler - 2024 - Estimation, Impact and Visualization of Schema Evolution in Graph Databases.pdf"}}
- ### Notes
- # Annotazioni
(22/7/2024, 16:05:35)
- “Schema Evolution in Graph Databases” (Hausler, 2024, p. 1) #5fb236
- “Due to NoSQL databases being schemaless, heterogeneous data can occur when performing data changes.” (Hausler, 2024, p. 1) #5fb236
- “As a user can not foresee the results of the evolution operation neither the amount of data changes nor the possible schema violations or a relaxed schema, a system to show the impact of evolution is essential.” (Hausler, 2024, p. 1) #a28ae5
- “estimate and illustrate the impact of evolution on the schema level” (Hausler, 2024, p. 1) #5fb236
- “structure profiles are designed for an initial data exploration” (Hausler, 2024, p. 1) #5fb236
- “Due to graph database offering schemalessness, heterogeneity can occur through optional elements or structural error.” (Hausler, 2024, p. 1) #5fb236
- “our goal is to involve users by informing them about such occurrences and giving the option to make changes if needed.” (Hausler, 2024, p. 1) #5fb236
- “Schema Management Layer (SML)” (Hausler, 2024, p. 1) #5fb236
- “schema and statistical information can be extracted, compared and constraints detected.” (Hausler, 2024, p. 1) #ffd400
*This seems not new. What's the novelty with respect to existing work?
I'm missing relevant work from Atzeni et al. like:
Paolo Atzeni, Francesca Bugiotti, Luca Cabibbo, Riccardo Torlone:
Data modeling in the NoSQL world. Comput. Stand. Interfaces 67 (2020)
Paolo Atzeni, Francesca Bugiotti, Luca Rossi:
Uniform access to NoSQL systems. Inf. Syst. 43: 117-133 (2014)
Francesca Bugiotti, Luca Cabibbo, Paolo Atzeni, Riccardo Torlone:
Database Design for NoSQL Systems. ER 2014: 223-231
Concerning the evolution management, the author should also consider:
Maxime Gobert, Loup Meurice, Anthony Cleve:
Modeling, manipulating and evolving hybrid polystores with HyDRa. Sci. Comput. Program. 230: 102972 (2023)
Maxime Gobert, Csaba Nagy, Henrique Rocha, Serge Demeyer, Anthony Cleve:
Best practices of testing database manipulation code. Inf. Syst. 111: 102105 (2023)
Anthony Cleve, Maxime Gobert, Loup Meurice, Jerome Maes, Jens H. Weber:
Understanding database schema evolution: A case study. Sci. Comput. Program. 97: 113-121 (2015)
Compared to such related work, I see potential novelty mainly concerning RQ3 and RQ4.*
- “the schema extraction paired with the information extraction for structure profiles is new” (Hausler, 2024, p. 1) #ffd400
*Why? What's the limitation of existing work?*
- “RQ3: How to estimate the effort and illustrate the impact of evolution operations as well as the affected elements? • RQ4: What kind of optimizations are needed?” (Hausler, 2024, p. 2) #ffd400
*Maybe this part is new. Concerning RQ1 and RQ2, they are related to existing work that is not mentioned.*
- “his limitation is due to schema evolution affecting only the property names np .” (Hausler, 2024, p. 3) #5fb236
- “estimate and display the affected elements through the Preview Module.” (Hausler, 2024, p. 4) #ffd400
*What do you mean with estimate? What kinds of estimation are you supporting?*
- “Schema evolution is conducted through the evolution operations add, rename, delete, copy, move, split and merge” (Hausler, 2024, p. 5) #5fb236
- “estimation of the impact of evolution on the database” (Hausler, 2024, p. 5) #5fb236
- “easy-to-understand language called GEO.” (Hausler, 2024, p. 5) #a28ae5
pages/@Evaluating Code Summarization Techniques%3A A New Metric and an Empirical Characterization.md
+23
View File
@@ -0,0 +1,23 @@
links:: [Local library](zotero://select/library/items/4Z4UBSE8), [Web library](https://www.zotero.org/users/1039502/items/4Z4UBSE8)
authors:: [[Antonio Mastropaolo]], [[Matteo Ciniselli]], [[Massimiliano Di Penta]], [[Gabriele Bavota]]
tags:: [[Computer Science - Software Engineering]], [[#zotero]]
date:: [[24-12-2023]]
item-type:: [[preprint]]
title:: @Evaluating Code Summarization Techniques: A New Metric and an Empirical Characterization
-
- [[Abstract]]
- Several code summarization techniques have been proposed in the literature to automatically document a code snippet or a function. Ideally, software developers should be involved in assessing the quality of the generated summaries. However, in most cases, researchers rely on automatic evaluation metrics such as BLEU, ROUGE, and METEOR. These metrics are all based on the same assumption: The higher the textual similarity between the generated summary and a reference summary written by developers, the higher its quality. However, there are two reasons for which this assumption falls short: (i) reference summaries, e.g., code comments collected by mining software repositories, may be of low quality or even outdated; (ii) generated summaries, while using a different wording than a reference one, could be semantically equivalent to it, thus still being suitable to document the code snippet. In this paper, we perform a thorough empirical investigation on the complementarity of different types of metrics in capturing the quality of a generated summary. Also, we propose to address the limitations of existing metrics by considering a new dimension, capturing the extent to which the generated summary aligns with the semantics of the documented code snippet, independently from the reference summary. To this end, we present a new metric based on contrastive learning to capture said aspect. We empirically show that the inclusion of this novel dimension enables a more effective representation of developers’ evaluations regarding the quality of automatically generated summaries.
- ### Attachments
- [Mastropaolo et al. - 2023 - Evaluating Code Summarization Techniques A New Me.pdf](zotero://select/library/items/MEUEEDN9) {{zotero-imported-file MEUEEDN9, "Mastropaolo et al. - 2023 - Evaluating Code Summarization Techniques A New Me.pdf"}}
- ### Notes
- # Annotazioni
- (19/1/2024, 11:16:08)
- “Evaluating Code Summarization Techniques: A New Metric and an Empirical Characterization” (Mastropaolo et al., 2023, p. 1) #5fb236
- *This is related to project [[PROJECTS/MOSAICO]]*
- “Several code summarization techniques have been proposed in the literature to document a code snippet or a function automatically.” (Mastropaolo et al., 2023, p. 1) #ffd400
- *This is a comment for a yellow highlight [[P1]] [[STAR]]*
- “oftware developers should be involved in assessing the quality of the generated summaries. However, in most cases, researchers rely on a” (Mastropaolo et al., 2023, p. 1) #ff6666
- *This is not good [[people/phuong]]*
- “falls short: (i) reference summaries, e.g., code comments collected by mining software repositories, may be of low quality or even outdated; (ii)” (Mastropaolo et al., 2023, p. 1) #5fb236
- “m a thorough empirical investigation on the complementarity of different types of metrics in capturing the quality of a generated summary. Also, we propose to address the limitations of existing metrics by consid” (Mastropaolo et al., 2023, p. 1) #ffd400
pages/@Evolutionary prompt engineering for cost-effective code generation with large language models.md
+218
View File
@@ -0,0 +1,218 @@
tags:: [[#zotero]]
date:: 2017
title:: @Evolutionary prompt engineering for cost-effective code generation with large language models
item-type:: [[journalArticle]]
original-title:: Evolutionary prompt engineering for cost-effective code generation with large language models
language:: en
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/VKR2ARTC), [Web library](https://www.zotero.org/users/1039502/items/VKR2ARTC)
- [[Abstract]]
- Large Language Models (LLMs) have seen increasing use in various software development tasks, especially in code generation. The most advanced recent methods attempt to incorporate feedback from code execution into prompts to help guide LLMs in generating correct code in an iterative process. While effective, these methods could be costly due to numerous interactions with the LLM and extensive token usage. To address this issue, we propose an alternative approach named Evolutionary Prompt Engineering for Code (EPiC), which leverages a lightweight evolutionary algorithm to refine the original prompts into improved versions that generate high-quality code, with minimal interactions with the LLM. Our evaluation against state-of-the-art (SOTA) LLM-based code generation agents shows that EPiC not only achieves up to 6% improvement in pass@k but is also 2–10 times more cost-effective than the baselines.
- ### Attachments
- [PDF](zotero://select/library/items/9RXNTKG3) {{zotero-imported-file 9RXNTKG3, "2017 - Evolutionary prompt engineering for cost-effective code generation with large language models.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotazioni
(16/5/2025, 11:18:31)
- “Cost-Effective Code Generation” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #5fb236
- “feedback from code execution into prompts” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #ffd400
*What kind of code execution information are fed into prompts?*
- “6% improvement in pass@k” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #5fb236
- “cost-effective” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #ffd400
*what kind of cost is considered here?*
- “MBPP dataset” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #ffd400
*what is it?*
- “LATS” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #ffd400
*what is it?*
- “One key limitation of these approaches is that the initial prompt fed to the LLM is often suboptimal.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #a28ae5
- “If we had an approach that systematically improves the prompt with minimal LLM calls, we could find the optimal prompt.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #5fb236
*this is s a kind of teacher-student pattern.*
- “if we automatically mutate the initial prompt, systematically test it, and then finalize an improved version, we can converge on correct code more efficiently.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #5fb236
- “Evolutionary Prompt Engineering for Code (EPiC)” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #a28ae5
- “to refine prompts in a structured and costeffective way.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #e56eee
- “augmented” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #ffd400
*why necessarely augmented? withb respect to what?*
- “The mutation is carried out using two approaches: one utilizes an LLM 1 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 Conference’17, July 2017, Washington, DC, USA Anon. 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 guided by a prompt that specifies how to perform the mutation, and the other employs vector embeddings of words to find and replace similar words.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 1) #a28ae5
- “pass@k metric,” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #a28ae5
- “as introduced in [3], for accuracy (effectiveness), which estimates the probability that at least one of the top k generated code samples is correct” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #a28ae5
- “Additional Token Usage per Solved Problem” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #e56eee
- “code generation task from the cost-effectiveness perspective” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #e56eee
- “novel framework EPiC that leverages a lightweight evolutionary algorithm to evolve the original prompts toward better ones that produce high-quality code” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #e56eee
- “cost-effectiveness of EPiC in code generation compared to baseline methods” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #e56eee
- “we briefly explain prompt engineering for LLMs in general and report the most related work in the context of prompt engineering of LLM for code.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #5fb236
- “Prompt engineering refers to the process of designing and refining prompts to achieve desired outcomes when using LLMs1” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #5fb236
- “approaches without training” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #5fb236
- “reasoning and logic” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #5fb236
- “reducing hallucination” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #5fb236
- “evolutionary-based methods” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #5fb236
- “reasoning and logic-based methods” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #5fb236
- “Few-shot prompting [1] provides limited examples to guide understanding but requires more tokens, making it less practical for long texts and susceptible to bias from example selection.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #5fb236
- “EvoPrompt [34] automates this by iteratively refining prompts using mutation and crossover.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #a28ae5
- “Using Parsel, they break down algorithmic tasks into structured descriptions written in natural language, then explore various combinations of function implementations using tests” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #5fb236
- “Reflexion [29] is a reinforcement-based framework in which language agents learn from linguistic feedback.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 2) #5fb236
- “EPiC is the first evolutionary-based prompt engineering method for code generation.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 3) #e56eee
- “It employs a lightweight process to identify the optimal solution in a cost-effective manner.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 3) #e56eee
- “EPiC utilizes a local embedding function to implement mutation operators on text to reduce the cost of iterative prompt engineering for code generation.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 3) #a28ae5
- “guides the search over iterations using the fitness function in Section 4.4, which helps in finding the best prompts.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 3) #a28ae5
- “without requiring gradient information” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 3) #a28ae5
- “where the pass rate of generated code is a discrete and non-differentiable function.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 3) #e56eee
- “initialization, evaluation, selection, variation, and iteration.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 3) #2ea8e5
- “evaluating fitness is relatively straightforward” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 3) #ffd400
*How can you say that? You are supposed to measure the quality of the output produced with the prompt at hand, and this can require some time/effort! #question*
- “optimized” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 3) #ffd400
*Do you know if each iteration improves the previous ones? #question*
- “sufficient to generate the correct implementatio” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 3) #ffd400
*Here we have "sufficient" and "correct" that need to be concretize. They refer crucial aspects that need to be materialized otherwise it's not clear how they can be achieved in practice.*
- “In” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 3) #ffd400
*Maybe you can start the paragraph by saying, "By referring to Fig. 2 ..."*
- “muCandidates ← chooseCandidates (candidates, N − 1)” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 4) #5fb236
- “test cases.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 4) #ffd400
*It seems that also test cases are generated. What if generated test cases are semantically wrong? This is a possible "point of failure" of the whole process.*
- “If any test case fails on the code, we continue with the EPE phase. If all test cases pass, we report the generated code as the final answer” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 4) #ffd400
*See my previous comment. Test cases might pass because tests are wrong if those are not given as input and instead also part of the generation.*
- “Note that test cases can be provided in various ways. One approach is to use developer-provided test cases for evaluation, while another is to generate test cases using the LLM.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 4) #ffd400
*See my previous point. This can be an important point of failure of the process.*
- “we also opted to use LLMs for test case generation to ensure a fully automated approach, assuming no developer-provided test cases. To ensure the functional correctness of these test cases, we validated them by parsing their Abstract Syntax Trees (AST)” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 4) #ffd400
*This is a critical point. It is not clear how it works. When test cases are generated, starting from what? From the same prompt used to generate code? #question*
- “prompts for code and test case generation” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 4) #ffd400
*These look like completely disconnected. How can you be sure that test cases are semantically connected to the wanted generated code? #question*
- “assert add3Numbers(1, 2, 3) == 6 assert add3Numbers(-1, 2, 3) == 4 assert add3Numbers(1, -2, 3) == 2 assert add3Numbers(1, 2, -3) == 0 assert add3Numbers(-3, -2, -1) == -6 assert add3Numbers(0, 0, 0) == 0” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 4) #ffd400
*I'm skeptical about the semantic correctness of the generated test cases.*
- “we generate multiple prompts by modifying the initial prompt using an LLM agent. Generating this prompt population forms an important part of our evolutionary algorithm” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 5) #ffd400
*What are the mutation operators to generate multiple prompts?*
- “We define a fitness function based on the ratio of test cases passed.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 5) #ffd400
*See my previous content.*
- “randomly mutates” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 5) #ffd400
*This triggers many questions related to the way mutants are generated.*
- “adding the elite prompt to the pool of mutated prompts.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 5) #5fb236
- “LLM_as_mutator , we provide LLMs with predefined instructions on how to implement the prompt mutation.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 6) #2ea8e5
- “alter the prompts by substituting words with their synonyms (sim_words_as_mutator )” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 6) #2ea8e5
- “You are a mutation tool. This is a Python function and its description. Please change the description by enhancing its clarity and comprehensibility for sophisticated language models. Please put the changed description between #Explanation and #End. Use at most 600 words.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 6) #ffd400
*Sometimes LLMs even fail in producing outputs respecting the given number of words limit!?!?!?*
- “selected words” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 6) #ffd400
*What's the criteria that is used to select words to changed for mutating prompts? #question*
- “[21],” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 6) #ff6666
*It should be [3], isn't it?*
- “For a single problem, this metric estimates the probability that at least one of the top k samples is correct” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 7) #2ea8e5
- “(Pm − Pb ) × N” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 7) #ffd400
*The denominator of the ATSP equation can be 0, isn't it?*
- “Total token usage for method m and baseline b” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 7) #5fb236
- “pass@1” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 7) #5fb236
*So this is the probability that the first generated sample is correct.*
- “The goal of the EPiC framework is to optimize the fitness function F based on the provided test cases T by identifying the optimal input x within the prompt space X.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 7) #5fb236
- “their cost is not disproportionately high.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 7) #ffd400
*What do you mean? What's the threshold that you considered for this? #question*
- “baseline configurations” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 7) #ffd400
*Can you say something more about about the used baseline configurations? Are they coming from the original works and presented as those that permit the corresponding approaches at their best? #question*
- “To enable a fairer comparison among the agents, we adopted a consistent test generation approach to produce test cases rather than using the ground-truth tests for internal evaluation.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 8) #5fb236
- “For the ablation study in Section 6,” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 8) #ffd400
*The reference to the performed ablation study suddenly appears without a proper motivation and introduction.*
- “temperature of 0.0” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 8) #ffd400
*How this temperature setting is connected to the temperature value given as 0.6 for the initial population builder phase described in Sec 3.2.1? #question*
- “RQ1: How does EPiC perform across different SOTA LLMs?” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 8) #ffd400
*Do you have any estimation of the costs of the considered baselines? #question*
- “achieves higher functional correctness at the cost of increased token usage.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 8) #5fb236
- “RQ2: How does EPiC compare to other iterative-based agents?” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 9) #ffd400
*What is the LLM that is used to get the results shown in Table 3?*
- “To alleviate the threat, we have shown that the LLM-generated tests are not that far off from the results using the original (developer-written) tests.” (“Evolutionary prompt engineering for cost-effective code generation with large language models”, 2017, p. 10) #ffd400
*How can you be sure about that? #question*
COnsider that those that are tagget with #5fb236 are just highlights, those that are tagged with #e56eee and #a28ae5 are imporant 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 sentence to summarize the work
STRENGHTS:
WEAKNESSES:
COMMENTS: Organize the notes with respect to the following criteria:
-
`Novelty`
-
`Rigor`
-
`Relevance (of the contribution)`
-
`Verifiability and Transparency`
-
`Presentation`
And then add a Detailed Comments section to report the notets that contain issues or typos.
pages/@Extensions and Scalability Experiments of a Generic Model-Driven Architecture for Variability Model Reasoning.md
+14
View File
@@ -0,0 +1,14 @@
tags:: [[#zotero]]
date:: 2024
title:: @Extensions and Scalability Experiments of a Generic Model-Driven Architecture for Variability Model Reasoning
item-type:: [[journalArticle]]
original-title:: Extensions and Scalability Experiments of a Generic Model-Driven Architecture for Variability Model Reasoning
language:: en
authors:: [[Anonymous Author]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/5DGDNYBE), [Web library](https://www.zotero.org/users/1039502/items/5DGDNYBE)
- [[Abstract]]
- Until recently, the state-of-the-art of Software Product Line (SPL) configuration and verification automation consisted of a collection of ad-hoc approaches tightly coupling a single input Variability Modeling Language (VML) with a single constraint solver. To remedy this situation, a novel generic Model-Driven Architecture (MDA) was then proposed that enables using a variety of VMLs and solvers. The key ideas of this proposal were (a) the use of a standard logical language (CLIF) as a pivot between VMLs and solvers, and (b) the use of a standard data exchange format (JSON) to explicilty and declaratively specify the abstract syntax and semantics of the VMLs to be used in an SPL engineering project and the automated reasoning task to be performed by the solvers.
- ### Attachments
- [Author - 2024 - Extensions and Scalability Experiments of a Generic Model-Driven Architecture for Variability Model.pdf](zotero://select/library/items/JMZHRYHA) {{zotero-imported-file JMZHRYHA, "Author - 2024 - Extensions and Scalability Experiments of a Generic Model-Driven Architecture for Variability Model.pdf"}}
pages/@Extracting Domain Models from Textual Requirements in the Era of Large Language Models.md
+18
View File
@@ -0,0 +1,18 @@
date:: 2021
publisher:: IEEE
place:: "Fukuoka, Japan"
conference-name:: 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)
proceedings-title:: 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)
isbn:: 978-1-66542-484-4
title:: @Extracting Domain Models from Textual Requirements in the Era of Large Language Models
item-type:: [[conferencePaper]]
original-title:: Extracting Domain Models from Textual Requirements in the Era of Large Language Models
language:: en
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/TAWHGXLD), [Web library](https://www.zotero.org/users/1039502/items/TAWHGXLD)
-
- [[Abstract]]
- Conceptual models are essential in Software and Information Systems Engineering to meet many purposes since they explicitly represent the subject domains. Machine Learning (ML) approaches have recently been used in conceptual modeling to realize, among others, intelligent modeling assistance, model transformation, and metamodel classification. These works encode models in various ways, making the encoded models suitable for applying ML algorithms. The encodings capture the models’ structure and/or semantics, making this information available to the ML model during training. Therefore, the choice of the encoding for any ML-driven task is crucial for the ML model to learn the relevant contextual information. In this paper, we report findings from a systematic literature review which yields insights into the current research in machine learning for conceptual modeling (ML4CM). The review focuses on the various encodings used in existing ML4CM solutions and provides insights into i) which are the information sources, ii) how is the conceptual model’s structure and/or semantics encoded, iii) why is the model encoded, i.e., for which conceptual modeling task and, iv) which ML algorithms are applied. The results aim to structure the state of the art in encoding conceptual models for ML.
- [[Attachments]]
- [2021 - Extracting Domain Models from Textual Requirements.pdf](zotero://select/library/items/UZ9DR85K) {{zotero-imported-file UZ9DR85K, "2021 - Extracting Domain Models from Textual Requirements.pdf"}}
pages/@Fairness Testing%3A A Comprehensive Survey and Analysis of Trends.md
+12
View File
@@ -0,0 +1,12 @@
links:: [Local library](zotero://select/library/items/6XAJVIRN), [Web library](https://www.zotero.org/users/1039502/items/6XAJVIRN)
authors:: [[Zhenpeng Chen]], [[Jie M. Zhang]], [[Max Hort]], [[Federica Sarro]], [[Mark Harman]]
tags:: [[Computer Science - Software Engineering]], [[readingnotes]]
date:: [[05-08-2022]]
item-type:: [[preprint]]
title:: @Fairness Testing: A Comprehensive Survey and Analysis of Trends
- [[Abstract]]
- Software systems are vulnerable to fairness bugs and frequently exhibit unfair behaviors, making software fairness an increasingly important concern for software engineers. Research has focused on helping software engineers to detect fairness bugs automatically. This paper provides a comprehensive survey of existing research on fairness testing. We collect 122 papers and organise them based on the testing workflow (i.e., the testing activities) and the testing components (i.e., where to find fairness bugs) for conducting fairness testing. We also analyze the research focus, trends, promising directions, as well as widely-adopted datasets and open source tools for fairness testing.
- [[Attachments]]
- [arXiv.org Snapshot](https://arxiv.org/abs/2207.10223) {{zotero-imported-file YVM7VSIU, "2207.html"}}
- [Chen et al_2022_Fairness Testing.pdf](https://arxiv.org/pdf/2207.10223.pdf) {{zotero-imported-file PB2CLBM2, "Chen et al_2022_Fairness Testing.pdf"}}
pages/@FloWare%3A a model-driven approach fostering reuse and customisation in IoT applications modelling and development.md
+23
View File
@@ -0,0 +1,23 @@
date:: 02/2023
issn:: "1619-1366, 1619-1374"
issue:: 1
doi:: 10.1007/s10270-022-01026-9
title:: @FloWare: a model-driven approach fostering reuse and customisation in IoT applications modelling and development
pages:: 131-158
volume:: 22
item-type:: [[journalArticle]]
access-date:: 2023-05-17T09:31:45Z
original-title:: FloWare: a model-driven approach fostering reuse and customisation in IoT applications modelling and development
language:: en
url:: https://link.springer.com/10.1007/s10270-022-01026-9
short-title:: FloWare
publication-title:: Software and Systems Modeling
journal-abbreviation:: Softw Syst Model
authors:: [[Flavio Corradini]], [[Arianna Fedeli]], [[Fabrizio Fornari]], [[Andrea Polini]], [[Barbara Re]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/CU54PZIA), [Web library](https://www.zotero.org/users/1039502/items/CU54PZIA)
- [[Abstract]]
- The relevance of IoT-based solutions in everyday life is continuously increasing. The capability to sense the world, activate computation based on data gathered by sensors, and possibly produce reactions on the world itself results in an almost neverending identification of novel IoT solutions and application scenarios. Nonetheless, IoT’s intrinsic nature, which includes a high degree of variability in used devices, data formats, resources, and communication protocols, complicates the design, development, reuse and customisation of IoT-based software systems. In addition, customers require personalised solutions strongly based on their specific requirements. Reducing the complexity of building customised solutions and increasing the reusability of developed artefacts are among the topmost challenges for enterprises and IoT application developers. Upon these challenges, we propose a model-driven approach organising the modelling and development of IoT applications in different steps, handling the complexity in representing the IoT domain variability, and empowering the reusability of design decisions and artefacts to simplify the derivation of customised IoT applications. Our proposal is named FloWare. It follows the typical path of an MDE solution, providing modelling support through feature models to fully represent and handle the possible variability of devices in a specific IoT application domain. Once a specific configuration has been selected, this will be complemented with specific information about the deployment context to automatically derive fragments of the IoT applications, that will be successively combined by the developer within a low-code development environment. The approach is fully supported by a toolchain that has been released for public use.
- [[Attachments]]
- [Corradini et al. - 2023 - FloWare a model-driven approach fostering reuse a.pdf](zotero://select/library/items/NWMS5M5W) {{zotero-imported-file NWMS5M5W, "Corradini et al. - 2023 - FloWare a model-driven approach fostering reuse a.pdf"}}
pages/@Form_valutazione_tesi_Phd - arianna fedeli.pdf.md
+11
View File
@@ -0,0 +1,11 @@
tags:: [[#zotero]]
title:: @Form_valutazione_tesi_Phd - arianna fedeli.pdf
item-type:: [[document]]
original-title:: Form_valutazione_tesi_Phd - arianna fedeli.pdf
language:: en
links:: [Local library](zotero://select/library/items/RZNL8TGY), [Web library](https://www.zotero.org/users/1039502/items/RZNL8TGY)
-
- ### Attachments
- [Form_valutazione_tesi_Phd - Arianna Fedeli.pdf.pdf](zotero://select/library/items/7U72736Z) {{zotero-imported-file 7U72736Z, "Form_valutazione_tesi_Phd - Arianna Fedeli.pdf.pdf"}}
- [Form_valutazione_tesi_Phd.docx](zotero://select/library/items/A3KWTBS6) {{zotero-imported-file A3KWTBS6, "Form_valutazione_tesi_Phd.docx"}}
pages/@From Today’s Code to Tomorrow’s Symphony%3A The AI Transformation of Developer’s Routine by 2030.md
+14
View File
@@ -0,0 +1,14 @@
tags:: [[#zotero]]
date:: 2030
title:: @From Today’s Code to Tomorrow’s Symphony: The AI Transformation of Developer’s Routine by 2030
item-type:: [[journalArticle]]
original-title:: From Today’s Code to Tomorrow’s Symphony: The AI Transformation of Developer’s Routine by 2030
language:: en
authors:: [[Matteo Ciniselli]], [[Niccolò Puccinelli]], [[Ketai Qiu]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/AMM4PA3K), [Web library](https://www.zotero.org/users/1039502/items/AMM4PA3K)
- [[Abstract]]
- In the rapidly evolving landscape of software engineering, the integration of Artificial Intelligence (AI) into the Software Development Life-Cycle (SDLC) heralds a transformative era for developers. Recently, we have assisted to a pivotal shift towards AI-assisted programming, exemplified by tools like GitHub Copilot and OpenAI’s ChatGPT, which have become a crucial element for coding, debugging, and software design. In this paper we provide a comparative analysis between the current state of AI-assisted programming in 2024 and our projections for 2030, by exploring how AI advancements are set to enhance the implementation phase, fundamentally altering developers’ roles from manual coders to orchestrators of AI-driven development ecosystems. We envision HyperAssistant, an augmented AI tool that offers comprehensive support to 2030 developers, addressing current limitations in mental health support, fault detection, code optimization, team interaction, and skill development. We emphasize AI as a complementary force, augmenting developers’ capabilities rather than replacing them, leading to the creation of sophisticated, reliable, and secure software solutions. Our vision seeks to anticipate the evolution of programming practices, challenges, and future directions, shaping a new paradigm where developers and AI collaborate more closely, promising a significant leap in SE efficiency, security and creativity.
- ### Attachments
- [Ciniselli et al. - 2030 - From Today’s Code to Tomorrow’s Symphony The AI Transformation of Developer’s Routine by 2030.pdf](zotero://select/library/items/UIIVP222) {{zotero-imported-file UIIVP222, "Ciniselli et al. - 2030 - From Today’s Code to Tomorrow’s Symphony The AI Transformation of Developer’s Routine by 2030.pdf"}}
pages/@GRuM – A Flexible Model-Driven Runtime Monitoring Framework and its Application to Automated Aerial and Ground Vehicls.md
+10
View File
@@ -0,0 +1,10 @@
tags:: [[#zotero]]
title:: @GRuM – A Flexible Model-Driven Runtime Monitoring Framework and its Application to Automated Aerial and Ground Vehicls
item-type:: [[document]]
original-title:: GRuM – A Flexible Model-Driven Runtime Monitoring Framework and its Application to Automated Aerial and Ground Vehicls
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"}}
- [logseq://graph/Logseq?page=%40JSSOFTWARE-D-22-00977_reviewer.pdf](logseq://graph/Logseq?page=%40JSSOFTWARE-D-22-00977_reviewer.pdf)
pages/@Generating customized low-code development platforms for digital twins.md
+21
View File
@@ -0,0 +1,21 @@
date:: 06/2022
issn:: 25901184
doi:: 10.1016/j.cola.2022.101117
title:: @Generating customized low-code development platforms for digital twins
pages:: 101117
volume:: 70
item-type:: [[journalArticle]]
access-date:: 2023-05-17T09:25:37Z
original-title:: Generating customized low-code development platforms for digital twins
language:: en
url:: https://linkinghub.elsevier.com/retrieve/pii/S2590118422000235
publication-title:: Journal of Computer Languages
journal-abbreviation:: Journal of Computer Languages
authors:: [[Manuela Dalibor]], [[Malte Heithoff]], [[Judith Michael]], [[Lukas Netz]], [[Jérôme Pfeiffer]], [[Bernhard Rumpe]], [[Simon Varga]], [[Andreas Wortmann]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/2G9ZM7Q5), [Web library](https://www.zotero.org/users/1039502/items/2G9ZM7Q5)
- [[Abstract]]
- A digital twin improves our use of a cyber–physical system and understanding of its emerging behavior. To this effect, a digital twin is to be developed and configured and potentially also operated by domain experts, who rarely have a professional software engineering background and for whom easy access and support, e.g., in form of low-code platforms are missing. In this paper, we report on an integrated method for the modeldriven engineering of low-code development platforms for digital twins that enables domain experts to create and operate digital twins for cyber–physical systems using the most appropriate modeling languages. The foundation of this method is (1) a code generation infrastructure for information systems combined with (2) an extensible base architecture for self-adaptive digital twins and (3) reusable language components for their configuration. Using this method, software engineers first configure the information system with the required modeling languages to generate the low-code development platform for digital twins before domain experts leverage the generated platform to create digital twins. This two-step method facilitates creating tailored low-code development platforms as well as creating and operating customized digital twins for a variety of applications.
- [[Attachments]]
- [Dalibor et al. - 2022 - Generating customized low-code development platfor.pdf](zotero://select/library/items/GNUXUQ5P) {{zotero-imported-file GNUXUQ5P, "Dalibor et al. - 2022 - Generating customized low-code development platfor.pdf"}}
pages/@Handbook on Artificial Intelligence-Empowered Applied Software Engineering%3A VOL.1%3A Novel Methodologies to Engineering Smart Software Systems.md
+24
View File
@@ -0,0 +1,24 @@
links:: [Local library](zotero://select/library/items/YDBUAGAA), [Web library](https://www.zotero.org/users/1039502/items/YDBUAGAA)
library-catalog:: DOI.org (Crossref)
authors:: João Ricardo Lourenço, Bruno Cabral, Paulo Carreiro, Marco Vieira, Jorge Bernardino
journal-abbreviation:: Journal of Big Data
publication-title:: Journal of Big Data
short-title:: Choosing the right NoSQL database for the job
url:: https://journalofbigdata.springeropen.com/articles/10.1186/s40537-015-0025-0
language:: en
original-title:: Choosing the right NoSQL database for the job: a quality attribute evaluation
access-date:: 2021-02-06T16:43:44Z
item-type:: [[journalArticle]]
volume:: 2
pages:: 18
title:: @Choosing the right NoSQL database for the job: a quality attribute evaluation
doi:: 10.1186/s40537-015-0025-0
extra:: 00120
issue:: 1
issn:: 2196-1115
date:: 12/2015
tags:: TYPHONML, #Highlights
- [[Attachments]]
- [Lourenço et al_2015_Choosing the right NoSQL database for the job.pdf](https://journalofbigdata.springeropen.com/track/pdf/10.1186/s40537-015-0025-0) {{zotero-imported-file EYEUBGCW, "Lourenço et al_2015_Choosing the right NoSQL database for the job.pdf"}}
-
pages/@ICSOFT_2025_34.md
+13
View File
@@ -0,0 +1,13 @@
tags:: [[/unread]], [[#zotero]]
title:: @ICSOFT_2025_34
item-type:: [[journalArticle]]
original-title:: ICSOFT_2025_34
language:: en
authors:: [[Reinhold Plösch]], [[Florian Ernst]], [[Matthias Saft]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/SA3WKFXB), [Web library](https://www.zotero.org/users/1039502/items/SA3WKFXB)
- [[Abstract]]
- The starting point for this paper and service for the query-based generation of quality models was the requirement to be able to manage software quality models dynamically, as detailed domain knowledge is usually required for this task. We present new approaches regarding the query-based generation of software quality models and the creation of profiles for quality analyses using the code quality tool SonarQube. Furthermore, our support for the automatic assignment of software quality rules to entries of a hierarchical quality model simplifies the maintenance of the models with the help of machine learning models and large language models (HMCN and SciBERT in our case). The resulting findings were evaluated for their practical suitability using expert interviews. The results are promising and show that semantic management of quality models could help spreading the use of quality models, as it considerably reduces the maintenance effort.
- ### Attachments
- [PDF](zotero://select/library/items/KYQLJ9PU) {{zotero-imported-file KYQLJ9PU, "Plösch et al. - Automated Quality Model Management Using Semantic Technologies.pdf"}}
pages/@ICSOFT_2025_73.md
+139
View File
@@ -0,0 +1,139 @@
tags:: [[/unread]], [[#zotero]]
title:: @ICSOFT_2025_73
item-type:: [[document]]
original-title:: ICSOFT_2025_73
links:: [Local library](zotero://select/library/items/L7XRE7S5), [Web library](https://www.zotero.org/users/1039502/items/L7XRE7S5)
- ### Attachments
- [PDF](zotero://select/library/items/4X6W69N5) {{zotero-imported-file 4X6W69N5, "ICSOFT_2025_73.pdf"}}
- ### Notes
- # Annotazioni
(1/4/2025, 11:33:27)
- “IT Project Documentation Elements” (“ICSOFT_2025_73”, p. 1) #5fb236
* *
- “Model Transformation Chai” (“ICSOFT_2025_73”, p. 1) #5fb236
* *
- “define requirements, establish goals, and mitigate risks.” (“ICSOFT_2025_73”, p. 1) #a28ae5
* *
- “we proposed a model transformation chain to facilitate the generation of IT project artefacts, which are offered as a solution in last 5 years scientific papers” (“ICSOFT_2025_73”, p. 1) #a28ae5
* *
- “structured from the transformation chain more detailed representation.” (“ICSOFT_2025_73”, p. 1) #ff6666
* *
- “In the early stages of an IT project, well-structured documentation is particularly essential, as it guides stakeholders in defining requirements, establishing goals, and mitigating risks before implementation begins.” (“ICSOFT_2025_73”, p. 1) #5fb236
* *
- “Furthermore, IT project documentation must adhere to established standards and best practices to ensure consistency, completeness, and usability across different stakeholders and project phases.” (“ICSOFT_2025_73”, p. 1) #5fb236
* *
- “Compliance with standar” (“ICSOFT_2025_73”, p. 1) #ff6666
* *
- “By aligning documentation with recognized frameworks, organizations can improve collaboration, ensure regulatory compliance, and streamline project execution.” (“ICSOFT_2025_73”, p. 1) #5fb236
* *
- “we introduced a model transformation chain designed to facilitate the generation of IT project artefacts” (“ICSOFT_2025_73”, p. 1) #5fb236
* *
- “Solutions published in 133 studies offering IT project elements obtaining with principles of model-driven elements obtaining with principles of model-driven engineering, machine learning and generative engineering, machine learning and generative artificial intelligence, learning and generative artificial intelligence, as well as and generative artificial intelligence, as well as manual practices, artificial intelligence, as well as manual practices, were mapped into artefacts used in the initial stages were mapped into artefacts used in the initial stages of IT project identified in (Nikiforova et al., 2025a). of IT project identified in (Nikiforova et al., 2025a). This transformation chain provides a” (“ICSOFT_2025_73”, p. 1) #ffd400
*what kinds of solutions are you talking about? *
- “ensuring alignme” (“ICSOFT_2025_73”, p. 1) #ffd400
*how? what does it mean/imply from a technical point of view? *
- “This paper follows our previous work by focusing on the extraction and structuring of IT project on the extraction and structuring of IT project documentation elements as mapping of them into the documentation elements as mapping of them into the created model transformation chain. We explore the created model transformation chain. We explore the elements of documentation that can be derived, the elements of documentation that can be derived, the methodologies employed to extract relevant methodologies employed to extract relevant information, employed to extract relevant information, and the to extract relevant information, and the benefits extract relevant information, and the benefits of relevant information, and the benefits of integrating this information, and the benefits of integrating this approach into IT project management practices. approach into IT project management practices. Through this study, we aim to provide a systematic” (“ICSOFT_2025_73”, p. 2) #ffd400
*At this stage the goal of the paper is vaguous and general. What are the limitations and challenges that you want to address? *
- “Agile IT project life cycle and IT Project Management Plan project life cycle and IT Project Management Plan structure, which is used for mapping in the next structure, which is used for mapping in the next section. Section 4 specify the fragments of the sectio” (“ICSOFT_2025_73”, p. 2) #ffd400
*These are suddenly mentioned without any introduction! *
- “However, challenges such as contextual ambiguity challenges such as contextual ambiguity (AI and such as contextual ambiguity (AI and NLP-based as contextual ambiguity (AI and NLP-based techniques struggle to ambiguity (AI and NLP-based techniques struggle to fully understand context-dependent requirements), fully understand context-dependent requirements), domain-specific variations, and the need for domain-specific variations, and the need for large, labelled datasets make it difficult to achieve labelled datasets make it difficult to achieve fully automated and error-free documentation extraction. automated and error-free documentation extraction. Model-driven development (MDD) offers a” (“ICSOFT_2025_73”, p. 2) #ffd400
*I think there is some recent work employing LLMs for code generation. It is necessary to compare the proposed approach with some baseline (not necessarily based on LLMs) to highlight the novelty of what has been presented here. *
- “Automated tools such as Papyrus, MagicDraw, and Enterprise Architect facilitate the extraction of textual Enterprise Architect facilitate the extraction of textual documentation from models, reducing manual effort documentation from models, reducing manual effort and improving accuracy. However, different and improving accuracy. However, different documentation accuracy. However, different documentation tools and methodologies different documentation tools and methodologies often lack documentation tools and methodologies often lack seamless seamless integration. Ensuring” (“ICSOFT_2025_73”, p. 2) #ffd400
*These are old statements / tools. *
- “The primary goal is to capture the essence of the product and its goal is to capture the essence of the product and its intended value, rather than producing exhaustive intended value, rather than producing exhaustive documentation (Pasuksmit et al., 2021). This documentation (Pasuksmit et al., 2021). This approach” (“ICSOFT_2025_73”, p. 3) #5fb236
* *
- “Key agile artefacts produced during these early stages include the product vision and roadmap” (“ICSOFT_2025_73”, p. 3) #5fb236
* *
- “These artefacts are typically maintained in collaborative tools like Jira or Trello, allowing for continuous refinement and adaptation.” (“ICSOFT_2025_73”, p. 3) #ffd400
*???? *
- “MODEL TRANSFORMATION CHAIN FOR IT PROJECT INITIATION ARTEFACTS” (“ICSOFT_2025_73”, p. 4) #5fb236
* *
- “In this article, we take and examine in more detail a fragment of this large chain that related to project documentation artefacts according to the IT Project Management Plan.” (“ICSOFT_2025_73”, p. 4) #5fb236
* *
- “chain fragment for Scope Management” (“ICSOFT_2025_73”, p. 4) #5fb236
* *
- “The rest of subsections demonstrates only transformation chain types” (“ICSOFT_2025_73”, p. 4) #5fb236
* *
- “This transformation is performed manually” (“ICSOFT_2025_73”, p. 6) #5fb236
* *
- “automation should be combined with manual work of stakeholders, where they select the corresponding use cases to be the user stories for implementation and prioritize them” (“ICSOFT_2025_73”, p. 6) #5fb236
* *
- “Obtaining consistent and well-structured IT project documentation is a continuous challenge for project managers and developers’ team due to the complexity and evolving nature of project artefacts.” (“ICSOFT_2025_73”, p. 7) #ffd400
*Indeed this is a relevant and difficult problem. However, the paper touches the problem in a generic an vaguous manner. Further than exploring some stepts of the required model refinements and transformation process, it's not clear e.g. how the mentioned transformations are actually implemented, orchestrated, chained. Chaining model transformations is critical problem and there are existing work that authors have not mentioned at all. *
pages/@IEEE COMPUTING EDGE.md
+23
View File
@@ -0,0 +1,23 @@
tags:: [[readingnotes]]
date:: 11/2022
issn:: "0740-7459, 1937-4194"
issue:: 6
doi:: 10.1109/MS.2022.3210313
title:: @IEEE COMPUTING EDGE
pages:: C2-C2
volume:: 39
item-type:: [[journalArticle]]
access-date:: 2022-11-09T16:17:29Z
original-title:: IEEE COMPUTING EDGE
language:: en
url:: https://ieeexplore.ieee.org/document/9928236/
publication-title:: IEEE Software
journal-abbreviation:: IEEE Softw.
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/2AUVYDBP), [Web library](https://www.zotero.org/users/1039502/items/2AUVYDBP)
- [[Attachments]]
- [2022 - IEEE COMPUTING EDGE.pdf](https://csdl-downloads.ieeecomputer.org/mags/so/2022/06/mso202206.issue.pdf?Expires=1668010639&Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly9jc2RsLWRvd25sb2Fkcy5pZWVlY29tcHV0ZXIub3JnL21hZ3Mvc28vMjAyMi8wNi9tc28yMDIyMDYuaXNzdWUucGRmIiwiQ29uZGl0aW9uIjp7IkRhdGVMZXNzVGhhbiI6eyJBV1M6RXBvY2hUaW1lIjoxNjY4MDEwNjM5fX19XX0_&Signature=sXtzqPw8E8f3j~BJLVRSS2lDWcI1al0X65zk27-xS9G6oU3XVkeqWmJt7yH~KYPX9gyIY1QUZr4jkEaYAST5VkCKwyULIjqlfeL4Fnqn-Wwv~R1Z8q7gBZa9av1lCH8GYmxOGLtxHZ5Yjir4ZzKkT4TBWUM82PAjNoixpC7vCjyGmI~xnvk6BW8cEjqRfKRv84l0hlCe75O~3MQdM2cOC~UwCbWUVFxCkMo5IiKN~F7hpQlfMFlDm8H2F1gN5wFh6skBY8I7GlFPSMzgIP84kP3Y8KlBSwCM4gijdAukVWY3-mooBeLiLCP6slJtXERdpWhpRVqqXUQzogDh5ctk1g__&Key-Pair-Id=K12PMWTCQBDMDT) {{zotero-imported-file ZE5KJ3YM, "2022 - IEEE COMPUTING EDGE.pdf"}}
- [[Highlights]]
-
-
pages/@In Search of the Essence of Low-Code%3A An Exploratory Study of Seven Development Platforms.md
+23
View File
@@ -0,0 +1,23 @@
date:: 10/2021
publisher:: IEEE
place:: "Fukuoka, Japan"
conference-name:: 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)
proceedings-title:: 2021 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C)
isbn:: 978-1-66542-484-4
doi:: 10.1109/MODELS-C53483.2021.00016
title:: @In Search of the Essence of Low-Code: An Exploratory Study of Seven Development Platforms
pages:: 57-66
item-type:: [[ConferencePaper]]
access-date:: 2023-05-17T09:26:27Z
original-title:: In Search of the Essence of Low-Code: An Exploratory Study of Seven Development Platforms
language:: en
url:: https://ieeexplore.ieee.org/document/9643620/
short-title:: In Search of the Essence of Low-Code
authors:: [[Alexander C. Bock]], [[Ulrich Frank]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/GEVNKRIF), [Web library](https://www.zotero.org/users/1039502/items/GEVNKRIF)
- [[Abstract]]
- Rapidly growing attention has been directed in recent years toward a type of software development and execution environment now passing under the name of ‘low-code development platforms.’ The fundamental claim is that limiting traditional coding mechanisms in favor of a variety of alternative means of design and specification yields substantial efficiency gains in professional and private software development. But although much stir at present surrounds low-code development platforms, it is by no means clear what, if any, features are distinctive of these systems, and whether any of these features mark out a technology which can be considered original. This paper presents an exploratory study of seven low-code development platforms, with the aim of discovering their essence and assessing them critically in the light of research in information systems development. An analysis framework covering a number of criteria regarding professional information systems development is used to characterize the selected platforms, and to point out features commonly, occasionally, and rarely possessed by them. The study reveals that hardly any features of low-code development are innovative in and of themselves, with novelty primarily consisting in their combination and integration. Still, we argue in conclusion, a number of research opportunities can be made out with an eye on the leitmotif of low-code development.
- [[Attachments]]
- [Bock e Frank - 2021 - In Search of the Essence of Low-Code An Explorato.pdf](zotero://select/library/items/7Q7NM984) {{zotero-imported-file 7Q7NM984, "Bock e Frank - 2021 - In Search of the Essence of Low-Code An Explorato.pdf"}}
pages/@Integrating Hardware in the Loop into IoT Systems Simulations%3A A Model-Driven Development Approach.md
+13
View File
@@ -0,0 +1,13 @@
tags:: [[#zotero]]
title:: @Integrating Hardware in the Loop into IoT Systems Simulations: A Model-Driven Development Approach
item-type:: [[journalArticle]]
original-title:: Integrating Hardware in the Loop into IoT Systems Simulations: A Model-Driven Development Approach
language:: en
authors:: [[Jose A Barriga]], [[Pablo Alonso]], [[Encarna Sosa-Sanchez]], [[Miguel A Perez-Toledano]], [[Pedro J Clemente]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/KASZNVPZ), [Web library](https://www.zotero.org/users/1039502/items/KASZNVPZ)
- [[Abstract]]
- Given the high heterogeneity, complexity and expensive nature of Internet of Things (IoT) environments, their scenarios are usually simulated before they are developed and deployed. However, current simulation tools and the underlying models on which these simulators are based often present significant variations between simulated results and real-life assessments. To address this challenge, the Hardware in the Loop (HiL) technique has been employed over time. HiL involves integrating actual hardware into a simulated environment, thereby creating a hybrid system that combines both simulated and physical components. As a layer composed of real hardware, sensitive devices that need to be accurately assessed can be deployed in the same way as they would be in the final system, leading to more reliable results than those purely based on mathematical simulation models. In this study, a model-driven IoT simulator, SimulateIoT, has been extended to incorporate HiL for realistic test scenarios. During this work, a comprehensive analysis of the novel combination of Model-Driven Development (MDD) and HiL techniques for simulating IoT systems has also been undertaken. Finally, to validate the applicability of the proposal, an excerpt of an IoT system based on a generic smart building is presented.
- ### Attachments
- [Barriga et al. - Integrating Hardware in the Loop into IoT Systems Simulations A Model-Driven Development Approach.pdf](zotero://select/library/items/T76DLWLW) {{zotero-imported-file T76DLWLW, "Barriga et al. - Integrating Hardware in the Loop into IoT Systems Simulations A Model-Driven Development Approach.pdf"}}
pages/@IoTMoF%3A A Requirements-Driven Modelling Framework for Adaptive IoT Systems.md
+26
View File
@@ -0,0 +1,26 @@
title:: @IoTMoF: A Requirements-Driven Modelling Framework for Adaptive IoT Systems
item-type:: [[journalArticle]]
original-title:: IoTMoF: A Requirements-Driven Modelling Framework for Adaptive IoT Systems
language:: en
authors:: [[Paul Boutot]], [[Sadaf Mustafiz]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/PG2F7JZ5), [Web library](https://www.zotero.org/users/1039502/items/PG2F7JZ5)
-
- [[Attachments]]
- [Boutot e Mustafiz - IoTMoF A Requirements-Driven Modelling Framework .pdf](zotero://select/library/items/PAUWRAG9) {{zotero-imported-file PAUWRAG9, "Boutot e Mustafiz - IoTMoF A Requirements-Driven Modelling Framework .pdf"}}
- tags:: [[#zotero]]
title:: @IoTMoF: A Requirements-Driven Modelling Framework for Adaptive IoT Systems
item-type:: [[journalArticle]]
original-title:: IoTMoF: A Requirements-Driven Modelling Framework for Adaptive IoT Systems
language:: en
authors:: [[Paul Boutot]], [[Sadaf Mustafiz]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/PG2F7JZ5), [Web library](https://www.zotero.org/users/1039502/items/PG2F7JZ5)
- ### Attachments
- [Boutot e Mustafiz - IoTMoF A Requirements-Driven Modelling Framework .pdf](zotero://select/library/items/PAUWRAG9) {{zotero-imported-file PAUWRAG9, "Boutot e Mustafiz - IoTMoF A Requirements-Driven Modelling Framework .pdf"}}
- # Annotazioni  
(14/1/2024, 22:55:13)
“he engineering of IoT systems brings about various challenges due to the inherent complexities associated with such adaptive systems.” ([Boutot e Mustafiz, p. 1](zotero://select/library/items/PG2F7JZ5)) ([pdf](zotero://open-pdf/library/items/PAUWRAG9?page=1&annotation=ZAZV859U)) This is a test to check how notes are managed by LogSeq
pages/@It’s a Matter of Style%3A Detecting Social Bots through Writing Style Consistency.md
+25
View File
@@ -0,0 +1,25 @@
tags:: [[#zotero]]
date:: 7/2021
publisher:: IEEE
place:: "Athens, Greece"
conference-name:: 2021 International Conference on Computer Communications and Networks (ICCCN)
proceedings-title:: 2021 International Conference on Computer Communications and Networks (ICCCN)
isbn:: 978-1-66541-278-0
doi:: 10.1109/ICCCN52240.2021.9522339
title:: @It’s a Matter of Style: Detecting Social Bots through Writing Style Consistency
pages:: 1-9
item-type:: [[conferencePaper]]
access-date:: 2024-02-21T12:04:49Z
original-title:: It’s a Matter of Style: Detecting Social Bots through Writing Style Consistency
language:: en
url:: https://ieeexplore.ieee.org/document/9522339/
short-title:: It’s a Matter of Style
authors:: [[Matteo Cardaioli]], [[Mauro Conti]], [[Andrea Di Sorbo]], [[Enrico Fabrizio]], [[Sonia Laudanna]], [[Corrado A. Visaggio]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/NLQQ48LE), [Web library](https://www.zotero.org/users/1039502/items/NLQQ48LE)
-
- [[Abstract]]
- Social bots are computer algorithms able to produce content and interact with other users on social media autonomously, trying to emulate and possibly influence humans’ behavior. Indeed, bots are largely employed for malicious purposes, like spreading disinformation and conditioning electoral campaigns. Nowadays, bots’ capability of emulating human behaviors has become increasingly sophisticated, making their detection harder. In this paper, we aim at recognizing bot-driven accounts by evaluating the consistency of users’ writing style over time. In particular, we leverage the intuition that while bots compose posts according to fairly deterministic processes, humans are influenced by subjective factors (e.g., emotions) that can alter their writing style. To verify this assumption, by using stylistic consistency indicators, we characterize the writing style of more than 12,000 among bot-driven and human-operated Twitter accounts and find that statistically significant differences can be observed between the different types of users. Thus, we evaluate the effectiveness of different machine learning (ML) algorithms based on stylistic consistency features in discerning between human-operated and bot-driven Twitter accounts and show that the experimented ML algorithms can achieve high performance (i.e., F-measure values up to 98%) in social bot detection tasks.
- ### Attachments
- [Cardaioli et al. - 2021 - It’s a Matter of Style Detecting Social Bots thro.pdf](zotero://select/library/items/LQLKJIZ3) {{zotero-imported-file LQLKJIZ3, "Cardaioli et al. - 2021 - It’s a Matter of Style Detecting Social Bots thro.pdf"}}
pages/@JSSOFTWARE-D-23-01182R1.md
+9
View File
@@ -0,0 +1,9 @@
links:: [Local library](zotero://select/library/items/PKK92D6W), [Web library](https://www.zotero.org/users/1039502/items/PKK92D6W)
authors:: [[Xiao He]], [[Tao Zan]]
tags:: [[⛔ No INSPIRE recid found]], [[#zotero]]
date:: 2024
item-type:: [[preprint]]
title:: @JSSOFTWARE-D-23-01182R1
- ### Attachments
- [He e Zan - 2024 - Bit a template-based approach to incremental and bidirectional model-to-text transformation.pdf](zotero://select/library/items/4F7TTNIZ) {{zotero-imported-file 4F7TTNIZ, "He e Zan - 2024 - Bit a template-based approach to incremental and bidirectional model-to-text transformation.pdf"}}
pages/@JSSOFTWARE-D-24-00320_reviewer.pdf.md
+9
View File
@@ -0,0 +1,9 @@
tags:: [[⛔ No INSPIRE recid found]], [[#zotero]]
title:: @JSSOFTWARE-D-24-00320_reviewer.pdf
item-type:: [[document]]
original-title:: JSSOFTWARE-D-24-00320_reviewer.pdf
language:: en
links:: [Local library](zotero://select/library/items/AUC6ZP72), [Web library](https://www.zotero.org/users/1039502/items/AUC6ZP72)
- ### Attachments
- [JSSOFTWARE-D-24-00320_reviewer.pdf](zotero://select/library/items/L9JTAQSZ) {{zotero-imported-file L9JTAQSZ, "JSSOFTWARE-D-24-00320_reviewer.pdf"}}
pages/@JSSOFTWARE-D-24-00573.md
+8
View File
@@ -0,0 +1,8 @@
tags:: [[#zotero]]
title:: @JSSOFTWARE-D-24-00573
item-type:: [[document]]
original-title:: JSSOFTWARE-D-24-00573
links:: [Local library](zotero://select/library/items/N57A695Z), [Web library](https://www.zotero.org/users/1039502/items/N57A695Z)
- ### Attachments
- [File PDF](zotero://select/library/items/CIE8SI7Y) {{zotero-imported-file CIE8SI7Y, "JSSOFTWARE-D-24-00573.pdf"}}
pages/@Large Language Models for Software Engineering%3A Survey and Open Problems.md
+13
View File
@@ -0,0 +1,13 @@
links:: [Local library](zotero://select/library/items/C6XDG4BZ), [Web library](https://www.zotero.org/users/1039502/items/C6XDG4BZ)
authors:: [[Angela Fan]], [[Beliz Gokkaya]], [[Mark Harman]], [[Mitya Lyubarskiy]], [[Shubho Sengupta]], [[Shin Yoo]], [[Jie M. Zhang]]
tags:: [[Computer Science - Software Engineering]], [[#zotero]]
date:: [[11-11-2023]]
item-type:: [[preprint]]
title:: @Large Language Models for Software Engineering: Survey and Open Problems
-
- [[Abstract]]
- This paper provides a survey of the emerging area of Large Language Models (LLMs) for Software Engineering (SE). It also sets out open research challenges for the application of LLMs to technical problems faced by software engineers. LLMs' emergent properties bring novelty and creativity with applications right across the spectrum of Software Engineering activities including coding, design, requirements, repair, refactoring, performance improvement, documentation and analytics. However, these very same emergent properties also pose significant technical challenges; we need techniques that can reliably weed out incorrect solutions, such as hallucinations. Our survey reveals the pivotal role that hybrid techniques (traditional SE plus LLMs) have to play in the development and deployment of reliable, efficient and effective LLM-based SE.
- ### Attachments
- [Fan et al_2023_Large Language Models for Software Engineering.pdf](https://arxiv.org/pdf/2310.03533.pdf) {{zotero-imported-file GQ7C92KJ, "Fan et al_2023_Large Language Models for Software Engineering.pdf"}}
- [arXiv.org Snapshot](https://arxiv.org/abs/2310.03533) {{zotero-imported-file 6Q7KEGCZ, "2310.html"}}
pages/@Launch of New Journal JSEAS.md
+18
View File
@@ -0,0 +1,18 @@
date:: [[23-01-2023]]
issn:: 2949-9372
extra:: Publisher: Athena Publishing
doi:: 10.55060/j.jseas.230123.001
title:: @Launch of New Journal JSEAS
item-type:: [[journalArticle]]
access-date:: 2023-09-28T10:45:15Z
original-title:: Launch of New Journal JSEAS
language:: en
url:: https://www.athena-publishing.com/journals/jseas/articles/192
publication-title:: Journal of Software Engineering for Autonomous Systems
authors:: [[Mark van den Brand]], [[Yanja Dajsuren]], [[Arash Saberi]]
library-catalog:: www.athena-publishing.com
links:: [Local library](zotero://select/library/items/V5LUXZQM), [Web library](https://www.zotero.org/users/1039502/items/V5LUXZQM)
-
- [[Attachments]]
- [Brand et al_2023_Launch of New Journal JSEAS.pdf](https://files.athena-publishing.com/article/192.pdf) {{zotero-imported-file ZJE6Z53I, "Brand et al_2023_Launch of New Journal JSEAS.pdf"}}
pages/@Leveraging LLMs to support co-evolution between definitions and instances of textual DSLs.md
+13
View File
@@ -0,0 +1,13 @@
tags:: [[/unread]], [[#zotero]]
title:: @Leveraging LLMs to support co-evolution between definitions and instances of textual DSLs
item-type:: [[journalArticle]]
original-title:: Leveraging LLMs to support co-evolution between definitions and instances of textual DSLs
language:: en
authors:: [[Weixing Zhang]], [[Regina Hebig]], [[Daniel Strüber]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/WXD635PK), [Web library](https://www.zotero.org/users/1039502/items/WXD635PK)
- [[Abstract]]
- Software languages evolve over time for various reasons, such as the addition of new features. When the language’s grammar definition evolves, textual instances that originally conformed to the grammar become outdated. For DSLs in a model-driven engineering context, there exists a plethora of techniques to co-evolve models with the evolving metamodel. However, these techniques are not geared to support DSLs with a textual syntax — applying them to textual language definitions and instances may lead to the loss of information from the original instances, such as comments and layout information, which are valuable for software comprehension and maintenance. This study explores the potential of Large Language Model (LLM)-based solutions in achieving grammar and instance co-evolution, with attention to their ability to preserve auxiliary information when directly processing textual instances. By applying two advanced language models, Claude-3.5 and GPT-4o, and conducting experiments across seven case languages, we evaluated the feasibility and limitations of this approach. Our results indicate a good ability of the considered LLMs for migrating textual instances in small-scale cases, which are representative of a subset of cases encountered in practice, where DSLs are often conceived as “small languages“ for specialized problems. In addition, we observe significant challenges with the scalability of LLM-based solutions to larger languages and instances, leading to insights that are useful for informing future research.
- ### Attachments
- [PDF](zotero://select/library/items/ARU4CMTH) {{zotero-imported-file ARU4CMTH, "Zhang et al. - Leveraging LLMs to support co-evolution between definitions and instances of textual DSLs.pdf"}}
pages/@Low-Code Is Often High-Code, So We Must Design Low-Code Platforms to Enable Proper Software Engineering.md
+21
View File
@@ -0,0 +1,21 @@
date:: 2021
publisher:: Springer International Publishing
place:: Cham
isbn:: 978-3-030-89158-9 978-3-030-89159-6
title:: @Low-Code Is Often High-Code, So We Must Design Low-Code Platforms to Enable Proper Software Engineering
book-title:: "Leveraging Applications of Formal Methods, Verification and Validation"
pages:: 202-212
volume:: 13036
item-type:: [[bookSection]]
access-date:: 2023-05-17T09:46:34Z
original-title:: "Low-Code Is Often High-Code, So We Must Design Low-Code Platforms to Enable Proper Software Engineering"
language:: en
url:: https://link.springer.com/10.1007/978-3-030-89159-6_14
authors:: [[Timothy C. Lethbridge]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/8LBEA26Y), [Web library](https://www.zotero.org/users/1039502/items/8LBEA26Y)
- [[Abstract]]
- The concept of low-code (and no-code) platforms has been around for decades, even before the term was used. The idea is that applications on these platforms can be built by people with less technical expertise than a professional programmer, yet can leverage powerful technology such as, for example, for databases, financial analysis, web development and machine learning. However, in practice, software written on such platforms often accumulates large volumes of complex code, which can be worse to maintain than in traditional languages because the low-code platforms tend not to properly support good engineering practices such as version control, separation of concerns, automated testing and literate programming. In this paper we discuss experiences with several low-code platforms and provide suggestions for directions forward towards an era where the benefits of low-code can be obtained without accumulation of technical debt. Our recommendations focus on ensuring low-code platforms enable scaling, understandability, documentability, testability, vendor-independence, and the overall user experience for developers those end-users who do some development.
- [[Attachments]]
- [Lethbridge - 2021 - Low-Code Is Often High-Code, So We Must Design Low.pdf](zotero://select/library/items/96MP3IME) {{zotero-imported-file 96MP3IME, "Lethbridge - 2021 - Low-Code Is Often High-Code, So We Must Design Low.pdf"}}
pages/@Low-Code Platform.md
+20
View File
@@ -0,0 +1,20 @@
date:: 12/2021
issn:: "2363-7005, 1867-0202"
issue:: 6
doi:: 10.1007/s12599-021-00726-8
title:: @Low-Code Platform
pages:: 733-740
volume:: 63
item-type:: [[journalArticle]]
access-date:: 2023-05-17T09:23:37Z
original-title:: Low-Code Platform
language:: en
url:: https://link.springer.com/10.1007/s12599-021-00726-8
publication-title:: Business & Information Systems Engineering
journal-abbreviation:: Bus Inf Syst Eng
authors:: [[Alexander C. Bock]], [[Ulrich Frank]]
library-catalog:: DOI.org (Crossref)
links:: [Local library](zotero://select/library/items/H9A7GYCY), [Web library](https://www.zotero.org/users/1039502/items/H9A7GYCY)
- [[Attachments]]
- [Bock e Frank - 2021 - Low-Code Platform.pdf](zotero://select/library/items/IDTQN8ZM) {{zotero-imported-file IDTQN8ZM, "Bock e Frank - 2021 - Low-Code Platform.pdf"}}
pages/@Low-Code Programming Models.md
+20
View File
@@ -0,0 +1,20 @@
links:: [Local library](zotero://select/library/items/7NN9HNPG), [Web library](https://www.zotero.org/users/1039502/items/7NN9HNPG)
authors:: [[Martin Hirzel]]
tags:: [[Computer Science - Programming Languages]]
date:: [[04-05-2022]]
item-type:: [[preprint]]
title:: @Low-Code Programming Models
- [[Abstract]]
- Traditionally, computer programming has been the prerogative of professional developers using textual programming languages such as C, Java, or Python. Low-code programming promises an alternative: letting citizen developers create programs using visual abstractions, demonstrations, or natural language. While low-code programming is currently getting a lot of attention in industry, the relevant research literature is scattered, and in fact, rarely uses the term "low-code". This article brings together low-code literature from various research fields, explaining how techniques work while providing a unified point of view. Low-code has the potential to empower more people to automate tasks by creating computer programs, making them more productive and less dependent on scarce professional software developers.
- [[Attachments]]
- [arXiv.org Snapshot](https://arxiv.org/abs/2205.02282) {{zotero-imported-file KFCH92K4, "2205.html"}}
- [Hirzel_2022_Low-Code Programming Models.pdf](https://arxiv.org/pdf/2205.02282.pdf) {{zotero-imported-file JGDXBIXM, "Hirzel_2022_Low-Code Programming Models.pdf"}}
- [[Highlights]]
- ((6464b288-5d89-4b29-bd9d-eb6c88f1371e)) #WORK/SE4DS2023_Intro
- ((6464e5e9-a147-4747-8c6f-2c907d728754)) #WORK/SE4DS2023_Intro #motivation
- ((6464e648-e4c8-496f-b66f-bb14f860170a)) #WORK/SE4DS2023_Intro
- ((6464e67a-e0da-4289-a819-ba114dd6c3ac)) #WORK/SE4DS2023_Intro #definition
- ((6464e6c2-476a-4106-bed9-c00c456ec273)) #WORK/SE4DS2023_Intro #definition
- ((6464e6f9-07ce-4bcc-b118-5c2f006d8535))
-
pages/@Low-code development and model-driven engineering%3A Two sides of the same coin%3F.md
+24
View File
@@ -0,0 +1,24 @@
tags:: [[Low-code development]], [[Model-driven engineering]], [[No-code development]]
date:: [[01-04-2022]]
issn:: 1619-1374
issue:: 2
doi:: 10.1007/s10270-021-00970-2
title:: @Low-code development and model-driven engineering: Two sides of the same coin?
pages:: 437-446
volume:: 21
item-type:: [[journalArticle]]
access-date:: 2023-05-17T09:52:15Z
original-title:: Low-code development and model-driven engineering: Two sides of the same coin?
language:: en
url:: https://doi.org/10.1007/s10270-021-00970-2
short-title:: Low-code development and model-driven engineering
publication-title:: Software and Systems Modeling
journal-abbreviation:: Softw Syst Model
authors:: [[Davide Di Ruscio]], [[Dimitris Kolovos]], [[Juan de Lara]], [[Alfonso Pierantonio]], [[Massimo Tisi]], [[Manuel Wimmer]]
library-catalog:: Springer Link
links:: [Local library](zotero://select/library/items/ZZ5ZNC2F), [Web library](https://www.zotero.org/users/1039502/items/ZZ5ZNC2F)
- [[Abstract]]
- The last few years have witnessed a significant growth of so-called low-code development platforms (LCDPs) both in gaining traction on the market and attracting interest from academia. LCDPs are advertised as visual development platforms, typically running on the cloud, reducing the need for manual coding and also targeting non-professional programmers. Since LCDPs share many of the goals and features of model-driven engineering approaches, it is a common point of debate whether low-code is just a new buzzword for model-driven technologies, or whether the two terms refer to genuinely distinct approaches. To contribute to this discussion, in this expert-voice paper, we compare and contrast low-code and model-driven approaches, identifying their differences and commonalities, analysing their strong and weak points, and proposing directions for cross-pollination.
- [[Attachments]]
- [Di Ruscio et al_2022_Low-code development and model-driven engineering.pdf](https://link.springer.com/content/pdf/10.1007%2Fs10270-021-00970-2.pdf) {{zotero-imported-file V2ZTBPAV, "Di Ruscio et al_2022_Low-code development and model-driven engineering.pdf"}}
pages/@Low-code will save the Digital Transformation.md
+9
View File
@@ -0,0 +1,9 @@
title:: @Low-code will save the Digital Transformation
item-type:: [[journalArticle]]
original-title:: Low-code will save the Digital Transformation
language:: en
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/F45VA8MS), [Web library](https://www.zotero.org/users/1039502/items/F45VA8MS)
- [[Attachments]]
- [Low-code will save the Digital Transformation.pdf](zotero://select/library/items/EBH4PBXC) {{zotero-imported-file EBH4PBXC, "Low-code will save the Digital Transformation.pdf"}}
pages/@LowcoBot%3A Towards Chatting With Low-Code Platforms.md
+69
View File
@@ -0,0 +1,69 @@
tags:: [[#zotero]]
title:: @LowcoBot: Towards Chatting With Low-Code Platforms
item-type:: [[journalArticle]]
original-title:: LowcoBot: Towards Chatting With Low-Code Platforms
language:: en
authors:: [[Francisco Martínez-Lasaca]], [[Pablo Díez]], [[Esther Guerra]], [[Juan de Lara]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/E92ZL76F), [Web library](https://www.zotero.org/users/1039502/items/E92ZL76F)
- [[Abstract]]
- Low-code platforms are gaining momentum, allowing the creation of complex applications directly from the browser. This allows their use by individuals with a wide range of backgrounds, but they pose some problems. On the one hand, newcomers may want to grasp the platform capabilities or pinpoint where can they access some functionality, which may prove difficult without guidance. On the other hand, their navigability can be complex: their functionality can be distributed across many webpages and user interfaces, each managing different concepts. Additionally, users may deem more convenient addressing some tasks using natural language instead of navigating visual interfaces. For these reasons, we introduce LowcoBot, a model-driven solution to generate LLM-based chatbots out of low-code platform design models. We demonstrate its capabilities by generating a chatbot for Dandelion+, a low-code platform built within an industrial context, and showing the range of tasks it supports out-of-the-box.
- ### Attachments
- [STAF_2024_paper_66.pdf](zotero://select/library/items/EGACKK83) {{zotero-imported-file EGACKK83, "STAF_2024_paper_66.pdf"}}
- ### Notes
- # Annotazioni
(10/6/2024, 12:25:34)
- “their functionality can be distributed across many webpages and user interfaces, each managing different concepts.” (Martínez-Lasaca et al., p. 1) #5fb236
* *
- “integrating conversational assistants – or chatbots – into low-code platforms can improve their navigability by providing users with more ways to interact with them –” (Martínez-Lasaca et al., p. 1) #5fb236
* *
- “odel-driven engineering (MDE) approach [3] that allows generating chatbots automatically” (Martínez-Lasaca et al., p. 2) #5fb236
* *
- “contents of the LLM agent vary between platforms.” (Martínez-Lasaca et al., p. 3) #5fb236
* *
- “o automatically populate tools and the initial prompt from a low-code platform model specification” (Martínez-Lasaca et al., p. 3) #5fb236
* *
- “visual metaphors (e.g., tables, diagrams, or forms)” (Martínez-Lasaca et al., p. 4) #5fb236
* *
- “capturing the relationships of the entities between the three technological spaces” (Martínez-Lasaca et al., p. 5) #5fb236
* *
- “initial prompt” (Martínez-Lasaca et al., p. 5) #5fb236
* *
- “shallow way” (Martínez-Lasaca et al., p. 5) #ffd400
*I wold define such a concept. *
- “igure 4:” (Martínez-Lasaca et al., p. 6) #ffd400
*Who create this graph and when? Can we explicitly link this graph with the explanatory example presented in Fig. 1? *
- “Conclusion” (Martínez-Lasaca et al., p. 10) #ffd400
*You are assuming that the LLM knows the lowcode platform you are considering. in case you are developing a new one or you are targeting a lowcode platform the LLM is not aware of, you should support also the training phase, isn't it? I think you should discuss this side situation somewhere in the paper. *
pages/@MODELS24_paper_2827.pdf.md
+239
View File
@@ -0,0 +1,239 @@
tags:: [[#zotero]]
title:: @MODELS24_paper_2827.pdf
item-type:: [[document]]
original-title:: MODELS24_paper_2827.pdf
links:: [Local library](zotero://select/library/items/LIC2UH3C), [Web library](https://www.zotero.org/users/1039502/items/LIC2UH3C)
- ### Attachments
- [MODELS24_paper_2827.pdf](zotero://select/library/items/XW2XW64V) {{zotero-imported-file XW2XW64V, "MODELS24_paper_2827.pdf"}}
- ### Notes
- # Annotazioni
(13/5/2024, 17:35:24)
- “unify the behaviour of domain-specific frameworks and evaluate it for two frameworks.” (“MODELS24_paper_2827.pdf”, p. 1) #a28ae5
* *
- “we enable structurally different meta-modeling approaches to exhibit identical behavior for the meta-model” (“MODELS24_paper_2827.pdf”, p. 1) #a28ae5
* *
- “for the user model” (“MODELS24_paper_2827.pdf”, p. 1) #a28ae5
* *
- “but exhibit different syntax and semantics” (“MODELS24_paper_2827.pdf”, p. 1) #a28ae5
* *
- “We identified 17 common concepts and defined artificial formal features for them.” (“MODELS24_paper_2827.pdf”, p. 1) #a28ae5
* *
- “Moreover, the formal nature of our interface prevents model inconsistencies and ensures safe meta-model modifications during runtime by forcing correct-by-construction.” (“MODELS24_paper_2827.pdf”, p. 1) #a28ae5
* *
- “language workbench, used to develop and validate the models” (“MODELS24_paper_2827.pdf”, p. 1) #5fb236
* *
- “run-time implementation exhibiting different syntax and semantics due to software or hardware constraints.” (“MODELS24_paper_2827.pdf”, p. 1) #5fb236
* *
- “Our scope is the typical domain-specific setup, where we have a meta-modeling language (M3 level), which is used to define the meta-model (M2 level) of a domain-specific language (DSL). With the DSL, user models (M1 level) can be instantiated, that comply to the rules defined in the M2 model [19], [1]. Respectively, the M2 model complies to the rules in the M3 model.” (“MODELS24_paper_2827.pdf”, p. 1) #5fb236
*It seems to be related to the coupled evolution setting. Let's see! [[check]] *
- “The situation is less perfect and can be highly challenging, if bijectivity is not given.” (“MODELS24_paper_2827.pdf”, p. 2) #a28ae5
* *
- “behavior” (“MODELS24_paper_2827.pdf”, p. 2) #5fb236
*mmm.... be careful with the usage of behavior.... let's see!!! [[check]] *
- “Artifacts expressible only in one framework are out of scope of our unified interface.” (“MODELS24_paper_2827.pdf”, p. 2) #ffd400
*This means that you are considering cases that can be managed with 1-1 mappings!!! *
- “This does not mean that the mapping is one to one.” (“MODELS24_paper_2827.pdf”, p. 2) #ffd400
* [[check]] *
- “bijectiv” (“MODELS24_paper_2827.pdf”, p. 2) #ff6666
* *
- “Our first aim is a generic method for transferring a meaningful functional subset of artifacts of one M2 language lossless into another such that having the same expressiveness afterwards.” (“MODELS24_paper_2827.pdf”, p. 2) #a28ae5
* *
- “based on the transferred M2 models, we want a generic way to transfer essential parts of the M1 model content lossless between DSM frameworks” (“MODELS24_paper_2827.pdf”, p. 2) #a28ae5
* *
- “Maintaining the behavior of is not as easy as it seams” (“MODELS24_paper_2827.pdf”, p. 2) #ff6666
* *
- “an cl” (“MODELS24_paper_2827.pdf”, p. 2) #ff6666
* *
- “interacting with the models and respectively the frameworks has to be unified.” (“MODELS24_paper_2827.pdf”, p. 2) #ffd400
*I'm not sure how far it is possible to go with making this platform independent. Consider for instance interpreted vs compiled modeling frameworks. *
- “Our proposal as depicted in Figure 1 is to identify common M2 and M1 concepts that will exist in most frameworks with the same intention.” (“MODELS24_paper_2827.pdf”, p. 2) #a28ae5
* *
- “majority” (“MODELS24_paper_2827.pdf”, p. 2) #ffd400
*How have you elicited/selected them? I expect to see some sort of survey. *
- “RQ3: Is the implementation effort for such an interface feasible for Ecore and our embedded DSL framework?” (“MODELS24_paper_2827.pdf”, p. 2) #ffd400
*Why have questioned this only for Ecore and for your DSL framework? *
- “In terms of common formats, only 9 % of the frameworks were interoperable.” (“MODELS24_paper_2827.pdf”, p. 2) #a28ae5
* *
- “M2-level "common model concepts", e.g. unary and n-ary relations.” (“MODELS24_paper_2827.pdf”, p. 2) #a28ae5
* *
- “behavior of models” (“MODELS24_paper_2827.pdf”, p. 3) #ffd400
*The concept of "behavior of models" needs clarification! What do you mean with it? *
- “(1) agreeing on one meta-modeling language that fulfills all needs and ensures consistency, and (2) developing a general method to convert from one DSM framework to another.” (“MODELS24_paper_2827.pdf”, p. 3) #ffd400
*This is the idea of "Power Model" from Brain Selic. *
- “Our approach differs in two aspects from the state of the art: first, we do not rely on any constraint language for ensuring completeness and correctness, but rather on a correct-by-construction (and deletion) approach” (“MODELS24_paper_2827.pdf”, p. 3) #a28ae5
* *
- “we do not accept information loss between two frameworks; instead, we require that concepts not natively supported are augmented by a wrapper.” (“MODELS24_paper_2827.pdf”, p. 3) #a28ae5
* *
- “We define a "concept" as a modeling element with a defined meaning, e.g. an M2 level class which is the blueprint for instantiating objects at M1 level.” (“MODELS24_paper_2827.pdf”, p. 3) #5fb236
* *
- “In other words, a concept is a modeling intention, with defined behavior, but open realization.” (“MODELS24_paper_2827.pdf”, p. 3) #ffd400
*What's the granularity of concept? I guess it very much depends on the modeling expert, isn't it? (I see a degree of arbitrariness) *
- “set of concepts as the common core” (“MODELS24_paper_2827.pdf”, p. 3) #a28ae5
* *
- “he properties and relations of our concepts are formally defined as an extended class diagram.” (“MODELS24_paper_2827.pdf”, p. 3) #ffd400
*I'm wondering how different can be this set of concepts than those available in EMOF. *
- “The more advanced those concepts are, the higher will be the effort in wrapping them to specific implementations.” (“MODELS24_paper_2827.pdf”, p. 3) #ffd400
*I can understand the idea even though it is not clear the practical benefits. Why defining a new M3 formalism? For instance, why not considering KM3 and possibly refine it if needed to reach the goal of the authors? I see the M2 layer concepts considerably overlapping with those in KM3. *
- “*M1OBJECT is the instance of an M2 class.” (“MODELS24_paper_2827.pdf”, p. 3) #ffd400
*This type of relation between M2 and M1 elements is not evident. *
- “Besides M1 and M2, we define three concepts on an Mx layer (s. Table 1a), which means these exist on M2 and M1 level. *MXELEMENT is an interface that enables common properties (s. subsection 3.3) for all M1 and M2 concepts, e.g. all concepts can have constraints, *MXCONSTRAINT. Moreover, we define *MXMDB as a singleton concept to be the root for all modeling operations, i.e. a model database (MDB).” (“MODELS24_paper_2827.pdf”, p. 4) #ffd400
*Why not presenting them in m2 and m1 layers, for instance with M2MDB, M1MDB, M2ELEMENT, M1ELEMENT, etc. *
- “build-in” (“MODELS24_paper_2827.pdf”, p. 4) #ff6666
*built-in *
- “We defined the features of our concepts formally in Figure 3 using UML. Our class diagram, however, comes with some extras.” (“MODELS24_paper_2827.pdf”, p. 4) #ffd400
*I miss a comparison/discussion of the expressive power of the proposed modeling concepts with those available in existing metamodeling frameworks. Why not considering one of those as possible candidate for the "Common modeling concepts" shown in Fig. 1. *
- “formally” (“MODELS24_paper_2827.pdf”, p. 4) #ffd400
* *
- “stereo type” (“MODELS24_paper_2827.pdf”, p. 4) #ff6666
* *
- “A UNIFIED MODELING INTERFACE BASED ON CONCEPTS” (“MODELS24_paper_2827.pdf”, p. 5) #ffd400
*This is related to our paper co-authored with J. De Lara. *
- “Correct by construction / correct by deletion” (“MODELS24_paper_2827.pdf”, p. 5) #ffd400
*THis is not convincing. *
- “consistent” (“MODELS24_paper_2827.pdf”, p. 5) #ffd400
*Do you mean correct? *
- “build” (“MODELS24_paper_2827.pdf”, p. 5) #ff6666
* *
- “Consistent” (“MODELS24_paper_2827.pdf”, p. 5) #ffd400
*Correct. *
- “Figure 4: Create graph of concepts: epimorphic mapping of concept and associations to a graph” (“MODELS24_paper_2827.pdf”, p. 7) #ffd400
*How the graphs that are represented in Fig 4 have a concrete implementation? What are the hypothesis that we should consider to say that by looking at Fig. 4 we can conclude that defined CRUD operations are complete and correct? Who define them? How? *
- “Implementation effort” (“MODELS24_paper_2827.pdf”, p. 7) #ffd400
*I don't get the points of the numbers shown in Table 2, especially those in the third column. How should we interpret such numbers? What's the research questions you wanted to answer? *
pages/@MODELS24_paper_2991.pdf.md
+8
View File
@@ -0,0 +1,8 @@
tags:: [[#zotero]]
title:: @MODELS24_paper_2991.pdf
item-type:: [[document]]
original-title:: MODELS24_paper_2991.pdf
links:: [Local library](zotero://select/library/items/B4VSXD4W), [Web library](https://www.zotero.org/users/1039502/items/B4VSXD4W)
- ### Attachments
- [MODELS24_paper_2991.pdf](zotero://select/library/items/X3GY4N54) {{zotero-imported-file X3GY4N54, "MODELS24_paper_2991.pdf"}}
pages/@MODELS24_paper_8050.pdf.md
+8
View File
@@ -0,0 +1,8 @@
tags:: [[#zotero]]
title:: @MODELS24_paper_8050.pdf
item-type:: [[document]]
original-title:: MODELS24_paper_8050.pdf
links:: [Local library](zotero://select/library/items/DN3BQIXA), [Web library](https://www.zotero.org/users/1039502/items/DN3BQIXA)
- ### Attachments
- [MODELS24_paper_8050.pdf](zotero://select/library/items/GGMG22IY) {{zotero-imported-file GGMG22IY, "MODELS24_paper_8050.pdf"}}
pages/@MODELS_2025_paper_100.md
+184
View File
@@ -0,0 +1,184 @@
tags:: [[#zotero]]
title:: @MODELS_2025_paper_100
item-type:: [[document]]
original-title:: MODELS_2025_paper_100
language:: en
links:: [Local library](zotero://select/library/items/MCTU2L36), [Web library](https://www.zotero.org/users/1039502/items/MCTU2L36)
- ### Attachments
- [PDF](zotero://select/library/items/3AQWFSFZ) {{zotero-imported-file 3AQWFSFZ, "MODELS_2025_paper_100.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotazioni
(22/5/2025, 11:21:13)
- “Integrating AI Development Process” (“MODELS_2025_paper_100”, p. 1) #5fb236
- “current practices often separate the development of ML and non-ML components, resulting in fragmented process development.” (“MODELS_2025_paper_100”, p. 1) #5fb236
- “establishment of effective feedback loops” (“MODELS_2025_paper_100”, p. 1) #5fb236
- “The framework aims to improve the management of AI system development by providing a unified and formalized representation of its constituent processes.” (“MODELS_2025_paper_100”, p. 1) #a28ae5
- “We demonstrate the feasibility of our framework through a case study, illustrating how it facilitates more systematic, transparent, and traceable process management in AI system development.” (“MODELS_2025_paper_100”, p. 1) #a28ae5
- “The integration of ML into software products introduces new software engineering (SE) challenges and intensifies existing ones” (“MODELS_2025_paper_100”, p. 1) #e56eee
- “The SE challenges introduced by ML integration largely stem from the need to coordinate multiple engineering pipelines, including system and software engineering, data engineering, and ML training” (“MODELS_2025_paper_100”, p. 1) #e56eee
- “However, integrating such heterogeneous artifacts into a cohesive development process remains inherently challenging” (“MODELS_2025_paper_100”, p. 1) #5fb236
- “These integration challenges are further exacerbated by current AI development practices, which frequently treat the development of ML and non-ML components in isolation [6].” (“MODELS_2025_paper_100”, p. 1) #5fb236
- “In order to address the challenges stemming from the lack of co-development between ML and non-ML components, we introduce AIEngOrchestrator, a model-based framework that orchestrates AI system development through an artifactcentric lens.” (“MODELS_2025_paper_100”, p. 1) #ffd400
*SO the focus of the orchestrator is the AI system development? Not the system being executed?*
- “Central to the framework is a domain-specific modeling language (DSL), GSM4SE4AI, an artifact-centric process modeling language that enables precise modeling of both the structural and behavioral aspects of AI development artifacts.” (“MODELS_2025_paper_100”, p. 1) #a28ae5
- “it establishes a unified structure that makes relationships between artifacts clear and manageable.” (“MODELS_2025_paper_100”, p. 1) #ffd400
*manageable for what?*
- “This integration offers end-to-end traceability, concurrent change propagation within and across development pipelines, and effective change impact analysis. A case study is used to demonstrate the applicability of the proposed approach.” (“MODELS_2025_paper_100”, p. 1) #ffd400
*What is the final goal of the approach?*
- “key principles from Software Engineering for AI” (“MODELS_2025_paper_100”, p. 1) #5fb236
- “core concepts in process modeling” (“MODELS_2025_paper_100”, p. 1) #5fb236
- “These systems are typically characterized by their reliance on machine learning (ML) models or other AI techniques to achieve their functionality.” (“MODELS_2025_paper_100”, p. 1) #5fb236
- “ML Module: Thi” (“MODELS_2025_paper_100”, p. 2) #2ea8e5
- “classification, prediction, recommendation, or anomaly detection” (“MODELS_2025_paper_100”, p. 2) #5fb236
- “Non-ML Module:” (“MODELS_2025_paper_100”, p. 2) #2ea8e5
- “Software Engineering Pipeline is responsible for the specification, design, implementation, and testing of the non-ML module” (“MODELS_2025_paper_100”, p. 2) #5fb236
- “Data Engineering Pipeline focuses on the collection, curation, and preprocessing of data required for training machine learning models.” (“MODELS_2025_paper_100”, p. 2) #5fb236
- “ML Training Pipeline handles model selection, training, and validation.” (“MODELS_2025_paper_100”, p. 2) #5fb236
- “System Engineering Pipeline oversees the integration of all system components—both ML and non-ML—as well as their overall verification and validation” (“MODELS_2025_paper_100”, p. 2) #5fb236
- “Despite this interdependence, these pipelines are often developed in isolation with limited coordination” (“MODELS_2025_paper_100”, p. 2) #a28ae5
- “This fragmentation disrupts the overall development lifecycle, primarily by hindering traceability, which in turn leads to cascading errors, costly rework, and increased integration risks. These challenges highlight the urgent need for a unified development approach that ensures traceability across pipelines and promotes coordinated engineering efforts.” (“MODELS_2025_paper_100”, p. 2) #ffd400
*Can you make some examples of problems due to the mentioned limited coordination? What are the currently available technologies that are exploited to mitigate such issues?*
- “Process modeling refers to the construction of a structured representation of a process, designed to enhance its comprehension, analysis, and optimization [9]. This representation typically identifies the actions to be executed (activities), the roles responsible for executing them, and the corresponding inputs and outputs (artifacts).” (“MODELS_2025_paper_100”, p. 2) #5fb236
- “Rather than prescribing a strict sequence of tasks, activities are triggered dynamically in response to the presence or changes in data values” (“MODELS_2025_paper_100”, p. 2) #a28ae5
- “We selected GSM as the foundational modeling approach for our framework due to its strong alignment with the dynamic, data-centric nature of AI system development. Building on these foundations, our framework adopts GSM to model the AI development process declaratively, using data-driven conditions to govern execution, as detailed in the following sections.” (“MODELS_2025_paper_100”, p. 2) #a28ae5
- “This section establishes the modeling foundation of the AIEngOrchestrator framework by introducing a domain-specific modeling language, GSM4SE4AI (Guard-Stage-Milestone for Software Engineering for AI).” (“MODELS_2025_paper_100”, p. 2) #5fb236
- “GSM4SE4AI is to provide a structured and coordinated process modeling approach specifically tailored to the integrated development of AI systems” (“MODELS_2025_paper_100”, p. 2) #5fb236
- “this language facilitates comprehensive end-toend traceability across the entire AI development lifecycle.” (“MODELS_2025_paper_100”, p. 2) #5fb236
- “detailed exploration of GSM4SE4AI: (A) the abstract syntax; (B) the concrete syntax of the macro-level model, illustrating the high-level representation and relations between artifacts; and (C) the concrete syntax of the micro-level model, detailing the lifecycle and information modeling within individual artifacts.” (“MODELS_2025_paper_100”, p. 2) #5fb236
- “A. GSM4SE4AI Abstract Syntax” (“MODELS_2025_paper_100”, p. 2) #2ea8e5
- “AI Development Process” (“MODELS_2025_paper_100”, p. 3) #2ea8e5
- “(1) Guard:” (“MODELS_2025_paper_100”, p. 3) #5fb236
- “(2) Stage: a unit of work that is activated when its guard condition is satisfied.” (“MODELS_2025_paper_100”, p. 3) #5fb236
- “(3) Milestone: a set of business rules also following the ECA pattern, which determines when a stage should be completed.” (“MODELS_2025_paper_100”, p. 3) #5fb236
- “its concrete syntax, defined across two distinct levels of granularity” (“MODELS_2025_paper_100”, p. 3) #ffd400
*Is this actually implemented? Is it tool supported?*
- “the concrete syntax captures: (i) the structural relationships among multiple artifact types—referred to as the macro-level representation, and (ii) the internal behavior of individual artifacts—referred to as the micro-level representation.” (“MODELS_2025_paper_100”, p. 3) #5fb236
- “high-level traceability and impact analysis across development pipelines” (“MODELS_2025_paper_100”, p. 3) #a28ae5
- “tracking of specific data attributes within artifacts (e.g., learning rate used in a hyperparameter tuning artifact) enabling precise verification and runtime introspection” (“MODELS_2025_paper_100”, p. 3) #a28ae5
- “Concrete Syntax” (“MODELS_2025_paper_100”, p. 3) #ffd400
*This is supposed to include actual modeling constructs that modelers can use to specify models conforming to the proposed metamodel. Actually by reading the descriptive text of the whole "Macro-Level Concrete Syntax" section, the abstraction level is still high and I don't see any modeling language or some constructs of it that can be used. The whole subsection is lenghty and not easy to grasp. At the end of the sub-section is not clear what's can be used out of the different presented concepts.*
- “This subsection introduces the concrete syntax used to represent the macro-level model in GSM4SE4AI, with a focus on the definition of AI artifact and their relationships.” (“MODELS_2025_paper_100”, p. 3) #5fb236
- “GSM4SE4AI, the core artifacts—along with their relationships and the rationale behind their inclusion—are modeled to reflect the objective of constructing a Traceability Information Model (TIM) tailored specifically for AI system” (“MODELS_2025_paper_100”, p. 3) #5fb236
- “A core component of any software development process is the definition and application of a TIM. Such models provide guidance on which development artifacts should be created and maintained, as well as the relationships that need to be established among them.” (“MODELS_2025_paper_100”, p. 3) #5fb236
- “TIM is designed to ultimately support essential project analyses, including change impact assessment, consistency checking, and requirements validation” (“MODELS_2025_paper_100”, p. 4) #5fb236
- “To realize this TIM within the context of SE4AI, GSM4SE4AI introduces a set of traceable AI artifacts and their corresponding links (traceable elements), organized around four complementary traceability approaches. Each approach targets a distinct aspect of traceability, and the associated artifacts are modeled to reflect that objective.” (“MODELS_2025_paper_100”, p. 4) #5fb236
- “Approach I: Full-Scope Coverage of AI Development” (“MODELS_2025_paper_100”, p. 4) #2ea8e5
- “(MLA1) ML Requirement Specification (MLRS)” (“MODELS_2025_paper_100”, p. 4) #2ea8e5
- “(MLA2) Data Splitting Artifact” (“MODELS_2025_paper_100”, p. 4) #2ea8e5
- “(MLA3) Training Algorithm Artifact” (“MODELS_2025_paper_100”, p. 4) #2ea8e5
- “(MLA4) Hyperparameter Tuning Artifact” (“MODELS_2025_paper_100”, p. 4) #2ea8e5
- “(MLA5) ML Module Artifact” (“MODELS_2025_paper_100”, p. 5) #2ea8e5
- “(MLA6) ML Validation Artifact” (“MODELS_2025_paper_100”, p. 5) #2ea8e5
- “System Requirement Specification (SRS),” (“MODELS_2025_paper_100”, p. 5) #5fb236
- “This subsection introduces the concrete syntax used to represent the micro-level model, with a focus on the definition of AI artifact behaviors.” (“MODELS_2025_paper_100”, p. 6) #a28ae5
- “As the artifact progresses, subsequent Stages are triggered based on Guard conditions that evaluate the values of associated Data Attributes.” (“MODELS_2025_paper_100”, p. 6) #5fb236
- “is automatically generated to collect the necessary input from the user.” (“MODELS_2025_paper_100”, p. 6) #ffd400
*What is the execution environmnet? When? at which stage of which process? We are missing an overview presentation about the provided framework supporting I guess the different pipelines presented earlier in the paper. The different artifacts of modeling constructs are presented without a proper context and enviroment presentation.*
- “Data attributes are explicitly selected and modeled to enhance traceability across different dimensions of AI system development.” (“MODELS_2025_paper_100”, p. 6) #ffd400
*See my previous comment.*
- “These attributes enable developers to trace how specific model configurations were derived and to revisit the reasoning behind them for future audits or refinements.” (“MODELS_2025_paper_100”, p. 7) #5fb236
- “This section explains how the framework supports runtime execution that is driven by changes in artifact data attributes, rather than by fixed activity flows.” (“MODELS_2025_paper_100”, p. 7) #ffd400
*Unfortunately the framework (intended as a software that can be used) has not been presented.*
- “Fig. 7. SRS-ML artifact behavior defined through data-driven stages. Transitions are shown for illustration, but control flow is implicit” (“MODELS_2025_paper_100”, p. 7) #ffd400
*How this process, that it is supposed to be an ideal one, can be actually put in practice also in relation with the existing technology? As a general comment we are missing concrete links from the presented ides with existing technologies and tools that cannot be completely substituted. It is necessary to ensure a link with them.*
- “Execution coordination is governed by the artifact relationship layer (see Section III). For instance, once a higherlevel artifact—such as the SRS-ML—has completed all its mandatory stages, related lower-level artifacts (e.g., MLRS, DRS, or SWRS) become eligible for instantiation.” (“MODELS_2025_paper_100”, p. 8) #ffd400
*What executes such coordination?*
- “enabling consistent propagation of modifications across artifact boundaries.” (“MODELS_2025_paper_100”, p. 8) #ffd400
*How such propagation is done? How changes are represented and executed/analyzed?*
- “IntentClassifierModule” (“MODELS_2025_paper_100”, p. 8) #5fb236
- “TextbasedChat” (“MODELS_2025_paper_100”, p. 8) #5fb236
- “DialogManagerModule” (“MODELS_2025_paper_100”, p. 8) #5fb236
- “A. Scenario 1. Change Impact Analysis across AI Pipelines” (“MODELS_2025_paper_100”, p. 8) #2ea8e5
- “This scenario exemplifies how the framework facilitates the concurrent propagation of changes across pipelines, supporting the systematic determination of how a change in one artifact may affect related artifacts across the AI development pipeline.” (“MODELS_2025_paper_100”, p. 8) #ffd400
*The representation and management of such changes is not clear.*
- “A subsequent update introduced a new requirement mandating the logging of all user interactions during runtime.” (“MODELS_2025_paper_100”, p. 8) #5fb236
- “Thanks to the explicit traceability links between artifacts across AI development pipelines supported by GSM4SE4AI, structured change impact analysis across pipelines becomes feasible and systematic. As illustrated in Fig. 9, the change is initiated within the SWRS of the TextbasedChat module. Through inter-transverse change propagation, this softwarelevel change triggers an update in the DRS, evolving it from Version 1.0 to Version 2.0.” (“MODELS_2025_paper_100”, p. 8) #ffd400
*This mechanism is very abstract and it's not evident how it happens in practice. I don't think software migrations due to change propagation happen automatically.*
- “s(” (“MODELS_2025_paper_100”, p. 9) #ff6666
*Missing space*
- “VI. PROOF-OF-CONCEPT PROTOTYPE” (“MODELS_2025_paper_100”, p. 9) #ffd400
*what's the envisioned architecture of the orchestrator? Section 6 shows some proof-of-concept dialog boxes without presenting a possible architecture actually involving all the different pipelines and change propagation requirements. Also this section is too high level.*
- “proof-of-concep” (“MODELS_2025_paper_100”, p. 9) #ff6666
*proof-of-concept*
- “A case study and prototype show improved traceability, change propagation, and consistency.” (“MODELS_2025_paper_100”, p. 10) #ffd400
*Improved with respect to what? It is necessary to convince about the mentioned improved by considering existing technologies.*
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.
pages/@MODELS_2025_paper_19.md
+126
View File
@@ -0,0 +1,126 @@
tags:: [[#zotero]]
title:: @MODELS_2025_paper_19
item-type:: [[document]]
original-title:: MODELS_2025_paper_19
language:: en
links:: [Local library](zotero://select/library/items/78JSCZMI), [Web library](https://www.zotero.org/users/1039502/items/78JSCZMI)
- ### Attachments
collapsed:: true
- [PDF](zotero://select/library/items/8XELL96A) {{zotero-imported-file 8XELL96A, "MODELS_2025_paper_19.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
- # Annotazioni
(5/5/2025, 16:40:59)
- “Model-Driven Approach” (“MODELS_2025_paper_19”, p. 1) #ffd400
*The paper makes an overview of different technologies for supporting multi agent systems and propose a taxonomy including and organizing different terms that are involved in the development of multi agents systems based on LLMs. As a such the title does not reflect the actual content of the paper, which is more a survey than an approach.*
- “LLM Agent Design” (“MODELS_2025_paper_19”, p. 1) #5fb236
- “most agents are assembled in an ad-hoc manner without a coherent architectural foundation.” (“MODELS_2025_paper_19”, p. 1) #5fb236
- “The challenge lies in structuring task decomposition, agent delegation, tool integration, and evaluation into coherent, extensible agent behaviors.” (“MODELS_2025_paper_19”, p. 1) #e56eee
- “we propose a modeldriven framework for LLM agent design that distinguishes structural components from cognitive modules and integrates them into a unified architecture.” (“MODELS_2025_paper_19”, p. 1) #e56eee
- “transforming how people interacted with LLMs and how developers began to architect intelligent capabilities atop existing and new software.” (“MODELS_2025_paper_19”, p. 1) #5fb236
- “With the rise of frameworks like LangChain1 and LlamaIndex2, developers could integrate LLMs into applications independent of LLM vendor lock-in” (“MODELS_2025_paper_19”, p. 1) #5fb236
- “from LLM workflows to agentic systems powered by LLMs capable of contextual, tool-mediated, and adaptive behavior.” (“MODELS_2025_paper_19”, p. 1) #e56eee
- “these approaches were functionally and architecturally distinct from LLM-integrated software.” (“MODELS_2025_paper_19”, p. 1) #5fb236
- “LLMs were used to classify model repositories (classification)” (“MODELS_2025_paper_19”, p. 1) #5fb236
- “LLM agents—components that use LLMs not just to respond, but to plan, act, and adapt” (“MODELS_2025_paper_19”, p. 1) #e56eee
- “OpenAI Swarm6, now replaced by Agents SDK7” (“MODELS_2025_paper_19”, p. 1) #5fb236
- “reintroduces concepts from multi-agent systems and cognitive architectures,” (“MODELS_2025_paper_19”, p. 1) #e56eee
- “the focus for developers moves beyond prompt writing and pipeline design to architectural and design choices involving planning modules, delegation logic, and tool interfaces.” (“MODELS_2025_paper_19”, p. 2) #e56eee
*THAT'S CRUCIAL! IMPORTANT. Maybe tool interfaces is related to MCP?*
- “architectural perspective” (“MODELS_2025_paper_19”, p. 2) #a28ae5
- “agents” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “tasks” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “tools” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “orchestra” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “cognitive modules” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “architectural model for LLM agent design” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “systematized framework of structural components” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “integrated behavioral scaffold” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “Plan–Act–Evaluate” (“MODELS_2025_paper_19”, p. 2) #5fb236
- “Explore–Exploit–Learn” (“MODELS_2025_paper_19”, p. 2) #5fb236
- “Together, these contributions present a principled, modeldriven view of LLM-native systems, clarifying core elements and enabling deliberate design of orchestration, reasoning, and adaptability.” (“MODELS_2025_paper_19”, p. 2) #e56eee
- “LLM usage to agentic integration” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “agent design architecture” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “structural components and cognitive modules” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “orchestration, decomposition, collaboration, and tool use” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “explore–exploit–learn dynamics” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “experimentation” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “future directions and conclusions” (“MODELS_2025_paper_19”, p. 2) #2ea8e5
- “distributed autonomy and coordination” (“MODELS_2025_paper_19”, p. 2) #5fb236
- “LLM-powered agents now exhibit memory, planning, and reasoning capabilities [18], with simulation pipelines embedding LLMs across their full lifecycle [19].” (“MODELS_2025_paper_19”, p. 2) #5fb236
- “Frameworks have emerged that decompose agents into modules for planning, memory, tool use, and reflection [23],” (“MODELS_2025_paper_19”, p. 2) #e56eee
- “showing convergence with MAS principles—but realized through LLM-native methods.” (“MODELS_2025_paper_19”, p. 2) #e56eee
- “Although effective for interleaved reasoning and acting, these early agents lacked orchestration, memory-backed decision-making, or modular delegation logic—essential features for handling complex, long-horizon tasks. Without shared execution contexts or rolebased coordination, they could not generalize beyond isolated task flows.” (“MODELS_2025_paper_19”, p. 2) #5fb236
- “foundational planning primitive embedded within structured architectures.” (“MODELS_2025_paper_19”, p. 3) #5fb236
- “memory (short- and long-term),” (“MODELS_2025_paper_19”, p. 3) #a28ae5
- “profile module” (“MODELS_2025_paper_19”, p. 3) #a28ae5
- “adaptive planning” (“MODELS_2025_paper_19”, p. 3) #a28ae5
- “Architectural Perspectives on LLM Agent Desig” (“MODELS_2025_paper_19”, p. 3) #2ea8e5
- “Early frameworks introduced cognitive loops with modular memory, internal/external actions, and decision cycles [26]” (“MODELS_2025_paper_19”, p. 3) #e56eee
- “while others organized agents around core functions of reasoning, perception, and action” (“MODELS_2025_paper_19”, p. 3) #e56eee
- “Learning, Knowledge, and Adaptation in LLM Agents” (“MODELS_2025_paper_19”, p. 3) #2ea8e5
- “As LLM agents gain traction, what remains missing is a cohesive, architectural model that ties these capabilities together with clarity and intentionality. Rather than introducing entirely new mechanisms, our work offers a model-driven perspective that unifies these components into a coherent design framework.” (“MODELS_2025_paper_19”, p. 3) #e56eee
- “We believe this will enable developers to build context-aware, tool-mediated, and adaptive LLM agents with deliberate modularity and strategic coordination,” (“MODELS_2025_paper_19”, p. 3) #f19837
- “The knowledge component supports semantic reasoning, and memory provides continuity and personalization across interactions.” (“MODELS_2025_paper_19”, p. 3) #a28ae5
- “Task execution is governed by a modular orchestration layer that coordinates subtasks, tool usage, and inter-agent collaboration.” (“MODELS_2025_paper_19”, p. 3) #5fb236
- “A. Operational Roles and Interfaces” (“MODELS_2025_paper_19”, p. 4) #5fb236
- “It carries with it an evaluative dimension, as each goal is associated with specific criteria that define what success looks like.” (“MODELS_2025_paper_19”, p. 4) #5fb236
- “This distinction is important because the same goal can be pursued through many different tasks, and tasks may need to be recomposed, reprioritized, or even reinterpreted as conditions change or new information arises. From a system perspective, this allows the agent to dynamically adjust its operational plan (tasks) while maintaining alignment with the overarching goal.” (“MODELS_2025_paper_19”, p. 4) #a28ae5
- “The agent does not use tools indiscriminately; rather, tool invocation is governed by its internal capabilities, activated based on task requirements and environmental context” (“MODELS_2025_paper_19”, p. 4) #5fb236
- “It maintains a shared context over the internal states of all agents, manages workflows, handles branching or fallback logic, and bridges perception, cognition, and action—enabling sustained, adaptive reasoning across stages and modalities.” (“MODELS_2025_paper_19”, p. 4) #5fb236
- “Goal” (“MODELS_2025_paper_19”, p. 5) #2ea8e5
- “Sufficiency” (“MODELS_2025_paper_19”, p. 5) #2ea8e5
- “Preferences” (“MODELS_2025_paper_19”, p. 5) #2ea8e5
- “Guardrails” (“MODELS_2025_paper_19”, p. 5) #2ea8e5
- “Memory” (“MODELS_2025_paper_19”, p. 5) #2ea8e5
- “Learning” (“MODELS_2025_paper_19”, p. 5) #2ea8e5
- “Knowledge” (“MODELS_2025_paper_19”, p. 5) #2ea8e5
- “epresentative types for each module” (“MODELS_2025_paper_19”, p. 5) #5fb236
- “Goals” (“MODELS_2025_paper_19”, p. 5) #2ea8e5
- “Sufficiency” (“MODELS_2025_paper_19”, p. 5) #2ea8e5
- “Learning” (“MODELS_2025_paper_19”, p. 5) #2ea8e5
- “Guardrails” (“MODELS_2025_paper_19”, p. 5) #2ea8e5
- “memory” (“MODELS_2025_paper_19”, p. 5) #2ea8e5
- “Episodic memory” (“MODELS_2025_paper_19”, p. 5) #5fb236
- “Reflective memory” (“MODELS_2025_paper_19”, p. 5) #5fb236
- “Preference memory” (“MODELS_2025_paper_19”, p. 5) #5fb236
- “main orchestration variations” (“MODELS_2025_paper_19”, p. 6) #2ea8e5
- “task decomposition type” (“MODELS_2025_paper_19”, p. 6) #2ea8e5
- “delegation and collaboration mechanisms” (“MODELS_2025_paper_19”, p. 6) #2ea8e5
- “tool usage” (“MODELS_2025_paper_19”, p. 6) #2ea8e5
- “orchestration architectures” (“MODELS_2025_paper_19”, p. 6) #5fb236
- “publish-subscribe” (“MODELS_2025_paper_19”, p. 6) #2ea8e5
- “graph-based” (“MODELS_2025_paper_19”, p. 6) #2ea8e5
- “handoff-based” (“MODELS_2025_paper_19”, p. 6) #2ea8e5
- “Publish-Subscribe” (“MODELS_2025_paper_19”, p. 6) #2ea8e5
- “Graph-Based” (“MODELS_2025_paper_19”, p. 6) #2ea8e5
- “Execution is centrally orchestrated based on graph logic, with a persistent shared Execution Context capturing state updates” (“MODELS_2025_paper_19”, p. 6) #5fb236
- “Handoff-Based” (“MODELS_2025_paper_19”, p. 6) #2ea8e5
- “Fig. 5.” (“MODELS_2025_paper_19”, p. 7) #ffd400
*A legend with the used color schema is needed.*
- “As shown in Figure 7, a central agent interprets userprovided instructions and orchestrates the task through a mix of direct action, delegation to specialized multi-agent teams, and internal deliberation.” (“MODELS_2025_paper_19”, p. 7) #a28ae5
- “A key mechanism in this setup is nested chat, which is an agentic version of prompt chaining. The nested chat can involve launching sub-conversations with other agents, running inner verification or refinement loops, or resolving ambiguities in the original instruction.” (“MODELS_2025_paper_19”, p. 7) #ffd400
*How about governance or in general the resolution of possible conflicting situations?*
- “Figure 7 is just one instantiation; delegation and collaboration patterns can vary widely depending on the agentic framework and problem space.” (“MODELS_2025_paper_19”, p. 7) #5fb236
- “Generic Tools” (“MODELS_2025_paper_19”, p. 8) #5fb236
- “Function Tools” (“MODELS_2025_paper_19”, p. 8) #5fb236
- “Agent-as-Tool” (“MODELS_2025_paper_19”, p. 8) #5fb236
- “Agent Role Typology” (“MODELS_2025_paper_19”, p. 8) #2ea8e5
- “exploreexploit-learn paradigm” (“MODELS_2025_paper_19”, p. 8) #5fb236
- “Plan–Act–Evaluate (PAE)” (“MODELS_2025_paper_19”, p. 8) #2ea8e5
- “Autogen, OpenAI Agents SDK, CrewAI, PydanticAI, and LangGraph” (“MODELS_2025_paper_19”, p. 9) #ffd400
*What are the criteria that have been used to select them?*
- “12We note two concerns, beyond this paper’s scope: (a) open-source models (e.g., available via Ollama) are less capable than frontier models, often lacking tool use, vision, and reasoning, and tend to produce more erratic agent behavior; and (b) frontier model costs can become prohibitive as agents and messages proliferate.” (“MODELS_2025_paper_19”, p. 9) #e56eee
- “hands-on experiences with agentic frameworks” (“MODELS_2025_paper_19”, p. 10) #5fb236
- “design architecture across diverse domains to assess robustness, adaptability, and goal alignment in real-world settings.” (“MODELS_2025_paper_19”, p. 10) #5fb236
- “benchmarks that evaluate orchestration quality” (“MODELS_2025_paper_19”, p. 10) #5fb236
- “This paper responds to that shift by proposing a principled, model-driven framework for LLM agent design.” (“MODELS_2025_paper_19”, p. 10) #a28ae5
- “we observed operational differences and early indications of recurring design tendencies” (“MODELS_2025_paper_19”, p. 10) #a28ae5
- “set of practical guidelines for structuring agent behavior” (“MODELS_2025_paper_19”, p. 10) #a28ae5
- “Rather than prescribing a monolithic architecture, we offer scaffolds that support flexible composition and architectural clarity.” (“MODELS_2025_paper_19”, p. 10) #ffd400
*Indeed, I appreciate the effort, even though the proposed description is generic and vague. There are not specific guidelines on how to actually decompose monolithic architectures.*
- “REFERENCES” (“MODELS_2025_paper_19”, p. 11) #ffd400
*34 references out of 50 come from arxive. I understand this is a very fast growing topic, however it is necessary to keep basing our research on peer reviewed sources. This is a general comment.*
COnsider that those that are tagget with #5fb236 are just highlights, those that are tagged with #e56eee and #a28ae5 are imporant 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 sentence to summarize the work COMMENTS: Organize the notes especially those that contain issues or typos.
pages/@MODELS_2025_paper_3.md
+190
View File
@@ -0,0 +1,190 @@
tags:: [[#zotero]]
title:: @MODELS_2025_paper_3
item-type:: [[document]]
original-title:: MODELS_2025_paper_3
language:: en
links:: [Local library](zotero://select/library/items/8E5M8QKA), [Web library](https://www.zotero.org/users/1039502/items/8E5M8QKA)
- ### Attachments
- [PDF](zotero://select/library/items/9QIL9QVD) {{zotero-imported-file 9QIL9QVD, "MODELS_2025_paper_3.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotazioni
(21/5/2025, 09:48:15)
- “autonomous reasoning and human-like conversational abilities.” (“MODELS_2025_paper_3”, p. 1) #5fb236
- “We discuss the conceptual foundations and key design principles of LLMA-UML and evaluate our extension by modeling a representative case study and discussing the benefits of our approach” (“MODELS_2025_paper_3”, p. 1) #ffd400
*What's the goal of such modeling effort?*
- “Incorporating such agents into software systems presents new challenges for system design and modeling.” (“MODELS_2025_paper_3”, p. 1) #5fb236
- “standardized way to model an AI agent that relies on a massive learned model and engages in open-ended natural language interactions.” (“MODELS_2025_paper_3”, p. 1) #a28ae5
- “However, these implementations follow ad-hoc architectures, and a general modeling method to describe their design has yet to mature.” (“MODELS_2025_paper_3”, p. 1) #5fb236
- “. We identify why existing UML multi-agent modeling techniques are insufficient for this new class of agents” (“MODELS_2025_paper_3”, p. 1) #2ea8e5
- “propose a UML profile with new modeling elements to address these deficiencies.” (“MODELS_2025_paper_3”, p. 1) #2ea8e5
- “communicate” (“MODELS_2025_paper_3”, p. 1) #ffd400
*what do you mean? Communicate you mean presenting a system under design/development? What's the goal of the modeling phase here? At what stage of the development you see modeling  being imporant when developing LLM-based multi-agent systems?*
- “currently model LLM-agent based systems in the domain of software engineering.” (“MODELS_2025_paper_3”, p. 1) #2ea8e5
- “outlines the related work” (“MODELS_2025_paper_3”, p. 1) #2ea8e5
- “problem and outlines the limitations of current UML models in this context.” (“MODELS_2025_paper_3”, p. 1) #2ea8e5
- “proposed UML extension for LLM-agents” (“MODELS_2025_paper_3”, p. 1) #2ea8e5
- “semantics and usage guidelines for LLMA-UML stereotypes.” (“MODELS_2025_paper_3”, p. 1) #a28ae5
- “papers that propose the development of LLM-agents” (“MODELS_2025_paper_3”, p. 2) #e56eee
- “agent interaction protocols (AIP).” (“MODELS_2025_paper_3”, p. 2) #a28ae5
- “o represent internal agent processing, they recommend using activity diagrams and statecharts and dashed notations for interfacing with other agents” (“MODELS_2025_paper_3”, p. 2) #5fb236
- “cloning, mitosis, reproduction and parasitic and symbiotic repationships.” (“MODELS_2025_paper_3”, p. 2) #5fb236
- “In particular, these UML models assume clearly defined internal state representations and a limited set of message types, which is a poor fit for LLM-based agents that operate via free-form natural language and possess an implicit knowledge model.” (“MODELS_2025_paper_3”, p. 2) #a28ae5
- “existing UML-based multi-agent modeling techniques lack concepts for the kinds of interactions and internal structures that LLM-based agents exhibit” (“MODELS_2025_paper_3”, p. 2) #a28ae5
- “ReAct is an approach that combines reasoning and acting by combining an LLM’s chainof-thought with actions in an environment” (“MODELS_2025_paper_3”, p. 2) #5fb236
- “advanced LLM-based agents are essentially hybrid systems combining a language model with additional modules or external services” (“MODELS_2025_paper_3”, p. 2) #e56eee
- “LLM-Agent-UMF” (“MODELS_2025_paper_3”, p. 2) #5fb236
- “They propose LLM-Agent-UMF, a unified conceptual framework to classify an agent’s core modules (planning, memory, profile, action, security) and distinguish the LLM and tool component” (“MODELS_2025_paper_3”, p. 2) #e56eee
- “key issues that need to be addressed to accurately represent LLM agents” (“MODELS_2025_paper_3”, p. 2) #a28ae5
- “Implicit Knowledge and Reasoning” (“MODELS_2025_paper_3”, p. 3) #2ea8e5
- “Current UML abstractions (e.g. the attributes/methods of a class) cannot directly encapsulate the complexity of an LLM’s knowledge base or the probabilistic nature of its reasoning” (“MODELS_2025_paper_3”, p. 3) #a28ae5
- “Existing agent profiles that include beliefs and goals [3] treat knowledge as discrete data, which does not capture the rich and diffuse knowledge embedded in an LLM.” (“MODELS_2025_paper_3”, p. 3) #e56eee
- “Natural Language Interaction:” (“MODELS_2025_paper_3”, p. 3) #2ea8e5
- “UML sequence diagrams and communication diagrams lack constructs to express that a message is, for example, a prompt or a free-form query to be interpreted by the agen” (“MODELS_2025_paper_3”, p. 3) #5fb236
- “Tool Use and Environment Actions” (“MODELS_2025_paper_3”, p. 3) #2ea8e5
- “LLM-agents can significantly extend their functionality beyond simple text generation by integrating and utilising external tools” (“MODELS_2025_paper_3”, p. 3) #5fb236
- “but they have not provided for on-the-fly tool usage driven by an agent’s internal reasoning.” (“MODELS_2025_paper_3”, p. 3) #5fb236
- “This makes it difficult to capture the loop where an LLM agent decides it lacks information, calls an external service, and then incorporates the result into its next prompt.” (“MODELS_2025_paper_3”, p. 3) #a28ae5
- “Dynamic Goals and Non-deterministic Behavior” (“MODELS_2025_paper_3”, p. 3) #2ea8e5
- “it does not readily accommodate the emergence of new goals at runtime” (“MODELS_2025_paper_3”, p. 3) #a28ae5
- “This limitation highlights the need for modeling techniques that can capture the dynamic and evolving nature of LLM-agent behavior.” (“MODELS_2025_paper_3”, p. 3) #a28ae5
- “UML-agent profiles are not well suited for representing the internal mechanisms and interaction patterns of LLM-based agents.” (“MODELS_2025_paper_3”, p. 3) #a28ae5
- “To address the limitations outlined in section IV, we introduce a UML extension, realized as a UML profile, specifically adapted to the modeling of LLM-agents and their interactions” (“MODELS_2025_paper_3”, p. 4) #a28ae5
- “stereotypes and model elements that capture the unique needs of LLM-based agents.” (“MODELS_2025_paper_3”, p. 4) #a28ae5
- “<<LLMAgent>> stereotype encapsulates the autonomous reasoning and decision-making capabilities” (“MODELS_2025_paper_3”, p. 4) #5fb236
- “<<Prompt>> stereotype facilitates natural languagebased communication, enabling agents to coordinate tasks and share information effectively within the system” (“MODELS_2025_paper_3”, p. 4) #5fb236
- “<<Tool>> stereotype represents external resources that agents leverage collaboratively, supporting task delegation and enhancing system flexibility as well as extending the autonomous capabilities of the <<LLMAgent>>” (“MODELS_2025_paper_3”, p. 4) #5fb236
- “<<Memory>> stereotype ensures that agents retain context and historical data across interactions” (“MODELS_2025_paper_3”, p. 4) #5fb236
- “<<LLMAgent>> is a stereotype used to clearly identify an autonomous agent component whose core reasoning capabilities are driven by a large language model.” (“MODELS_2025_paper_3”, p. 4) #5fb236
- “<<Prompt>>” (“MODELS_2025_paper_3”, p. 4) #ffd400
*It's not appropriate using this stereotype also to represent amswers from agents. Prompts are string given as input to LLMs and not answers.*
- “distinguish user queries, agent responses,” (“MODELS_2025_paper_3”, p. 4) #ffd400
*This is not consistent with Fig 2 where <<prompt>> is used to represent at the same manner both user queries and agent responses.*
- “this profile includes conventions for modeling the internal reasoning cycle of an LLM agent” (“MODELS_2025_paper_3”, p. 4) #ffd400
*How this conventions are prescriptive? How to check if they are actually used? IN general, at this point of the paper is not clear if the proposed UML profile is tool supported. Moreover, what the intended use of the profile, who is the main intended stakeholder?*
- “UML Activity Diagrams or Interaction Overview Diagrams can be used to describe the control flow of the agent.” (“MODELS_2025_paper_3”, p. 4) #ffd400
*Typically, processes involving orchestration or choreographis of services are specified by using BPMN, Can you comment the performed choice with respect to the possible use of BPMN? #question*
- “These diagrams can be annotated to represent reasoning steps such as interpret prompt, evaluate context, select tool, invoke tool, and generate response” (“MODELS_2025_paper_3”, p. 4) #ffd400
*How can the annotation be done?*
- “Using the proposed profile, modelers can develop both structural and behavioral UML diagrams that explicitly capture the characteristics of LLM-based agents” (“MODELS_2025_paper_3”, p. 4) #5fb236
- “Component Diagrams” (“MODELS_2025_paper_3”, p. 5) #2ea8e5
- “This structural representation clearly identifies the core agent, its external tool dependencies and its connection to the memory components, providing more insight than a standard UML diagram where the LLM nature and specific dependencies may be obscured” (“MODELS_2025_paper_3”, p. 5) #5fb236
- “Sequence Diagrams:” (“MODELS_2025_paper_3”, p. 5) #2ea8e5
- “The agent then sends its response back to the user, modeled as another <<Prompt>> message with content such as “Your meeting is scheduled for tomorrow at 10am”.” (“MODELS_2025_paper_3”, p. 5) #ffd400
*The stereotype <<Prompt>> is used also to represent responses from Agents*
- “Figure 2:” (“MODELS_2025_paper_3”, p. 5) #ffd400
- “Sequence Diagram: Scheduling a Meeting, illustrating <<Prompt>> messages, <<Tool>> interaction, and a clarification loop.” (“MODELS_2025_paper_3”, p. 5) #ffd400
*Why do you need to specify loops for giving instructins on the calendar to be used? Why not including this information in the initial prompt? By the way the example is not effective in presenting the case of emerging behaviours, decisions that need to be taken at runtime etc. as motivated earlier in the paper.*
- “Activity Diagrams:” (“MODELS_2025_paper_3”, p. 5) #2ea8e5
- “Overall, the proposed UML profile and its diagramming guidelines allow modelers to create representations of LLMbased systems that explicitly indicate the presence and role of the LLM through stereotypes such as <<LLMAgent>>. The profile highlights natural language interactions using <<Prompt>>, clarifies how agents use external capabilities using <<Tool>> elements, represents the function of conversational context or persistent state using <<Memory>> artifacts, and illustrates the flow of reasoning and action within both activity and sequence diagrams. Crucially, these enhancements are integrated within the standard UML framework, facilitating adoption by software engineers working within established modeling environments.” (“MODELS_2025_paper_3”, p. 6) #ffd400
*This is a repetition.*
- “A <<Tool>> provides specific external functionality with at least one defined interface operation.” (“MODELS_2025_paper_3”, p. 7) #5fb236
- “a <<LLMAgent>> enforces session coherence by linking to <<Memory>> and processing requests in sequence.” (“MODELS_2025_paper_3”, p. 7) #5fb236
- “knowledge representation includes both implicit knowledge within <<LLMAgent>> structures and explicit knowledge stored in <<Memory>>” (“MODELS_2025_paper_3”, p. 7) #5fb236
- “interaction dynamics revolve around <<Prompt>> message sequences and <<Tool>> invocations, with context management achieved through structured <<Memory>> access.” (“MODELS_2025_paper_3”, p. 7) #5fb236
- “reasoning processes appear as nested activations within sequence diagrams, annotated activity flows for chain-ofthought logic, or alternatively combined fragments for nondeterministic behavior.” (“MODELS_2025_paper_3”, p. 7) #5fb236
- “When implemented through a UML profile, these semantics help to avoid modeling oversights (such as missing memory links or undefined tool interfaces) and ensure a coherent architecture for LLM agent design.” (“MODELS_2025_paper_3”, p. 7) #a28ae5
- “a theoretical modeling extension, evaluation is conducted by analyzing its expressiveness and consistency rather than quantitative metrics.” (“MODELS_2025_paper_3”, p. 7) #a28ae5
- “We illustrate the usefulness of the proposed UML profile through an example case study and discuss how it addresses the previously identified issues.” (“MODELS_2025_paper_3”, p. 7) #ffd400
*WHat are the research questions that you wanted to answer with the case study?*
- “chapter” (“MODELS_2025_paper_3”, p. 7) #ff6666
*Section*
- “By comparing LLMA-UML diagrams with their conventional UML counterparts, we evaluate the expressiveness, clarity, and practical benefits of the extension.” (“MODELS_2025_paper_3”, p. 7) #a28ae5
- “To illustrate the benefits of LLMA-UML, we model a software development pipeline where multiple LLM-based agents collaborate to analyze requirements, generate code, and validate results. This case study highlights the unique attributes of LLM-agents such as natural language interaction, memorydriven reasoning, tool integration and adaptive workflows” (“MODELS_2025_paper_3”, p. 7) #ffd400
*To illustrate the benefits of LLMA-UML it is necessary to discuss the existing challenges that the approach aims to address. What's the difficulties that the defined UML profiles permits to address? Who is the main stakeholder? What are the criticalities due to the lack of a modeling language like LLMA-UML. As mentioned many times by the authors, one of the peculiar characteristics of the LLM_bases systems is their emerging behaviour, their reasoning and planning. Why modeling them? What's the benefit?*
- “The shared memory component (<<Memory>>) is central to the operation of the system. It holds project-specific context that agents retrieve or update during task execution.” (“MODELS_2025_paper_3”, p. 8) #5fb236
- “As illustrated in Figure 6, the activity diagram models the decision logic within the pipeline.” (“MODELS_2025_paper_3”, p. 8) #ffd400
*How is this used in practice?*
- “precise modeling of LLM-agent systems where traditional UML falls short.” (“MODELS_2025_paper_3”, p. 9) #5fb236
- “The case study also demonstrates the scalability of LLMAUML, with complex interactions, such as simultaneous tool use by multiple agents, remaining readable through stereotyped elements.” (“MODELS_2025_paper_3”, p. 9) #ffd400
*The consideration of multiple agents is indeed relevant even though it is not properly covered. In particualar, it can be the case that Agents interact each other and in this case it is necessary to introduce some governance mechanisms in order to manage conflicting situations (e.g., different outputs from agents that are supposed to support the same task and from the same query they produce conflicting results).*
- “In summary, LLMA-UML bridges the gap between traditional software modeling and the unique requirements of LLM-agent systems, providing a structured yet flexible framework for designing, analyzing and communicating AI-driven workflows.” (“MODELS_2025_paper_3”, p. 9) #5fb236
- “Our proposed UML profile introduces the <<LLMAgent>>, <<Prompt>>, <<Tool>> and <<Memory>> stereotypes and corresponding semantics which together enable modelers to create clear and expressive models of LLM-agent architectures and interactions.” (“MODELS_2025_paper_3”, p. 10) #5fb236
- “theoretical foundation for describing systems that integrate LLM-agents using a standard modeling language.” (“MODELS_2025_paper_3”, p. 10) #ffd400
*There are arelady different frameworks that permits to specify workflows of different agents. How do you compare with them? What's the benefit of the proposed approach with respect to them?*
- “Furthermore, to address the socio-technical aspects of LLM agents, future extensions could include concepts such as a <<Policy>> stereotype to explicitly model ethical constraints or alignment rules governing agent behavior.” (“MODELS_2025_paper_3”, p. 10) #ffd400
*Yes, this is related to one of my comments above related to governance.*
- “[6] J. Liu, K. Wang, Y. Chen, X. Peng, Z. Chen, L. Zhang, and Y. Lou, “Large Language Model-Based Agents for Software Engineering: A Survey.”” (“MODELS_2025_paper_3”, p. 10) #ffd400
*please complete references with all the details*
COnsider that those that are tagget with #5fb236 are just highlights, those that are tagged with #e56eee and #a28ae5 are imporant 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 sentence to summarize the work COMMENTS: Organize the notes especially those that contain issues or typos.
pages/@MODELS_2025_paper_8.md
+119
View File
@@ -0,0 +1,119 @@
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.
pages/@MODELS_2025_paper_85.md
+150
View File
@@ -0,0 +1,150 @@
tags:: [[#zotero]]
title:: @MODELS_2025_paper_85
item-type:: [[document]]
original-title:: MODELS_2025_paper_85
language:: en
links:: [Local library](zotero://select/library/items/NISUMPS4), [Web library](https://www.zotero.org/users/1039502/items/NISUMPS4)
- ### Attachments
- [PDF](zotero://select/library/items/443HYUW3) {{zotero-imported-file 443HYUW3, "MODELS_2025_paper_85.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotazioni
(22/5/2025, 16:21:55)
- “Requirement Extraction” (“MODELS_2025_paper_85”, p. 1) #a28ae5
- “Use Case Modeling” (“MODELS_2025_paper_85”, p. 1) #a28ae5
- “from User Stories” (“MODELS_2025_paper_85”, p. 1) #a28ae5
- “Early-stage software modeling plays a crucial role in capturing stakeholders’ intentions and ensuring that the system aligns with user requirements.” (“MODELS_2025_paper_85”, p. 1) #5fb236
- “transitioning from the natural language of user stories to structured artifacts, such as UML use case diagrams and full use case descriptions, remains challenging for analysts—especially for novices—due to its time-consuming, tedious, and susceptible to errors.” (“MODELS_2025_paper_85”, p. 1) #a28ae5
- “Story2Spec, a DeepSeek-based tool that classifies user stories into requirements according to the FURPS model (functional, usability, performance, reliability, and supportability).” (“MODELS_2025_paper_85”, p. 1) #a28ae5
- “it generates use case diagrams following UML syntax language and use cases descriptions based on a predefined template.” (“MODELS_2025_paper_85”, p. 1) #5fb236
- “Story2Spec tool generates consistent and interpretable use case diagrams with clear and detailed use case descriptions” (“MODELS_2025_paper_85”, p. 1) #5fb236
- “the proposed tool can significantly support the specification phase and, thus, mitigate the burden on analysts when identifying software artifacts” (“MODELS_2025_paper_85”, p. 1) #5fb236
- “A clear definition of user needs and system interactions and behavior paves the way for understandable and well-structured UML diagrams, which can positively impact communication among stakeholders, users, and developers” (“MODELS_2025_paper_85”, p. 1) #5fb236
- “Several studies indicate that including UML in agile methods significantly enhances the consistency and comprehensibility of software designs, thus decreasing the uncertainty and misconceptions throughout the project life cycle.” (“MODELS_2025_paper_85”, p. 1) #5fb236
- “In agile development, developers rely on user stories and succinct descriptions of software requirements to understand the system’s different functionalities.” (“MODELS_2025_paper_85”, p. 1) #5fb236
- “User stories basically boost cross-team clarity by clearly identifying the target users and the significance of functions, often proposing a delivery timeline for delivery according to priority.” (“MODELS_2025_paper_85”, p. 1) #5fb236
- “Nevertheless, it can pose new challenges if the user stories are not written properly or are misinterpreted due to their complexity and ambiguity, leading to increased workload, delays, and unmet user expectations [4].” (“MODELS_2025_paper_85”, p. 1) #5fb236
- “As a <actor/user> I want <goal/action> so that <reason/value>.” (“MODELS_2025_paper_85”, p. 1) #5fb236
- “time ,” (“MODELS_2025_paper_85”, p. 1) #ff6666
- “In this context, we introduce our tool, Story2Spec, powered by Deepseek, which automatically extracts requirements following the FURPS model [14]. This model is particularly beneficial for handling user stories because of their informal and varied nature.” (“MODELS_2025_paper_85”, p. 1) #a28ae5
- “Classifies user stories into requirements according to the FURPS model (functional, usability, performance, reliability, and supportability).” (“MODELS_2025_paper_85”, p. 2) #5fb236
- “Generates use case diagrams based on the extracted software requirements following the UML syntax language.” (“MODELS_2025_paper_85”, p. 2) #5fb236
- “Generate a complete description of the use cases based on a predefined template.” (“MODELS_2025_paper_85”, p. 2) #5fb236
- “A within-subjects study involving 12 software engineering analysts was conducted to assess the efficiency and usability of the Story2Spec tool compared to the baseline ChatGPT.” (“MODELS_2025_paper_85”, p. 2) #5fb236
- “[10] developed an NLP-based approach that integrates ontological modeling and Prolog rules to convert user stories into structured UML diagrams, including class, use case, and package diagrams.” (“MODELS_2025_paper_85”, p. 2) #5fb236
- “However, the model may struggle with user stories that are ambiguous or poorly organized, which could necessitate additional refinement or even human intervention.” (“MODELS_2025_paper_85”, p. 2) #5fb236
- “[15] utilized machine learning and NLP techniques to generate UML use case diagrams.” (“MODELS_2025_paper_85”, p. 2) #ffd400
*The subject of a sentence cannot be a bibliographic reference. This issue occurs many times in the related work section.*
- “ChatGPT requires high computational resources and encounters difficulties in appropriately interpreting domainspecific terms without further customized training or modification.” (“MODELS_2025_paper_85”, p. 2) #5fb236
- “. [17] presented a method based on Stanford CoreNLP to generate a sequence diagram and a collaborative diagram from natural language requirements” (“MODELS_2025_paper_85”, p. 2) #5fb236
- “Despite the progress made in deriving UML from user stories, the critical step of extracting detailed requirements is often overlooked [8], [9], [20], despite its importance.” (“MODELS_2025_paper_85”, p. 3) #a28ae5
- “This section describes the motivation example that drives our study as shown in 1” (“MODELS_2025_paper_85”, p. 3) #ff6666
*... shown in *Fig.* 1.*
- “rdadmap project” (“MODELS_2025_paper_85”, p. 3) #ffd400
*What is it about? Can you introduce it?*
- “analysts and experts usually extract these artifacts manually, which poses some challenges.” (“MODELS_2025_paper_85”, p. 3) #5fb236
- “Such manual work could be susceptible to human error, like overlooking some vital information or miscategorizing the requirements since these can differ from one analyst to another.” (“MODELS_2025_paper_85”, p. 3) #5fb236
- “Shifting toward automation can resolve the issues encountered with the manual approach.” (“MODELS_2025_paper_85”, p. 3) #5fb236
- “Story2Spec, which acts as a supportive solution for developers and analysts.” (“MODELS_2025_paper_85”, p. 3) #ffd400
*Why developers directly? The tool is supposed to extract requirements, right? Requirements are not taken as input directly from developers.*
- “Furthermore, our tool offers scalability over time since it can used for different projects of any size.” (“MODELS_2025_paper_85”, p. 3) #ff6666
*Many grammatical errors.*
- “1) Requirements classification, which aims to categorize requirements into functional, usability, performance, reliability, supportability, and others according to the FURPS model;” (“MODELS_2025_paper_85”, p. 3) #2ea8e5
- “2) Use case diagram generation: in this step, the deep seekbased model generates a UML use case diagram based on the input requirements;” (“MODELS_2025_paper_85”, p. 3) #2ea8e5
- “3) Use cases description Generation: each use case identified in the diagram will be systematically expanded into a comprehensive textual description including preconditions, postconditions, and flow of activities.” (“MODELS_2025_paper_85”, p. 3) #2ea8e5
- “Deriving requirements from user stories is an essential phase in the software development lifecycle, guaranteeing that user needs are comprehensively understood and converted into executable activities” (“MODELS_2025_paper_85”, p. 3) #5fb236
- “as shown in 2” (“MODELS_2025_paper_85”, p. 3) #ff6666
*as shown in Fig. 2*
- “shown in 3(I” (“MODELS_2025_paper_85”, p. 3) #ff6666
- “Fig. 2. User Requirement Classification Interface (Interface A)” (“MODELS_2025_paper_85”, p. 4) #ffd400
*It's not needed to consume page space to include a figure showing a file upload form.*
- “B. Use case diagram generation” (“MODELS_2025_paper_85”, p. 4) #ffd400
*The generation processes need to be properly presented. For instance, it is not clear the links from the use cases given in Fig. 4 and the classified user stories given in Fig.2 . A clear mapping description needs to be given. Also the need for the user stories classification has to be clearly motivated.*
- “V. EVALUATION” (“MODELS_2025_paper_85”, p. 5) #ffd400
*I suggest adding a dedicated subsections to present the metrics that have been used for the evaluation (i.e., precision, recall, F1-score, etc)*
- “To validate our work, we conducted a within-subjects study with 12 software engineering experts.” (“MODELS_2025_paper_85”, p. 5) #5fb236
- “as shown in I .” (“MODELS_2025_paper_85”, p. 5) #ff6666
*as shown in Table I*
- “We analyzed 10 projects that included 877 user stories.” (“MODELS_2025_paper_85”, p. 5) #ffd400
*How are these projects selected.*
- “Each expert was requested to evaluate the generated use case diagram based on the following evaluation question by rating them on a 5-point Likert scale (1 = Not at all, 2 = Slightly, 3 = Moderately, 4 = Mostly, 5 = Completely).” (“MODELS_2025_paper_85”, p. 5) #ffd400
*In my opinion, in the whole evaluation process also artifacts produced by humans and mixed with the automated ones need to be considered.  As it is the evaluation permits to evaluate the correctness of the considered artifacts, but not the completeness. The generation step from user stories can neglect some use stories making the generated use cases uncomplete.  This is why it is necessary to include also manually created use cases.*
- “by answering the following questions” (“MODELS_2025_paper_85”, p. 5) #ffd400
*Add an explici reference to Table III that includes the questions that need to be answered.*
- “To answer this question, the participants answer the questionnaire, which contains five questions ranging from (QE14 to QE18) by rating using the following scale: 1 = Strongly Disagree, 2 = Disagree, 3 = Neutral, 4 = Agree, 5 = Strongly Agree.” (“MODELS_2025_paper_85”, p. 6) #ffd400
*Add a reference to Table IV.*
- “We evaluated six projects (P1-P6), with two projects assessed by each of the 12 experts. Each evaluation includes responses to seven questions (QE1–QE7). We calculate the mean (M) and standard deviation (SD) for the six projects for each evaluation question.” (“MODELS_2025_paper_85”, p. 6) #5fb236
- “VII .” (“MODELS_2025_paper_85”, p. 6) #ff6666
*Table VII.*
- “We studied the efficiency of our story2spec tool compared to ChatGPT’s performance as shown in VII . It identifies actors and uses cases (QE1, QE2) for specific projects like projects 1 and 3. Some standard deviation values are high, which indicates that some generated diagrams might be incomplete or difficult to interpret. Additionally, ChatGPT faces some difficulties in providing the include/extend relationships between use cases due to a lack of deep knowledge about UML structure.” (“MODELS_2025_paper_85”, p. 6) #ffd400
*It is not clear if experts were aware or not of the language models that generated the artifacts under analysis. In other words, the experts were aware that were evaluating the use cases generated by ChatGPT or Story2Spec? This can be a potential bias. It is important to keep this aspect hidden.*
- “in VIII.” (“MODELS_2025_paper_85”, p. 7) #ff6666
*in Table VIII*
- “in IX” (“MODELS_2025_paper_85”, p. 7) #ff6666
*in Table IX*
- “chatGPT” (“MODELS_2025_paper_85”, p. 7) #ff6666
*ChatGPT. Please check carefully the paper to fix errors like this one.*
- “In this section, the 12 participants evaluate the usage of our tool story2spec and the baseline ChatGPT in terms of time, ease of use, and workload reduction, as shown in X. Each participant rates the evaluation questions on a 5-point Likert scale.” (“MODELS_2025_paper_85”, p. 7) #ff6666
*Typo and rephrase.*
- “This study introduces Story2Spec, a DeepSeek-based tool for helping analysts transform natural language user stories into structured UML diagram modeling. It initially classifies user stories into requirements according to the FURPS model (functional, usability, performance, reliability, and supportability). Next, it produces use case diagrams following the UML syntax and generates case descriptions based on predefined. To evaluate the performance of our tool, we conducted a withinsubjects study involving 12 software engineering experts with varying levels of experience. We compared our results with the baseline ChatGPT. The findings indicate that the Story2Spec tool is able to create clear and consistent use case diagrams and use case descriptions that comply with UML standards. Furthermore, the story2spec tool proves to be efficient in saving time and reducing the workload of the analysts. In future work, we aim to explore other UML diagrams, such as the class and sequence diagrams.” (“MODELS_2025_paper_85”, p. 8) #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.
pages/@MQ-LLM4DSL%3A module and quality driven domain-specific language design with large language models.md
+150
View File
@@ -0,0 +1,150 @@
tags:: [[#zotero]]
date:: 2018
title:: @MQ-LLM4DSL: module and quality driven domain-specific language design with large language models
item-type:: [[journalArticle]]
original-title:: MQ-LLM4DSL: module and quality driven domain-specific language design with large language models
language:: en
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/9QZM3S2R), [Web library](https://www.zotero.org/users/1039502/items/9QZM3S2R)
- [[Abstract]]
- Domain-Specific Languages (DSLs) are essential in software engineering, offering precise expression and excellent usability for specific domains, significantly improving software development efficiency. However, DSL design is challenging, requiring deep domain knowledge and language expertise to ensure quality. Mainstream DSL design methods use intermediate models like ontologies and metamodels to guide construction through manually defined rules, demanding substantial expert effort. Although some approaches transform ontologies into DSLs using explicit rules, ensuring full requirement retention remains a challenge. These methods primarily focus on the expressiveness of DSLs, while considerations for other quality aspects are insufficient. Some methods emphasize the evaluation of DSL during the design process and the improvement based on the evaluation results, incorporating this process as a part of the DSL design method. However, these methods do not provide clear improvement approaches based on specific evaluations. We propose the MQ-LLM4DSL method. This method utilizes the functional modules of domain corpus as an intermediate model for DSL design. It also provides specific improvement methods based on the core quality factors of the DSL and iteratively optimizes the quality of each step in the DSL design. Experimental results show that DSLs designed with MQ-LLM4DSL outperform those created using the baseline method, achieving an improvement: 22% in Expressiveness, 16% in Flexibility and 9% in EaseofLearn.
- ### Attachments
- [MQ-LLM4DSL_cleaned](zotero://select/library/items/5A6TMKFV) {{zotero-imported-file 5A6TMKFV, "MQ-LLM4DSL_cleaned.pdf"}}
- [PDF](zotero://select/library/items/DKM2YEJW) {{zotero-imported-file DKM2YEJW, "2018 - MQ-LLM4DSL module and quality driven domain-specific language design with large language models.pdf"}}
- ### Notes
- I'm reviewing a research paper and I took the following notes:
# Annotazioni
(16/5/2025, 19:27:20)
- “Although some approaches transform ontologies into DSLs using explicit rules, ensuring full requirement retention remains a challenge.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #5fb236
- “Some methods emphasize the evaluation of DSL during the design process and the improvement based on the evaluation results, incorporating this process as a part of the DSL design method. However, these methods do not provide clear improvement approaches based on specific evaluations.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #5fb236
- “Automatically generating high-quality DSLs from domain-specific corpora has long been an open research challenge, attracting significant interest from both academia and industry.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #5fb236
- “domain corpora as the functional requirements for DSL design” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #5fb236
- “Other quality requirements consist of usability, flexibility, etc” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #5fb236
- “Corpus2DSL” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #2ea8e5
- “Model2DSL” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #2ea8e5
- “The presence of conceptual models allows designers to build precise results based on their understanding of the requirements, which also achieves traceability of the design and reduces complexity by breaking down tasks” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #5fb236
- “Unfortunately, these methods focus on discussing the rationality of conceptual models and lack specific steps for building models and transforming them into DSLs.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #5fb236
- “Ontology2DSL” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #2ea8e5
- “[17, 33, 33]” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #ff6666
*Reference [33] occurs twice.*
- “Existing DSL design methods still require a significant amount of work from experts at different design stages.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #5fb236
- “Corpus2Model2DSL” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 1) #ffd400
*It's not shown in Fig. 1, isn't it?*
- “The above DSL design methods lack focus on improving DSL quality.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #5fb236
- “lack approaches to improve DSL quality through quality evaluation.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #5fb236
- “However, these methods do not provide clear improvement approaches based on specific evaluations” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #5fb236
- “two limitations of existing methods” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #ffd400
*Which one exactly?*
- “domain corpora to DSL design, and to ensure the expressiveness and other qualities of DSLs.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #5fb236
- “MQ-LLM4DSL(Figure 2)” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #ff6666
*A space is missing before the open parenthesis. There are many occurrences of the same problem.*
- “Based on this, clear executable steps for designing DSLs are provided so that LLMs can easily understand and execute the steps and present results. By summarizing and analyzing existing DSL evaluation methods, we have selected quality indicators and evaluation methods that can guide DSL improvement. Then, combining the DSL design steps with the evaluation methods, we provide methods for evaluation-feedback to further improve DSL quality.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #ffd400
*This description is vague and requires a concrete example to show what you plan to improve. A motivating and explanatory example would help understand the challenges the work aims to address.*
- “The method consists of the following four parts:” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #5fb236
- “1. Pattern Extraction: Use LLMs to extract entities, relationships, and other abstract concepts (referred to as elements) from domain corpora;” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #2ea8e5
- “2. Restructuring and Refining of the Functional Module Architecture: Use patterns as the initial functional modules, restructure the architecture based on the common parts of the patterns and the similar relationships among functional modules;” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #2ea8e5
- “3. Module DSL Design and Integration:” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #2ea8e5
- “M DSL” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #ffd400
*Is this a typo?*
- “Evaluation and Improvement:” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #2ea8e5
- “Figure 2:” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #ffd400
*According to the figure, it seems that the DSL quality evaluation process gives some input to the DSL development process. However, I would expect that there is also a connection on the other way round.*
- “quality during use and quality during maintenance.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 2) #5fb236
- “Therefore, we cannot improve the DSL based on the evaluation results of each quality indicator individually.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 3) #5fb236
- “we need to determine the relationship between various quality indicators and identify which quality assessments can guide DSL improvements” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 3) #5fb236
- “requirements, which is Expressiveness.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 3) #ffd400
*Only expressiveness? It seems you wanted to focus on more than one requirement.*
- “Expressiveness” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 3) #5fb236
- “Therefore, improvements to the DSL should prioritize Expressiveness. Then, consider quality indicators that have little to no impact on the existing Expressiveness during improvement. Finally, consider improvements that potentially affect Expressiveness. Based on this, select quality indicators that can provide information for DSL improvement. Following the aforementioned approach to filter existing DSL evaluation methods, we obtain the results(Table 2).” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 3) #ffd400
*this is not clear, it needs rewording.*
- “MQ-LLM4DSL ,” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 3) #ff6666
*extra space before ","*
- “3 Approach” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 3) #ffd400
*This section is high level and it looks like more a project proposal than a developed approach presentation. I suggest revise the whole section (and also the other ones) with the aim of making the paper more concrete and robust. It is necessary to present explanatory examples and real DSL cases that can be used to make the paper more concrete. Currently the paper is about DSL design and development, and there is no "trace" of DSL in the paper.*
- “Table 2: DSL evaluation methods for quality improvement” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 4) #ffd400
*The content of Table 2 is not properly supported by proper evidence. How have authors defined such quality indicators? I'm not convinced about them. For instance, many aspects are related to "Understanding" including the supporting tool of the considered DSL. You might have different implementations of the same DSL, and quality aspects may change. For instance, how would you cover graphical vs textual DSLs?*
- “Figure 4: MQ-LLM4DSL overview” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 4) #ffd400
*In my opinion, the process cannot be only unidirectional. Also back-propagation should be supported. During the development of the DSL it can be required to refine requirements in order to add some unforeseen ones or refine existing ones.*
- “3.1.1 Pattern Extraction.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 4) #2ea8e5
- “3.1.2 Functional Module Architecture Restructuring and Refinement.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 4) #2ea8e5
- “Refinement is then performed on the existing functional module architecture, further subdividing and designing modules that represent large, complex, or insufficiently clear functions, based on the existing architecture.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 4) #5fb236
- “3.1.3 Module DSLs Design and Integration.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 4) #2ea8e5
- “3.1.4 Quality Evaluation and Improvement.” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 5) #2ea8e5
- “Quality Evaluation and Improvement” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 6) #ffd400
*The approach is supposed to be quality driven, thus I would expect to have quality checks in different stages of the process, instead of having quality evaluations only the very end of the approach. It is difficult to understand how improvement are guided with the aim of improving the quality of the DSL under development. Moreover, it is not clear if the process shown in Fig. 4 has been actually implemented and tool supported.*
- “4.5 Detailed Experimental Setup” (“MQ-LLM4DSL: module and quality driven domain-specific language design with large language models”, 2018, p. 8) #ffd400
*Also this section needs details. It is not clear how the experiments have been actually executed. Currently, readers are supposed to download the package from zenodo and figure out on their own how the approach has been actually developed, what are the software components related to the what has been presented in the paper etc. It is necessary to make the paper self-explanatory and then readers taht want know more can explore the code. Not the vice versa.
*
COnsider that those that are tagget with #5fb236 are just highlights, those that are tagged with #e56eee and #a28ae5 are imporant 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 sentence to summarize the work
STRENGHTS:
WEAKNESSES:
COMMENTS: Organize the notes with respect to the following criteria:
-
`Novelty`
-
`Rigor`
-
`Relevance (of the contribution)`
-
`Verifiability and Transparency`
-
`Presentation`
And then add a Detailed Comments section to report the notets that contain issues or typos.
pages/@Management of Heterogeneous Data in Digital Editions%3A A Model-Driven Approach.md
+76
View File
@@ -0,0 +1,76 @@
tags:: [[#zotero]]
date:: 2024
title:: @Management of Heterogeneous Data in Digital Editions: A Model-Driven Approach
item-type:: [[journalArticle]]
original-title:: Management of Heterogeneous Data in Digital Editions: A Model-Driven Approach
language:: en
authors:: [[Sebastian Enns]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/8KNLJ85P), [Web library](https://www.zotero.org/users/1039502/items/8KNLJ85P)
- [[Abstract]]
- The increasing use of web technologies in the Digital Humanities presents new opportunities for handling domain-specific content but also introduces challenges, particularly due to the heterogeneity of data models. Users of this domain often encounter difficulties in finding or configuring systems for their Digital Editions that can manage complex documents and perform necessary adjustments. This frequently results in self-management, where users must set up and maintain intricate technical infrastructures. To address these issues, a multi-level modeling architecture is proposed for integrating and managing heterogeneous data in Digital Editions. This model-driven infrastructure abstracts elements and relationships across various projects, enhancing interoperability and customization. Key contributions include the development of a meta-model, the implementation of multi-level modeling techniques, and the creation of tools such as a modeling tool, data importer, text editor, and web page generator. These tools are going to improve the efficiency, flexibility, and sustainability of essential processes in Digital Editions, encompassing the conception, elaboration, and publication phases. The approach is going to evaluate, how a modeldriven infrastructure based on a platform-independent multi-level modeling approach will improve the efficiency and applicability of the technology in the aforementioned steps of Digital Editions.
- ### Attachments
- [File PDF](zotero://select/library/items/92IXTQVM) {{zotero-imported-file 92IXTQVM, "Enns - 2024 - Management of Heterogeneous Data in Digital Editions A Model-Driven Approach.pdf"}}
- ### Notes
- # Annotazioni
(18/7/2024, 16:58:01)
- “Heterogeneous Data in Digital Editions” (Enns, 2024, p. 1) #5fb236
- “Digital Editions” (Enns, 2024, p. 1) #ffd400
*What do you mean? What are they?*
- “multi-level modeling architecture is proposed for integrating and managing heterogeneous data in Digital Editions.” (Enns, 2024, p. 1) #a28ae5
- “across various projects, enhancing interoperability and customization” (Enns, 2024, p. 1) #a28ae5
- “multi-level modeling techniques, and the creation of tools such as a modeling tool, data importer, text editor, and web page generator.” (Enns, 2024, p. 1) #ffd400
*Check the related work.*
- “Digital Editions are scholarly publications that provide foundational material for research in the humanities and cultural studies in digital form” (Enns, 2024, p. 1) #a28ae5
- “conception phase” (Enns, 2024, p. 1) #5fb236
- “conception phase, the data model is developed, the subject of the edition is determined, contents and questions are defined, and the relationships within and outside the edition are established.” (Enns, 2024, p. 1) #a28ae5
- “Elaboration” (Enns, 2024, p. 1) #5fb236
- “involves exploring the contents through the description and transcription of documents, as well as establishing metadata standards.” (Enns, 2024, p. 1) #a28ae5
- “Publication” (Enns, 2024, p. 1) #5fb236
- “includes the release of the edited subjects in a suitable environment” (Enns, 2024, p. 1) #a28ae5
- “data model was developed” (Enns, 2024, p. 1) #a28ae5
- “model transformations of the actual data model of the edition” (Enns, 2024, p. 1) #5fb236
- “ther, the variety and complexity of technologies in the Digital Humanities often lead to inadequate and inefficient tools that do not meet specific research requirements [41]. Additionally, these tools often lack user-friendliness and demand significant dedication to master [35]. Large, standardized infrastructures are often too rigid, costly, and unable to adequately support the dynamic, innovative needs of Humanities research” (Enns, 2024, p. 1) #ffd400
*All of these motivations are peculiar and need to be presented by complementing the text with reference to some concrete examples.*
- “heterogeneous data, obsolete tools and complex technical infrastructures,” (Enns, 2024, p. 1) #5fb236
- “Using multi-level modeling, further model layers can be created based on a meta-model, which can extend the existing model with additional conditions and aspects” (Enns, 2024, p. 2) #5fb236
- “abstraction of elements and relations from data models of existing Digital Editions” (Enns, 2024, p. 2) #a28ae5
- “model-driven infrastructure that includes an additional domain-specific model layer based on a meta-model.” (Enns, 2024, p. 2) #ffd400
- “This infrastructure will enable the integration and management of heterogeneous data for Digital Editions in the Digital Humanities.” (Enns, 2024, p. 2) #ffd400
*It's not clear what's the contribution of this work with respect to existing techniques to manage hybrid polystores. What are the specificities of the considered application domain that make existing solutions unsuitable for it?*
- “Enhancing the interoperability of various elements within Digital Editions by providing a common meta-model that can be adapted to different projects” (Enns, 2024, p. 2) #ffd400
*What are the technical challenges that you foresee?*
- “Allow domain experts to tailor the domain-specific layer and tools to fit the specific needs of their projects, ensuring that unique aspects of their data are adequately addressed.” (Enns, 2024, p. 2) #ffd400
*There are low-code tools that permit to create custom data management systems. What are the novelties that you see from this aspect?*
- “While the specific attributes and models are tailored to the needs of the CensusIRL project, they are based on generic principles of data modeling and process definition that could be reused in other similar projects” (Enns, 2024, p. 2) #ffd400
*What are the limitations of such tools that justify and require the development of another approach?*
- “However, the current lack of a cohesive framework to manage heterogeneous data models hinders the efficiency and applicability of technologies” (Enns, 2024, p. 2) #ffd400
*A motivating example is required here otherwise it is not clear what are the peculiar requirements of the quested approach. Without such discussions, it seems that the author is talking about typical data-intensive applications, which can be engineered with several existing tools.*
- “6 Current status The recent research focused on identifying the topic and the necessary preliminary work. This includes an initial literature review in the field of platform-independent modeling and the examination of existing Digital Editions in the Digital Humanities.” (Enns, 2024, p. 4) #ffd400
*The paper is missing a clear description of the peculiarities of the considered application domain. Moreover, it is not clear if the perspective work mainly consists of applying existing technologies, without envisioning novelties, further than the implementation of a framework managing Digital Editions.*
pages/@Map and Its Impact on the Functional Safety of Automated Driving Vehicles.md
+23
View File
@@ -0,0 +1,23 @@
date:: [[25-09-2023]]
issn:: 2949-9372
extra:: Publisher: Athena Publishing
doi:: 10.55060/j.jseas.230925.001
title:: @Map and Its Impact on the Functional Safety of Automated Driving Vehicles
item-type:: [[journalArticle]]
access-date:: 2023-09-28T10:45:04Z
original-title:: Map and Its Impact on the Functional Safety of Automated Driving Vehicles
language:: en
url:: https://www.athena-publishing.com/journals/jseas/articles/256
publication-title:: Journal of Software Engineering for Autonomous Systems
authors:: [[Vishwanath Nagnath
library-catalog:: www.athena-publishing.com
links:: [Local library](zotero://select/library/items/2R2EDVZF), [Web library](https://www.zotero.org/users/1039502/items/2R2EDVZF)
Pai]], [[Ion Barosan]], [[Arash Khabbaz
Saberi]]
- [[Abstract]]
- The increasing progress of Automated Driving (AD) technologies emphasises the significance of maps in ensuring the safety of these AD systems. While research has been conducted on the safety of AD systems themselves, the role of maps has not been thoroughly explored. In this article, we aim to address this gap by conducting an analysis to quantify the...
- [[Attachments]]
- [Nagnath Pai et al_2023_Map and Its Impact on the Functional Safety of Automated Driving Vehicles.pdf](https://files.athena-publishing.com/article/256.pdf) {{zotero-imported-file XUCSGTU9, "Nagnath Pai et al_2023_Map and Its Impact on the Functional Safety of Automated Driving Vehicles.pdf"}}
pages/@MicroArc%3A Event Driven Analysis and Design Method for Microservice Based Systems.md
+13
View File
@@ -0,0 +1,13 @@
tags:: [[#zotero]]
title:: @MicroArc: Event Driven Analysis and Design Method for Microservice Based Systems
item-type:: [[journalArticle]]
original-title:: MicroArc: Event Driven Analysis and Design Method for Microservice Based Systems
language:: en
authors:: [[Ali Yildiz]], [[Onur Demirors]]
library-catalog:: Zotero
links:: [Local library](zotero://select/library/items/LIUMGVSB), [Web library](https://www.zotero.org/users/1039502/items/LIUMGVSB)
- [[Abstract]]
- The rapid development of the Internet infrastructure has enabled software applications to leverage almost unlimited and scalable resources. Microservice-based architecture has emerged as a solution to harness the benefits of a distributed cloud-based infrastructure. Event-driven architecture is a powerful approach for addressing challenges in distributed systems, such as scalability, distributed data, and sharing of data at scale. In an event-driven microservice architecture, decoupled services interact by responding to events and event streams facilitate data sharing between them. Despite these advantages, there is no de facto method for the analysis and design of systems within microservice architecture. Organizations often face difficulties in developing microservice-based systems, owing to the lack of well-defined methodologies for analysis and design. In this study, we present an analysis and design method for microservicebased systems. MicroArc is a method for analyzing and designing microservice-based systems, and comprises modeling notations and guiding processes to articulate how the method is applied. The MicroArc approach enables the identification of events and microservice candidates by modeling the flow of processes in the early phase of development.
- ### Attachments
- [Yildiz e Demirors - MicroArc Event Driven Analysis and Design Method for Microservice Based Systems.pdf](zotero://select/library/items/3LW8QF7T) {{zotero-imported-file 3LW8QF7T, "Yildiz e Demirors - MicroArc Event Driven Analysis and Design Method for Microservice Based Systems.pdf"}}

Some files were not shown because too many files have changed in this diff Show More