type:: [[REVIEWS]] tags:: year:: 2024 venue:: [[MODELS]] full-title:: A Self-Extension Mechanism for Domain Specific Languages: A Foundation for Model Libraries date-start:: [[28-04-2024]] - 22:12 date-submitted:: [[01-05-2024]] external-links:: status:: [[DONE]] deadline-submission:: [[26-04-2024]] file:: [[@MODELS24_paper_2991.pdf]] parent:: todoist:: https://app.todoist.com/app/task/2991-a-self-extension-mechanism-for-domain-specific-languages-a-foundation-for-m-7858701420 - ### [[Highlights]] - # Annotazioni - (1/5/2024, 11:22:22) - - “require” ([“MODELS24_paper_2991.pdf”, p. 1](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=1&annotation=824VHA4L)) #ff4400 - *Not very clear and convincing* - - “Occasionally, a few languages solve this as an example of their technological space.” ([“MODELS24_paper_2991.pdf”, p. 1](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=1&annotation=G6QUP4Y7)) #f0ff00 - *Uml profile? Whats new? So far is not clear* - - “concludes” ([“MODELS24_paper_2991.pdf”, p. 2](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=2&annotation=ZBRVCYB4)) #f0ff00 - *What?* - - “MaCoCo” ([“MODELS24_paper_2991.pdf”, p. 2](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=2&annotation=WAB6JL25)) #f0ff00 - *What's the link with monticore?* - - “This design is a foundation of the self-extension mechanism, which we describe in more detail in the following sections.” ([“MODELS24_paper_2991.pdf”, p. 3](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=3&annotation=YYGF48N8)) #f0ff00 - *Up to now it I not clear.* - - “Extendable concepts:” ([“MODELS24_paper_2991.pdf”, p. 3](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=3&annotation=XC9W9B44)) #f0ff00 - *Are they linked to some application domain?* - - “While this feature is essential for providing reusable libraries, it does not necessarily have to be part of the DSL. It often makes sense to reuse the packaging mechanisms” ([“MODELS24_paper_2991.pdf”, p. 3](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=3&annotation=FSTZ7JZU)) #f0ff00 - *What does it mean?* - - “reprocessed” ([“MODELS24_paper_2991.pdf”, p. 3](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=3&annotation=F2WWHFME)) #f0ff00 - *What?* - - “GUI” ([“MODELS24_paper_2991.pdf”, p. 4](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=4&annotation=QGDTZDYA)) #f0ff00 - *What's the need for mentioning the two versions of the gui dsl?* - - “GUI component declaration with its implementation, where the implementation consists of components imported from other models and instantiated as a part of the component.” ([“MODELS24_paper_2991.pdf”, p. 4](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=4&annotation=X7KIDCX4)) #f0ff00 - *Needs to be clarified with examples. It is not clear until now.* - - “The presented approach differs from the GUI DSL 1, where components are a part of the DSL grammar and models only” ([“MODELS24_paper_2991.pdf”, p. 4](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=4&annotation=BUM3HCJ9)) #f0ff00 - *Is this relevant? I would present dsl2 without the née for mentioning dsl1. What do we loose if we have only dsl2 in the discussion* - - “self-extension mechanism eliminates the need to modify artifacts at the” ([“MODELS24_paper_2991.pdf”, p. 4](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=4&annotation=HK6RN9FL)) #f0ff00 - *Why self? What de the characteristics that distinguish the self? What' the difference between self and not self?* - - “Data structure” ([“MODELS24_paper_2991.pdf”, p. 5](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=5&annotation=3HGGJZKJ)) #f0ff00 - *No associations?* - - “despite having two versions of the pages)” ([“MODELS24_paper_2991.pdf”, p. 5](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=5&annotation=6ZGU3Z2P)) #f0ff00 - *Why is it relevant to see both?* - - “After the component is added to the language, the app modeler integrates it into the models.” ([“MODELS24_paper_2991.pdf”, p. 6](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=6&annotation=52KH39VZ)) #f0ff00 - *How?* - - “The app modeler moves the common layout to a new model specifying the component. (3) The app modeler directly” ([“MODELS24_paper_2991.pdf”, p. 7](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=7&annotation=ZFPM6CM4)) #f0ff00 - *How is the semantics of the component specified? Even in this case language engineer might be required because users might not have the knowledge to add components.* - - “self-extension” ([“MODELS24_paper_2991.pdf”, p. 7](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=7&annotation=32AURMS8)) #f0ff00 - *Why self?* - - “Table 2: Lines of code (LoC) for GUI components” ([“MODELS24_paper_2991.pdf”, p. 7](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=7&annotation=JFGG3Z3H)) #f0ff00 - *I'm not convinced about this metric. Comments have to be developed anyhow and such a metric is not linked and do not leverage the main novelty of the approach I. E. The possibility of adding new components by relying on some reusable libraries. Te way components are concretely added is not explained. For instance is it possible to do so during modeling sessions? Or it is necessary to import all the required components before starting the specification of models?* - - “implementation is always higher and stays within 20% difference, which, besides GUI DSL 2 syntax being more compact than Java in” ([“MODELS24_paper_2991.pdf”, p. 7](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=7&annotation=QS95867X)) #f0ff00 - *A qualitative discussion about such a 20% is missing.* - - “Since the amount of code remains within the same bounds for both GUI DSL versions and the code does not change its meaning, the effort spent on the component implementation is similar.” ([“MODELS24_paper_2991.pdf”, p. 7](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=7&annotation=D3HIXNCN)) #f0ff00 - *Exactly, that's the point!!!* - - “adding or changing the component by a language engineer.” ([“MODELS24_paper_2991.pdf”, p. 7](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=7&annotation=NGRKLBAG)) #f0ff00 - *I think that the required competences are almost the same, so what's the point here.* - - “Workflow in GUI DSL 2” ([“MODELS24_paper_2991.pdf”, p. 8](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=8&annotation=5REI7ZXD)) #f0ff00 - *In this case the app modeler should still have language engineering competences. If not you should convincingly prove it.* - - “This communication includes providing the specification to the language engineer and notifying the app modeler of deploying the new language version. In our experience working with GUI DSL 1, the development delay introduced by the communication between two teams varied from several minutes to several full working days. Such a delay due to communication needs quickly accumulates with continuous requirement changes and new language users.” ([“MODELS24_paper_2991.pdf”, p. 8](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=8&annotation=H6W2ELPG)) #f0ff00 - *Communication seems the main aspect that the proposed approachd deals with. However so far the validation is mainly on LOC and is not about communication aspects and does not show in quantitative extent how it is improved.* - - “To summarize, the self-extension mechanism simplifies the workflow for introducing a new domain concept, such as a GUI component in our example. We observe the benefits when dealing with isolated cases of component creation. However, the mechanism has tradeoffs, which we discuss in the next section.” ([“MODELS24_paper_2991.pdf”, p. 8](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=8&annotation=M8RQ99ZM)) #f0ff00 - *This is not so evident. You should involve people in doing so.* - - “against” ([“MODELS24_paper_2991.pdf”, p. 8](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=8&annotation=YEXJC75C)) #f0ff00 - *Why against?* - - “s” ([“MODELS24_paper_2991.pdf”, p. 8](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=8&annotation=SRERWBKE)) #f0ff00 - *Extra s* - - “Developing, deploying, integrating, and maintaining the infrastructure for a model library creates additional work since it requires additional scripts that implement the importing” ([“MODELS24_paper_2991.pdf”, p. 8](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=8&annotation=X6M43UPW)) #f0ff00 - *That's a good point and the paper does not discuss such an infrastructure to manage/store/provision model libraries.* - - “In our example, the overview component is implemented by a language developer (GUI DSL 1) or an app modeler (GUI DSL 2). GUI DSL 2 that has the self-extension mechanism demands a” ([“MODELS24_paper_2991.pdf”, p. 8](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=8&annotation=TTNPHE6M)) #ff4400 - *It does not parse.* - - “created 38 library components.” ([“MODELS24_paper_2991.pdf”, p. 8](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=8&annotation=PPKCK3BN)) #f0ff00 - *Can you mention their competencies?* - - “If a DSL is built for modelers with narrow expertise, a selfextension mechanism will introduce a challenge since it pushes concepts to a modeling level, bringing the DSL closer to a GPL.” ([“MODELS24_paper_2991.pdf”, p. 9](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=9&annotation=IPW46FT4)) #f0ff00 - *I agree see my previous comments.* - - “With GUI DSL 2, the modeler must understand how to define a new layout template in a model to utilize the selfextension mechanism efficiently. If the component implementation is entirely delegated to a library developer, the advantage of the reduced communication overhead discussed in this work has no effect.” ([“MODELS24_paper_2991.pdf”, p. 9](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=9&annotation=HXIDH6DG)) #f0ff00 - *I agree!!!!* - - “Our work specifies conditions and creates a model library.” ([“MODELS24_paper_2991.pdf”, p. 9](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=9&annotation=LNM34YAN)) #f0ff00 - *Where?* - - “whereas our approach is to create a new DSL or rework an existing one.” ([“MODELS24_paper_2991.pdf”, p. 9](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=9&annotation=WZ3KI2QU)) #f0ff00 - *I think it is similar to the uml idea.* - - “mechanism that supports a model library without modifying the DSL.” ([“MODELS24_paper_2991.pdf”, p. 9](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=9&annotation=UNCL63W7)) #f0ff00 - *What are the concepts that you allow to extend?* - - “prerequisites, including self-extension, import, and packaging mechanisms.” ([“MODELS24_paper_2991.pdf”, p. 9](zotero://select/library/items/B4VSXD4W)) ([pdf](zotero://open-pdf/library/items/X3GY4N54?page=9&annotation=2F7DJPAK)) #f0ff00 - *I the paper only the concept of self extension is discussed. The other two concepts are not prsenteded technically.* - ### [[Comments]] - #.tabular - Summary of the paper - The paper presents an extension mechanism for Domain-Specific Languages to facilitate the addition of new modeling constructs at the model level. Unlike traditional programming languages that provide extension capabilities via libraries, the proposed permits users to extend DSLs without altering the original language, facilitating continuous adaptation to new requirements. Applied to a GUI DSL, the mechanism enables modelers to introduce and reuse concepts directly within models. - Summary of main points for/against the paper - +Interesting and relevant problem - +The proposed approach has been implemented and used to develop a system in production - -The benefits of the approach have not been convincingly presented - -The LOC as the main metric to evaluate the proposed extension mechanism is not appropriate - - Limited validation - - Detailed evaluation - While the paper highlights the benefits of the self-extension mechanism, there is limited validation, particularly regarding its impact on communication overhead and workflow efficiency. - Some concepts mentioned in the paper, such as import and packaging mechanisms, are not adequately presented or discussed, leaving gaps in understanding the overall approach. - The paper introduces the term 'self-extension' without providing a clear rationale for the use of 'self.' - While I appreciate the authors' attempt to highlight the strengths of GUI DSL 2 compared to its predecessor, GUI DSL 1, I believe their goal falls short. The technical distinctions in terms of abstraction levels where extensions operate are evident. However, I remain unconvinced that the role of the language engineer can be completely eliminated in the case of GUI DSL 2. Instead, the app modeler depicted in Fig. 6.b is expected to possess more technical knowledge than the one shown in Fig. 6.a. Developing the semantics of the modeling constructs to be added at the model level inherently requires competencies from a language engineering perspective. - The paper lacks a convincing description of the applicability of the approach to any modeling language. In Section 3, the authors introduce the concept of 'Extendable concepts,' but fail to establish a clear link or provide management details relevant to the considered application domain. Additionally, the paper briefly mentions 'import' and 'packaging mechanisms' in the same section, but fails to adequately explain or discuss these concepts later in the paper. Regarding 'packaging mechanisms,' the authors state, 'While this feature is essential for providing reusable libraries, it does not necessarily have to be part of the DSL. It often makes sense to reuse the packaging mechanisms.' However, the meaning of this statement is unclear and requires further elaboration for better understanding. - The description of the steps described at page 6 needs to be improved. For instance, step 4 should give details on how and when modelers can integrate the newly developed language component. - Concerning step 2 of the workflow discussed on page 7, in my opinion, even in that case, language engineers can be required because users might not know how to add new language components. - Based on my previous points, I recommend removing the discussion on GUI DSL 1 to create space for a more thorough explanation of the strengths and limitations of GUI DSL 2. This will allow for the inclusion of more technical details and an enhanced evaluation of the proposed mechanism. - Concerning section 5 (and Tab. 7), I remain unconvinced about using Lines of Code (LOC) as a metric. While components need to be developed regardless, this metric does not align with or fully leverage the main novelty of the approach, which is the ability to add new components through reusable libraries. Furthermore, the process of adding components is not adequately explained. For example, it is unclear whether components can be added during modeling sessions or if all required components must be imported before model specification begins. Clarifying these implementation details would enhance understanding and evaluation of the proposed approach. - The gain of 20% in terms of LOC requires a qualitative discussion concerning the aspects related to the communications of the involved stakeholders. These aspects are mentioned in different parts of the papers but misses a rigorous treatment and validation. - Even the last paragraph of Section 5 is not convincing: "To summarize, the self-extension mechanism simplifies the workflow for introducing a new domain concept, such as a GUI component in our example. We observe the benefits when dealing with isolated cases of component creation. However, the mechanism has tradeoffs, which we discuss in the next section." LOC cannot be used to assess the introduced workflow simplifications. - Questions to authors (rebuttal phase) - How can the authors convincingly demonstrate to readers that a 20% reduction in Lines of Code (LOC) is beneficial for simplifying the workflow required to extend the DSL at hand? - In my opinion, the app modeler utilizing the proposed extension mechanism should possess some level of language engineering competencies. Can you provide convincing arguments to the contrary? - ### [[REVIEWS/Notes]]