Section 2.2 Pag. 5, What does "obligatory" mean in Table 1? The

advertisement
Section 2.2
1. Pag. 5, What does "obligatory" mean in Table 1? The change description does not distinguish
between obligatory and non-obligatory.
2. Why is "generalize metaproperty" not considered an updative change?
3. Why is "pull metaproperty" not also considered a subtractive change?
4. Are considered changes on the navigability or aggregation status of a association?
5. I think should be indicated which two properties are considered: attributes and references (but
not associations).
Maybe, it could be more appropriate a change taxomony organized by types of metamodels
elements (like taxonomy defined by Wom Kim for object database schemas), and then the
changes can be classified according to the three categories of table 1.
6. Pag. 6. When the KM3Diff metamodel is introduced could be useful to illustrate it with a
difference model for the MM of the Petri net. This model would help to explain how PTArc and
TPArc are represented so they are considered refinements instead of new relationships.
7. Pag. 6. The sentence "In such situations, the modifications in table 1 refer to the same elements
.." is not clear. what does "same elements" refer to? You should indicate which are the
dependent changes when the evolution MM0 a MM2 is direct. The effect of CTr and CT-r
transformations should be indicated using the Petri net example.
8. Pag. 7, I think the paragraph below Figure 3 is incomplete, maybe a sentence has been eliminated
by a careless mistake. This sentence would appear just before the last sentence "The main
problem .." refering to "parallel dependent".
9. Pag. 7, The definition of parallel dependency is confused. The notation owner|type| supertypes -> {change-type metaclasses} have not been explained. Is it necessary to introduce owner, type
and supertypes in the definition?
10. It is clear if you add a metaproperty (unresolvable) to a superclass obtained by either an
superclass extracting operation or whose type is this new superclass (resolvable) then a
dependency exists between the modifications, do you need refer to owner, type and supertype
meta-attributes.
Section 3
11. Pag. 8. Why all the changes in table 1 have not been included in table 2?
12. You should explain the meaning of R and -R in cells of Table 2.
Section 3.1
13. Pag. 10. It would be nice you use an only running example instead of using Petri net example and
fig. 4 example.
Sarebbe da stravolgere il lavoro. Comunque c’è un altro review che dice che gli esempi vanno bene
quindi io salterei questo punto
14. Pg.9: replace “supertTypes” with “supertypes”
Perche? E’ il nome di una funzione usata anche in diverse figure. Ho lasciato cosi
15. Section 3.1 enumerates and demonstrates each type of interdependency. I feel that two or three
examples would suffice. Full results are presented in Table 2. Describing each combination is
unnecessary.
Ora ci stanno e li lascerei.
16. Furthermore, the example data could benefit from being more concrete. In particular, using
descriptive class and attribute names (e.g. Person and age) would be less confusing than the
current examples.
C’e’ uno dei reviewer che dice che gli esempi sono buoni quindi lascerei cosi’
17. "For instance, if the introduction of PTArc and TPArc... would be represented as the deletion and
addition of those new entities, all the existing connections between arcs and transitions would
be lost." This is an interesting point. However, it is not clear how an algorithm for comparing two
versions of a metamodel can distinguish between, say, a renaming and a deletion followed by an
addition. Does this affect the classification of metamodel changes and/or the process for
resolving interdependencies?
Ho aggiunto questo: In this respect, the quality of the approach used for the difference calculation
may affects the results of the proposed co-adaptation technique. In other words, depending on the
metamodels being considered, difference algorithms have to be properly chosen or customized.
Interested readers can refer to~\cite{KDPP09} which summarizes the already existing approaches
for model matching
Section 3.2 and Figure 8
18. For example: why was this particular algebraic encoding used and how was it helpful? (There is
only an explanation of the encoding itself, not the rationale behind it).
Ho messo questo, un po riaggiustato da quello che c’era prima: “In this section we propose an
approach to identify and resolve the dependencies which have been discussed in the previous
section. The approach is based on the concepts of sets and functions which will enable a precise
and formal identification and manipulation of dependencies among atomic changes.”
19. The semantics of the graphical notation in figure 8 not clear to me: What do the ovals represent
(sets) and why are they necessary here? Is there any significance to the overlaps of the ovals and
the graphical order in which they appear (some kind of ordering?)? This needs to be explained a
lot better and more rationale provided.
Ho messo: Please note that the overlaps of the ovals and the graphical order in which they appear
have no semantics and their layout is related to presentation purposes only.
20. I found Figure 8 very difficult to understand; it could benefit from a legend for the shaded areas,
and dashed and solid lines.
21. Provide some justification for the statement that this approach can be applied in a practical
sense to any other meta-metamodel. Or, alternatively, if the answer is unclear identify it
explicitly as an open question.
Ho aggiunto questo: The implementation of the approach relies on the KM3 metamodeling
language~\cite{KM3} which provides metamodeling constructs consisting of a common subset of
OMG/MOF~\cite{MOF} and EMF/Ecore~\cite{EMF}. The applicability of the proposed co-evolution
approach with respect to the metamodeling elements which are not included in such a subset is an
open issue and it will be investigated in the near future.
22. Pag. 13. What fragment of the difference model in Fig. 6 is encoded in Fig. 8?
The sets and the functions in Figure~\ref{fig:signatureAndFunctions} enables the encoding of
models conforming to the KM3 difference metamodel as in the example in
Figure~\ref{fig:algebraicModelEncoding} which depicts the encoding of a fragment of the
difference models in Figure~\ref{fig:decomposedDeltaModel}. More specifically, the
elements~\texttt{ac3}, ~\texttt{aa1} and \texttt{a1} of
Figure~\ref{fig:decomposedDeltaModel}.a,~\texttt{cc1},~\texttt{c1},~\texttt{ac2},~\texttt{cc2}, and
\texttt{c2} of Figure~\ref{fig:decomposedDeltaModel}.b are represented.
23. Figure 8 is very complicated. I think it is necessary an explanation of the notation used in Fig. 8
24. How is obtained this figure? How is the difference model encoded from the algebraic
specification? Do you need specify axioms?
C’era gia’ questo che ho leggermente modificato: In particular, an algebra signature is directly
derived from the KM3 difference metamodel whose elements define sorts and functions as
reported in Figure~\ref{fig:signatureAndFunctions}. This
operation can be performed in an automated way by means of dedicated model transformations as
shown in~\cite{DiRuscio07,ATLSEM}.
25. How are expressed difference models by an algebraic specification?
26. What do "a1,..an, b1,..bm" terms denote in definition 1?
27. How are sorted out the dependent changes by an algebraic encoding?
Ho tolto “sort out” vedi 18
28. The technique is independent of the metamodel, but is dependent of the metamodeling
language?
Vedi 21
29. Pag. 14, What do ";", "|" and "-" symbols denote in expression (2)?
30. The paragraph below expression (2) is not clear.
31. How can I implement this proposal? The authors do not indicate that the approach has been
implemented, insteda they indicate that a systematic validation will be done in the future.
In short, I think the paper need some important changes and I don't see how the proposal is
implemented in a MDE tool.
Download