In subclause 6.4.3, it states that enumeration type names "always end with 'Type' (e.g., 'OperatorType')." This is not true. Enumeration type names in the profilr actually all end in "Kind" (which is consistent with usual OMG practice). There is also no "OperatorKind" enumeration; the only two enumerations in the specifiacation are DSTypeKind and RangeKind.

Enumeration type name convention correction

In subclause 6.4.3, the statement about the convention of enumeration type names is incorrect.

The first paragraph of subclause 6.2.5 is poorly worded. In particular, the first sentence is too long and both the first two sentences are rather convoluted and hard to understand.

Rewrite first paragraph of Clause 6.2.5

The first paragraph of Clause 6.2.5 needs to be rewritten.

Equation 6-8 in subclause 6.2.3 does not seem to be correct.

The second term on the right-hand side has y _k in the denominator, which is inconsistent with the left-hand side. This term also begins with the partial derivative of y _k with respect to x _j, but x _j has been posited to relate to y _l, not y _k, so presumable the partial derivative in question is zero. Therefore, perhaps only the first term on the right-hand side is necessary.

Even though this section is not part of the normative profile, it is important background and should be correct.

Correction of Equation 6-8

The second term on the right hand side of this equation should be removed due its vanishing value.

Subclause 6.2.1 includes the comment "The ROSETTA formalism further supports the rigorous development of structures for the design of systems and the assemblage of systems of systems that mathematically interpret the methods of Nam Suh on Axiomatic Design theory." However no reference is given for this "Axiomatic Design theory". Such a reference should be added to the list of non-normative references in 3.2, and this should be cited in 6.2.1.

Update non-normative references

Axiomatic Design theory is an essential theory being referred to in the ROSETTA framework, a reference is needed for readers who are interested in the theory.

The current position of the reference for Quality Function Deployment is misplaced and should be updated.

In Clause 4, the term "relational structure" is defined as "A defined collection of relations". However, the term "relation" is not defined. Presumably this is intended to mean a mathematical relation, but it would be better to include an explicit definition of this fundamental term.

Definition of the term "relation"

The term "relation" is a fundamental term used in the specification, and needs to be formally defend in Clause 4 with the other fundamental terms.

SysML is mentioned in several places in the specification document, and it is used for the example in Annex B. Therefore, the SysML standard should be included in the list of non-normative references.

Adding a non-normative reference for SysML

A SysML standard reference should be included since SysML is referred in the specification.

Subclause 1.3 ends with the sentence: "The contributors believe that this is a vendor specific concern that would best be served by a longer term RFP, should there be interest, if and when the UPR RFC is finalized." This is not appropriate for a standard specification document.

The "RFC" is an OMG process, which is now actually over. It is the beta specification resulting from that process that is now being finalized. But the specification will not even become available in non-beta form unless it is finalized, so it also doesn't make sense for the document to refer to "if and when...[it] is finalized."

The sentence should be removed.

Inappropriate statement on RFC/RFP

The statement, "The contributors believe that this is a vendor specific concern that would best be served by a longer term RFP, should there be interest, if and when the UPR RFC is finalized." was addressed to the ADTF and AB prior to adoption of the specification. And it is no longer appropriate to include in the current specification, hence need to be removed.

The UPR XMI file includes an operator library, corresponding to the model shown in Figure 8-2 in the specification document. As shown in that figure, the operator classes in this library should all have the OperatorSemantics stereotype applied. However, these stereotype applications are missing from the XMI file.

Add missing stereotype applications

Fix the XMI generator in order to add missing stereotype applications as requested by the issue.

In Figure 8-1, there is an association directly between the stereotypes ComparisonOperator and OperatorSemantics. The intent seems to be for a stereotyped literal string to provide the name of the comparison operator associated with an operator semantics class. However, while such an association between stereotypes is technically legal syntactically (because stereotypes are kinds of classes), there is no standard way to instantiate it, because the standard does not require a tool to implement stereotyping using actual stereotype instances.

An alternative would be to associate the OperatorSemantics stereotype directly to LiteralString, requiring that the LiteralString be stereotyped by ComparisonOperator. However, this seems unnecessarily heavyweight. Instead, it would be much simpler to simply give OperatorSemantics a symbol: String property and move the applyTo operation to OperatorSemantics. The ComparisonOperator stereotype would then be entirely unnecessary.

Merge with UPR-4

The solution investigated for resolving UPR-4 removed the stereotypes this issue is about

In the definition of the UPRConstraint::comparisonOperator in subclause 7.3.2.2, it is assumed that the name of the comparison operator is given by the string value of the constraint specification property. However, UML requires that a constraint specification evaluates to a Boolean value, not a string (see the well-formedness constraint Constraint::boolean_value, UML 2.5.1, 7.8.3.6).

