Issue 10836: Section: 8.1.2 p. 40 (uml-corba-ccm-ftf) Source: Fraunhofer FOKUS (Ms. Julia Reznik, julia.reznik@fokus.fraunhofer.de) Nature: Clarification Severity: Minor Summary: Initiated by Tom Rutt (Fujitsu) "According to the metamodel for UML (uml super fig 7-12 and 7-13) the OwnedAttribute association end of class and data type is ordered, and includes both "attributes" and "association ends". So from UML point of view the Struct mapping is ok in the current spec. (However some tools have trouble ordering across attributes and association ends). The FTF may decide to not use the association version of containment for Struct members which are themselves complex types Resolution: Revised Text: Actions taken: March 21, 2007: received issue November 7, 2007: closed issue Discussion: For better dealing with ordering of Struct members and for simplifying the representation of Struct type in general the association representation for members has been removed from the profile. Changes: P.40: Text: “or as an Association (for user-defined typed members)” has been removed. P.41. Figure 8.12 has been replaced in: (figure 8.12 on page 16 of ptc/2007-06-08) End of Annotations:===== m: webmaster@omg.org Date: 21 Mar 2007 05:15:27 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Julia Reznik Company: Fraunhofer FOKUS mailFrom: reznik@fokus.fraunhofer.de Notification: No Specification: UML Profile for CORBA and CORBA Components Final Adopted Specification Section: 8.1.2 FormalNumber: ptc/2007-03-11 Version: 1 RevisionDate: 03.21.07 Page: 40 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.10) Gecko/20070216 Firefox/1.5.0.10 Description Initiated by Tom Rutt (Fujitsu) "According to the metamodel for UML (uml super fig 7-12 and 7-13) the OwnedAttribute association end of class and data type is ordered, and includes both "attributes" and "association ends". So from UML point of view the Struct mapping is ok in the current spec. (However some tools have trouble ordering across attributes and association ends). The FTF may decide to not use the association version of containment for Struct members which are themselves complex types." Date: Mon, 07 May 2007 14:15:08 -0400 From: Tom Rutt Subject: Re: The UML Profile for CORBA and CORBA Components: FTF Ballot number 1 To: Julia Reznik Cc: uml-corba-ccm-ftf@omg.org Reply-To: tom@coastin.com User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) Here is my vote on FTF ballot 1 Issue 10834: Yes Issue 10835: NO: neads clarification: the replacement text: "Array members are represented by an attribute of the DataType, which always has the name .members. (profile keyword), .members. type is represented by the type of the attribute. The array size (dimensions) is represented by the tag .index. of the DataType. The size of an one-dimensional array can be also represented by the multiplicity of the attribute .members. (e.g.: .index.=n or [0..n-1]), otherwise it can be a list of integers separated by comma where each integer represents the size of each multidimensional array dimension (e.g.: .index.=n, m)." is unclear why there are two ways to represent array index . Do all arrays representations have a Tag for index, even if the attribute multiplicity is used in the case of one dimensional array. It should state that the multiplicity for a multi dimension array is the product of all the dimension values (e.g, integer [2][3] has multiplicity 6. Also, it needs to be clarified whether the member attribute is in row major or collumn major order. Issue 10836, 10838: yes , however need to fix bug in example before issuing report: I have an editiorial correction noted for the figures on Issue 3. < A first attribute should have type A::B rather than B.with clarification Issue 10837: yes Tom Rutt Fujitsu Julia Reznik wrote: Dear UML-CORBA&CCM FTF voting members, could you please vote within 2 weeks (*Deadline: 21 May 2007* ) on the resolutions to proposed to the following issues (see attached archive with an issue description document and a new final adopted spec with change bars): ----------- Voting Form ----------- (Mark each Issue with *YES*, *NO *or *ABSTAIN *based on resolutions proposed in attached document) Issue 10834: Issue 10835: Issue 10836: Issue 10837: Issue 10838: Many many thanks in advance, Julia Reznik -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Date: Tue, 08 May 2007 15:23:31 +0200 From: Julia Reznik User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) To: tom@coastin.com Cc: uml-corba-ccm-ftf@omg.org Subject: Re: The UML Profile for CORBA and CORBA Components: FTF Ballot number 1 X-OriginalArrivalTime: 08 May 2007 13:23:25.0491 (UTC) FILETIME=[0EDC7030:01C79174] Dear Tom, thanks a lot for your prompt answer. Tom Rutt schrieb: Here is my vote on FTF ballot 1 Issue 10834: Yes Issue 10835: NO: neads clarification: the replacement text: "Array members are represented by an attribute of the DataType, which always has the name .members. (profile keyword), .members. type is represented by the type of the attribute. The array size (dimensions) is represented by the tag .index. of the DataType. The size of an one-dimensional array can be also represented by the multiplicity of the attribute .members. (e.g.: .index.=n or [0..n-1]), otherwise it can be a list of integers separated by comma where each integer represents the size of each multidimensional array dimension (e.g.: .index.=n, m)." is unclear why there are two ways to represent array index . You are right, it's confusing, indeed. The profile should give one and clear-defined possibility to represent array indexes. I had the feeling that I have to use UML multiplicity (since it's given) for index of an one-dimensional array... but we can not use it for multidimensional arrays and, again, I agree with you, it's confusing to have more than one representations. Ok, I suggest that all arrays representations must have a tag for index: one-dimensional arrays: .index.=n, where n is an integer and represents the size of array dimension, the multiplicity of the attribute "members" is not used here. multidimensional arrays: .index.=n, m,...,k, where n,m,k are integers and represent the size of each multidimensional array dimension. And one important thing I forgot to mention in the submission: all array dimensions must be specified. IDL does not support open arrays like [] because IDL does not support pointers. So, n, m,... should be greater than 0. Do all arrays representations have a Tag for index, even if the attribute multiplicity is used in the case of one dimensional array. It should state that the multiplicity for a multi dimension array is the product of all the dimension values (e.g, integer [2][3] has multiplicity 6. We don't need this, I don't see a real use for this kind of information. Also, it needs to be clarified whether the member attribute is in row major or collumn major order. Tom, you are thinking of two-dimensional arrays (row major or column major order), or? But I thing, I know what do you mean. An array type definition determines the number of elements of an array, but IDL does not specify how arrays are to be indexed in different implementation languages. This means that the implementation of array indices is language mapping specific. I would say that dimensions of an array must have the same order as defined (or should be defined) in IDL. What do you think about that? Tom, should I issue your comments regarding arrays in order to be able to vote again? Issue 10836, 10838: yes , however need to fix bug in example before issuing report: I have an editiorial correction noted for the figures on Issue 3. < A first attribute should have type A::B rather than B.with clarification Ok! Here is the same: I have to issue you comment to be able to do changes (replace Figure) in the specification, or? Kind regards, Julia Issue 10837: yes Tom Rutt Fujitsu