Issue 5953: Sequence metatype (deployment-ftf) Source: Zuehlke Engineering (Mr. Frank Pilhofer, fpilhofer2008(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: This is an issue for the Deployment FTF: The sequence metatype is not required in MOF. Parameter and attribute multiplicities should be used instead. Proposed resolution: In section 3.3, "Model Diagram Conventions", delete paragraphs 9 ("This specification is aligned with MOF 1.4 ...") and 10 ("Note- Instances of the Sequence metaclass ...") and the diagram preceding paragraph 9. Add paragraph: "This specification uses the notation of placing the multiplicity in square brackets after the type, as in "label: String [1]". If the multiplicity is omitted from an attribute, parameter or return value, the default of one to one is used." Throughout the document, replace all occurences of the Sequence type with the new notation. In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation", in the Generic Transformation Rules subsection, rewrite paragraphs 3 ("Wherever the multiplicity at the navigable end of a navigable association ...") and 4 ("A similar rule is applied for all uses of the Sequence data type ...") to read: Wherever the multiplicity of an attribute, parameter or return value is not exactly one (but 0..1, 1..* or *), a new class is introduced to represent a sequence of the type of the attribute, parameter or return value. The sequence class has the <<CORBA- Sequence>> stereotype, and its name is the english plural of the name of the type. The sequence class has a composition association with the element class that is navigable from the sequence to the element. The composition is qualified with the index of the sequence. The attribute, parameter or return value is then replaced with an attribute, parameter or return value, respectively, with the same name as before, but with the type being the newly introduced sequence class and the exactly one (1..1) multiplicity. A similar rule is applied to all navigable association or composition ends whose multiplicity is not exactly one (but 0..1, 1..* or *): a new class is introduced to represent a sequence of the class at the navigable end, this sequence class is defined as described above. The original association or composition end is then replaced with a navigable association or composition end, with the same role name as before, at the new sequence class, with a multiplicity of exactly one (1..1). According to the rules in the UML Profile for CORBA, these associations and compositions will then map to a structure member in IDL, its type being a named sequence of the referenced type. Excepted from the two rules above are attributes, parameters, return values or navigable association or composition ends where the type is String, unsigned long or Endpoint, Instead of defining new sequence types, the existing types in the CORBA package are being used; see below. In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation", in the Special Transformation Rules subsection, rewrite the items for "Sequence(String)", "Sequence(unsigned long)" and "Sequence(End- point)" to talk about "Sequence of String", "Sequence of unsigned long" and "Sequence of Endpoint", respectively. Resolution: Revised Text: Actions taken: June 19, 2003: received issue Discussion: End of Annotations:===== Subject: Sequence metatype Date: Thu, 19 Jun 2003 09:51:46 -0400 Thread-Topic: Sequence metatype Thread-Index: AcM2aezZOcGG1hw6SpiMCCi81LOC2g== From: "Pilhofer, Frank" To: Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h5JDpZkM002379 This is an issue for the Deployment FTF: The sequence metatype is not required in MOF. Parameter and attribute multiplicities should be used instead. Proposed resolution: In section 3.3, "Model Diagram Conventions", delete paragraphs 9 ("This specification is aligned with MOF 1.4 ...") and 10 ("Note- Instances of the Sequence metaclass ...") and the diagram preceding paragraph 9. Add paragraph: "This specification uses the notation of placing the multiplicity in square brackets after the type, as in "label: String [1]". If the multiplicity is omitted from an attribute, parameter or return value, the default of one to one is used." Throughout the document, replace all occurences of the Sequence type with the new notation. In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation", in the Generic Transformation Rules subsection, rewrite paragraphs 3 ("Wherever the multiplicity at the navigable end of a navigable association ...") and 4 ("A similar rule is applied for all uses of the Sequence data type ...") to read: Wherever the multiplicity of an attribute, parameter or return value is not exactly one (but 0..1, 1..* or *), a new class is introduced to represent a sequence of the type of the attribute, parameter or return value. The sequence class has the <> stereotype, and its name is the english plural of the name of the type. The sequence class has a composition association with the element class that is navigable from the sequence to the element. The composition is qualified with the index of the sequence. The attribute, parameter or return value is then replaced with an attribute, parameter or return value, respectively, with the same name as before, but with the type being the newly introduced sequence class and the exactly one (1..1) multiplicity. A similar rule is applied to all navigable association or composition ends whose multiplicity is not exactly one (but 0..1, 1..* or *): a new class is introduced to represent a sequence of the class at the navigable end, this sequence class is defined as described above. The original association or composition end is then replaced with a navigable association or composition end, with the same role name as before, at the new sequence class, with a multiplicity of exactly one (1..1). According to the rules in the UML Profile for CORBA, these associations and compositions will then map to a structure member in IDL, its type being a named sequence of the referenced type. Excepted from the two rules above are attributes, parameters, return values or navigable association or composition ends where the type is String, unsigned long or Endpoint, Instead of defining new sequence types, the existing types in the CORBA package are being used; see below. In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation", in the Special Transformation Rules subsection, rewrite the items for "Sequence(String)", "Sequence(unsigned long)" and "Sequence(End- point)" to talk about "Sequence of String", "Sequence of unsigned long" and "Sequence of Endpoint", respectively. Subject: Updated proposed resolution for issue 5953 Date: Wed, 23 Jul 2003 17:14:42 -0400 Thread-Topic: issues 5953 - 5955 -- Deployment FTF issues Thread-Index: AcM7XESXAvHtUadGEdeMjQCgyTbmFwWAqJLg From: "Pilhofer, Frank" To: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h6NLBZkM007912 This is an update of the proposed resolution for issue 5953: The sequence metatype is not required in MOF. Parameter and attribute multiplicities should be used instead. The wording on the default attribute multiplicity was changed based on the discussion in today's telecon: The resolution for issue 5953 was accepted with one amendment to replace "default of one to one" (which sounds like multipli- cities on both ends of an association) with "default of exactly one [1]". The full text of the updated proposed resolution follows: In section 3.3, "Model Diagram Conventions", delete paragraphs 9 ("This specification is aligned with MOF 1.4 ...") and 10 ("Note- Instances of the Sequence metaclass ...") and the diagram preceding paragraph 9. Add paragraph: "This specification uses the notation of placing the multiplicity in square brackets after the type, as in "label: String [1]". If the multiplicity is omitted from an attribute, parameter or return value, the default of exactly one [1] is used." Throughout the document, replace all occurences of the Sequence type with the new notation. In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation", in the Generic Transformation Rules subsection, rewrite paragraphs 3 ("Wherever the multiplicity at the navigable end of a navigable association ...") and 4 ("A similar rule is applied for all uses of the Sequence data type ...") to read: Wherever the multiplicity of an attribute, parameter or return value is not exactly one (but 0..1, 1..* or *), a new class is introduced to represent a sequence of the type of the attribute, parameter or return value. The sequence class has the <> stereotype, and its name is the english plural of the name of the type. The sequence class has a composition association with the element class that is navigable from the sequence to the element. The composition is qualified with the index of the sequence. The attribute, parameter or return value is then replaced with an attribute, parameter or return value, respectively, with the same name as before, but with the type being the newly introduced sequence class and the exactly one (1..1) multiplicity. A similar rule is applied to all navigable association or composition ends whose multiplicity is not exactly one (but 0..1, 1..* or *): a new class is introduced to represent a sequence of the class at the navigable end, this sequence class is defined as described above. The original association or composition end is then replaced with a navigable association or composition end, with the same role name as before, at the new sequence class, with a multiplicity of exactly one (1..1). According to the rules in the UML Profile for CORBA, these associations and compositions will then map to a structure member in IDL, its type being a named sequence of the referenced type. Excepted from the two rules above are attributes, parameters, return values or navigable association or composition ends where the type is String, unsigned long or Endpoint, Instead of defining new sequence types, the existing types in the CORBA package are being used; see below. In section 6.4, "PIM for CCM to PSM for CCM for IDL Transformation", in the Special Transformation Rules subsection, rewrite the items for "Sequence(String)", "Sequence(unsigned long)" and "Sequence(End- point)" to talk about "Sequence of String", "Sequence of unsigned long" and "Sequence of Endpoint", respectively.