[Ccsds-omg-liaison] an AB review of the SOLM submission (space/2010-11-01 & 02)

[hugues.vincent]

Dear SOLM submitters,


Here are my first comments as AB reviewer of the "Spacecraft Operations Language  Metamodel" submission (space/2010-11-01 & 02).


The main issue wrt this submission is that it offers a metamodel as well as a UML  Profile when only a metamodel was required by the RFP. This is not only a formal issue  (ie submitters trying to standardize more than what requested and voted by the DTC) but also  a cause for lack of interest from the tooling communitee. I really believe that a SOLM  profile would have done better with an interest from the tooling communitee:
- better implementability in the tooling all the over the market,
- better choice of reused metamodel elements such as stereotyped metaclasses (see my  comments afterwards).


Even if I doubt of the relative "lawfulness" of the complete work, I reviewed it  entirely:
- Figure 2 - page3: please specify what the arrows mean in this figure.

- Page 3: "This specification ... provides the potential for mapping into different  PSM's using the model transformation ...": what do you mean by "potential"? The RFP  were asking for standardized mapping: is it or not?

- Section 2: The conformance point is not clear. I propose to:
	- Move the 1st, 3rd, 4th and 6th paragraph to the section 1 because they hold  explanations rather than conformance points.
	- Start with "This specification defines 2 conformance types:"
	- Follow with the "A SOLM modeling environment" paragraph and the "A SOLM  execution environment" paragraphs.
One last comment on conformance points, the "execution environment" conformance points  is not similar to the one on "modeling environement". Is it on purpose?

- Section 6 - page 6 last sentence ("Each interaction ... operations log"): replace  "should be" with "must be".

- Section 6 - page 7 - 1st and 2nd paragraph: As far as I understood this, you include  the whole UML activity metamodel in your metamodel and you say that this metamodel is  too complex for some of the targeted languages:
	- one issue here is that the semantics behind the UML activities is not crystal  clear and that's what fUML (Semantics of a Foundational Subset for Executable UML  Models - ptc/09-10-05) has been created. Clearly, fUML is something that definitely  should be considered for SOLM.
	- another issue is what to do with things that have been modeled but can't be  understood with the target language? 
	- all in all, is the aim of the metamodel to be able to generate an executable  script from the content of a M1 model modelized by your metamodel, OR is it the  opposite: generating a M1 model from a script. The former case is what I had understood  when reading the intoduction of the spec, the latter one is what I tend to understand  with these paragraphs (and, actually, with the annexes).

- Section 6 - page 7 - last pargraph - "a stereotype for a Verify node": stereotype are  for profiles while this section is speaking of the metamodel: metaclass.

- Section 6.7 - Tab line 6.5.1 & 6.5.4: I won't discuss the theoretical "can a UML  profile be considered as a MOF compliant metamodel?". Yet, if the metamodel is the UML  profile specified in section 7, what is section 6 for?

- Section 6.7 - Tab line 6.5.5: As already said, it seems to me than the appendixes  give language to SOLM mapping rather than the opposite that what asked for in the RFP.

- Section 6.7 - Tab line 6.5.8: UML activity doesn't hold clear enough semantics for a  mapping to executable languages: consider fUML

- Section 7 - overall comments:
	- stereotypes have a lot of attributes and associations: that doesn't seem  "user friendly" in most UML tools!
	- Almost all stereotypes extends the metaclass "Class". That seems a bit odd  when SOLM includes UML activity: what about extending an activity metaclass?

- Section 7.3, 7.4 and 7.5: these stereotypes extends other stereotypes. Even if UML  allows that kind of things, I doubt that that was the intent; what about inheritance?

- Section 7.10: ParameterType is an enumeration. Why is it defined as extending the  metatclass "Property"?

- Section 7.16.1: is it Decision or DecisionNode ?

- Appendiwes A and B: If (as requested by the RFP), these parts are mandatory, please  move them in the core text, ie as non annex.




These comments don't preclude any further comments from me or other AB members.

Best regards,
Hugues VINCENT
OMG Architecture Board Member
hugues_vincent (at) omg.org