logseq/pages/@MODELS24_paper_2827.pdf.md

tags:: #zotero title:: @MODELS24_paper_2827.pdf item-type:: document original-title:: MODELS24_paper_2827.pdf links:: Local library, Web library

• Attachments

  • MODELS24_paper_2827.pdf {{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? *