An alternative would be to require the constraint specification property to be an opaque expression returning a Boolean value, whose body is the name of the comparison operator. If the language property was also required to be "UPR", then this would indicate that the comparison for the constraint was to be carried out using the semantics as given in the UPR specification.

UPRConstraint specified by an OpaqueExpression

UPRConstraint specified by an OpaqueExpression

This resolution proposal is based on the principle described in the comments of the related issue, with slight modifications as suggested in the issue description.

The Constraint::Specification property of an UPRConstraint will use a OpaqueExpression. The language of that opaque expression shall be "UPR" and its body shall be the symbol of the operator to be applied. The semantics of the operator is encoded in a class specializing OperatorSematicsClass. This abstract class has two operations:

• a "symbol" operation, with no input parameter, returning the string value representing the operator symbol to be used in the body of the UPRConstraint specification
• an applyTo operation, with two input parameters (one for each operand), intended for returning the result of the comparison specified by this operator

The symbol() operation provided with the OperatorSemanticsClass makes the ComparisonOperator stereotype useless. It can removed from the profile, making it simpler.

The library shall be adjusted to cope with the modification described above.

The normative XMI for the profile and library needs to be correspondingly updated.

The updated XMI, profiles in .MDZip files (MagicDraw), and diagrams shall be provided in the submission package.

As introduced in subclause 6.4.1, each of the subsequent normative clauses contain domain models as well as specifications for the UML profile itself. It should be clarified as to what the normative force is of these domain models.

Normative force of the domain models

The resolution of this issue is merged with the resolution to UPR-2

The conformance clause only requires syntactic conformance with application of the profile. Since the whole point of the profile is to support the semantics of a specific analysis framework, the current conformance requirement seems lacking. While it is reasonable to separate syntactic from semantic conformance into different conformance points, there should still be a clear semantic conformance point.

• Adding a semantic conformance point*

The current conformance clause lacks a semantic conformance point. The proposed new conformance clause is restructured to clearly indicate the two conformance points: which are (1) the previous syntax conformance point; and (2) the new conformance point that requires a conforming tool must able to extract the information modeled by the stereotypes according to the domain models provided in the specification.

The purpose of introducing the domain models is to present the semantic knowledge (to be modelled by using UPR stereotypes) and structure of the semantic knowledge being supported by the ROSETTA framework. These knowledge are essential to facilitate trade-offs and analyses methods supported by ROSETTA framework, for example, UT-B and UT-R as described in subclauses 6.2.4 and 6.2.5 respectively. As such, the normative force for an implementation of the semantics of the domain model is to model the semantic knowledge, such as Constraints and Sensitivities specifically as defined in the specification, in a structured way to allow agile extraction of the information. The information can then be used by analysis tools to perform trade-offs and analyses methods such as UT-R and UT-B. It is important to note that the actual analyses are not within the scope of the normative force of the domain models. The last sentence added in the new Semantic Conformance reflects the above normative force.

The current title of the specification, as submitted, is "UPR: UML Profile for the Relational Oriented Systems Engineering Technology Trade-Off and Analysis Framework (ROSETTA)". While the intent is to position the profile as being for the existing ROSETTA "framework", the connotation of "framework" to most modelers make the profile seem both more heavyweight and specific than it really is. It is suggested to rename the specification to "UML Profile for Relational Oriented Systems Engineering Technology Trade-Off and Analysis", dropping both the "the" and "framework".

Change of Profile Title

The name of the profile should be renamed into "UML Profile for Relational Oriented Systems Engineering Technology Trade-Off and Analysis (ROSETTA)".

The profile diagrams in subclauses 7.3.1, 8.2.1, 9.3.1, 10.3.1 and 11.3.1 contains non-standard usages of model elements, particularly, owned operations and owned rules, which should be removed.

Revision of profile diagrams

The profile diagrams in subclauses 7.3.1, 8.2.1, 9.3.1, 10.3.1 and 11.3.1 are update with the removal of the non-standard usage of owned operations and owned constraints.

The evaluation() operation of the UPRConstraint cannot work and the parameter types applyTo() operation of the OperatorSemanticsClass has to be adjusted as well.

Indeed, the evaluation of the UPRConstraint can only work on value specifications. That is: the value of a property has to be considered, not the property itself. So the evaluate() operation requires an input parameter that specifies the value to be compared to the value specified by the constraint.

Merged with UPR-4

The resolution of this issue is merged with the resolution to UPR-4 and UPR-5