1. OMG Mailing List
  2. UML Profile for ROSETTA Finalization Task Force

Open Issues

  • Issues not resolved
  • Name: upr-ftf
  • Issues Count: 15

Issues Descriptions

Non-standard usage in profile diagrams


The specification property of a UPRConstraint cannot be a string

  • Key: UPR-4
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Sat, 9 Feb 2019 00:03 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT
  • Attachments:

The first paragraph of 6.2.5 is poorly worded

  • Key: UPR-12
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Sat, 9 Feb 2019 01:06 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT

Enumeration type names do not end in "Type"

  • Key: UPR-13
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Sat, 9 Feb 2019 01:10 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT

The evaluate() operation of OperatorSemanticsClass cannot work as specified

  • Key: UPR-26
  • Status: open  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Tue, 7 May 2019 06:19 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT

There should be a non-normative reference for SysML

  • Key: UPR-8
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Sat, 9 Feb 2019 00:38 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT

The term "relation" should be defined

  • Key: UPR-9
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Sat, 9 Feb 2019 00:42 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT

There should be a reference for Axiomatic Design theory

  • Key: UPR-10
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Sat, 9 Feb 2019 00:45 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT

Equation 6-8 is incorrect

  • Key: UPR-11
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Sat, 9 Feb 2019 01:03 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT

The way the ComparisonOperator sterotype is used will not work

  • Key: UPR-5
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Sat, 9 Feb 2019 00:20 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT

Stereotype applications are missing from the UPR XMI file

  • Key: UPR-6
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Sat, 9 Feb 2019 00:25 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT

Scope should not refer to the UPR RFC

  • Key: UPR-7
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Sat, 9 Feb 2019 00:34 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT

There should be a semantic conformance point

  • Key: UPR-2
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Fri, 8 Feb 2019 23:45 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT

What is the normative force of the domain models?

  • Key: UPR-3
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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.

  • Reported: UPR 1.0b1 — Fri, 8 Feb 2019 23:47 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT

Revise the name of the specification

  • Key: UPR-1
  • Status: open  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    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".

  • Reported: UPR 1.0b1 — Fri, 8 Feb 2019 23:43 GMT
  • Updated: Fri, 24 May 2019 14:33 GMT