UML Profile for ROSETTA Avatar
  1. OMG Specification

UML Profile for ROSETTA — Closed Issues

  • Acronym: UPR
  • Issues Count: 15
  • Description: Issues resolved by a task force and approved by Board
Open Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

Enumeration type names do not end in "Type"

  • Key: UPR-13
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Resolved — UPR 1.0
  • Disposition Summary:

    Enumeration type name convention correction

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

  • Updated: Tue, 8 Oct 2019 17:59 GMT

The first paragraph of 6.2.5 is poorly worded

  • Key: UPR-12
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Resolved — UPR 1.0
  • Disposition Summary:

    Rewrite first paragraph of Clause 6.2.5

    The first paragraph of Clause 6.2.5 needs to be rewritten.

  • Updated: Tue, 8 Oct 2019 17:59 GMT

Equation 6-8 is incorrect

  • Key: UPR-11
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Resolved — UPR 1.0
  • Disposition Summary:

    Correction of Equation 6-8

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

  • Updated: Tue, 8 Oct 2019 17:59 GMT

There should be a reference for Axiomatic Design theory

  • Key: UPR-10
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Resolved — UPR 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Oct 2019 17:59 GMT

The term "relation" should be defined

  • Key: UPR-9
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Resolved — UPR 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Oct 2019 17:59 GMT

There should be a non-normative reference for SysML

  • Key: UPR-8
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Resolved — UPR 1.0
  • Disposition Summary:

    Adding a non-normative reference for SysML

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

  • Updated: Tue, 8 Oct 2019 17:59 GMT

Scope should not refer to the UPR RFC

  • Key: UPR-7
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Resolved — UPR 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Oct 2019 17:59 GMT

Stereotype applications are missing from the UPR XMI file

  • Key: UPR-6
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Resolved — UPR 1.0
  • Disposition Summary:

    Add missing stereotype applications

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

  • Updated: Tue, 8 Oct 2019 17:59 GMT

The way the ComparisonOperator sterotype is used will not work

  • Key: UPR-5
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Duplicate or Merged — UPR 1.0
  • Disposition Summary:

    Merge with UPR-4

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

  • Updated: Tue, 8 Oct 2019 17:59 GMT

The specification property of a UPRConstraint cannot be a string

  • Key: UPR-4
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Resolved — UPR 1.0
  • Disposition Summary:

    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.

  • Updated: Tue, 8 Oct 2019 17:59 GMT
  • Attachments:

What is the normative force of the domain models?

  • Key: UPR-3
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Duplicate or Merged — UPR 1.0
  • Disposition Summary:

    Normative force of the domain models

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

  • Updated: Tue, 8 Oct 2019 17:59 GMT

There should be a semantic conformance point

  • Key: UPR-2
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Resolved — UPR 1.0
  • Disposition Summary:
    • 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.

  • Updated: Tue, 8 Oct 2019 17:59 GMT

Revise the name of the specification

  • Key: UPR-1
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. 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
  • Disposition: Resolved — UPR 1.0
  • Disposition Summary:

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

  • Updated: Tue, 8 Oct 2019 17:59 GMT

Non-standard usage in profile diagrams


The evaluate() operation of OperatorSemanticsClass cannot work as specified

  • Key: UPR-26
  • Status: closed  
  • Source: Airbus Group ( Mr. 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
  • Disposition: Duplicate or Merged — UPR 1.0
  • Disposition Summary:

    Merged with UPR-4

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

  • Updated: Tue, 8 Oct 2019 17:59 GMT