Unlike the previous paper, we're doing better here - no deeply embedded OO conceit right from the start. And 'conforms to' is the first relation that shows up.
Section 2 is a survey of existing tools.
Section 3 gets into the meat of things, by offering fairly concrete definitions. The starting point is, as usual, a graph (directed multigraph). "model-based" anything seems to always want to end up being visual, so it's hard to escape graphs, even though it's not always clear that that's the right answer. Again, there is a notion of conformance (with too much emphasis on nodes... and no types as both edges and nodes go to nodes). Interestingly, there is a need for self-reference if one wants finitely many levels!
The advantage, in a sense, is that everything is a graph, so operations are simple to define. This disadvantage is that it's not clear that graph-level operations are actually meaningful when the graph is interpreted as a model. It looks to be too reductionist a formalism.This untypedness and fuzzyness should up already in definitions 6 and 7; the match operation "searches" (!) for equivalences!
It's disappointing that definition 9, "model transformation", mentions "rules". And "set of models"? If a set of models is an important entity, why not give it a name? And then, a model transformation should be some kind of homomorphism of that entity, not just a function.
For example, it feels like Definition 6 (Correspondence model) is trying to say "monomorphic graph homomorphism" but with a lot of verbiage. Compose (Def'n 10) is unclear, but it feels like pushout? Or is that Merge?
The section 4 first talks about requirements (good, but fuzzy), and then looks at what the existing tools to.
It's cited a lot. Too much to go through.
No comments:
Post a Comment