Issues for Mailing list of the UML Profile for CORBA and CCM Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 10834: Section: 8.1.2
Issue 10835: Section: 8.1.2 p. 44
Issue 10836: Section: 8.1.2 p. 40
Issue 10837: clarification about relationships of specifications needed
Issue 10838: More clarification text about order of CORBAStruct members is needed
Issue 10981: Section: 3 Normative References
Issue 10982: Section: 7.2.10
Issue 10983: Section: 7.3.3
Issue 11009: Section: 8.1.2
Issue 11010: Section: 8.1.2, Figure 8.12
Issue 11158: Section: 8.1.2
Issue 11159: Section: 8.2.1 - 2
Issue 12359: Section 9 of UML Profile for CORBA and CCM

Issue 10834: Section: 8.1.2 (uml-corba-ccm-ftf)

Initiated from Tom Rutt (Fujitsu: "The sequence mapping needs either fixing or clarification. I am still concerned about the complexity and yet incompleteness of the profile mapping for CORBA sequences and arrays. Suggestion: AnonymousSequence types are named by concatenation containing type "::" "m"<n> , where n is the member number of the anonymous sequence in containing type, e. g bar::m2 for second member of Struct bar (P. 31, Figure 8.15). Also I suggest to represent the sequence element values as a multivalued attribute with lower bound 0 and upper bound = sequence size or "*". This seems to work and is much easier to understand. Also, it requires NO NEW TAGGED VALUES for Sequencies." 

Initiated from Tom Rutt (Fujitsu): "Something similar to Sequences could be done for array mappings as well."

Resolution:
Due to arrays are multidimensional using of lower bound and upper bound for the
representing of array members is not enough, this solution is good for one
dimension data structures (sequences are one-dimensional arrays). The
suggestions have been adopted as follows:
• Both named and anonymous arrays are represented by the UML
DataType;
• Tag “type” is removed from the profile;
• Array members are represented by an attribute of the DataType with the
name “members” (profile keyword), members type is represented by the
type of the “members”-attribute and the array size is represented by the
tag value “index”. 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,
where n, m,... should be greater than 0, since CORBA IDL does not
support open arrays like “a []” because IDL does not support pointers.
• To clarify how elements of multidimensional arrays are to be ordered the
profile should use the same convention as GIOP, which is quoted from
CORBA/IIOP Specification, Chapter 15.3.2.4 „Array”: “In multidimensional
arrays, the elements are ordered so the index of the first dimension varies
most slowly, and the index of the last dimension varies most quickly.”
• Anonymous arrays get a name by concatenation of name of the containing
type plus "::" plus "m"<n>, where n is the member number of the
anonymous array in containing type.
Changes:
• CCMProfile Metamodel: tag “type” has been deleted from the
stereotype “CORBATemplate”, the extension link between classes
“Property” and “CORBAAnonymousArray” has been deleted, a new
relationship between classes “CORBAAnonymousArray” and
“DataType” has been added. P. 37, Figure 8.7: attributes “index” and “type” have been deleted from
the class “CORBATemplate”;
• P.44 Text:
o “Named by a typedef declaration arrays are represented by the
UML DataType with the stereotype <<CORBAArray>>. The
upper bound of the array is modeled as a tag “index”of the
DataType, and can be either a number (upper bound of the one
dimentional array) or a list of integers separated by comma
where each integer represents the size of each multidimensional
array dimensions. Named by a typedef CORBAArrays have a
tag “type”, which represents the element type of the array.
o Named by the member name of a constructed type arrays are
represented by the UML Property (attribute) with the stereotype
<<CORBAAnonymousArray>>. This stereotype has also the tag
“index” representing the index of the array and described
above.”
has been replaced in:
o “Named by a typedef declaration arrays are represented by the
UML DataType with the stereotype <<CORBAArray>>. 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 value of the tag „index“ is a list of integers
separated by comma where each integer represents the size of
each multidimensional array dimension (e.g.: "index"=n, m).
One-dimensional arrays are represented as “index”=n, where n
is an integer and must be greater than 0.
o Named by the member name of a constructed type arrays are
represented by the DataType with the stereotype
<<CORBAAnonymousArray>>. Anonymous arrays get a name
by concatenation name of the container (containing type), "::"
and "m"<n>, where n is the member number of the anonymous
array in the container. This stereotype has also the tag “index”
representing the index of the array described above.”
• P 44, Figure 8.17 and 8.18 have been replaced according to changes
done in the specification: ((figure 8.17 on page 15 of ptc/2007-06-08))         Figure 8.17, Figure 8.18
• P 45 Text:
“Since CORBA IDL does not support open arrays like "typedef short s
[];" because IDL does not support pointers, integer m,n and k must be
greater than 0.” has been added.
• P 45 Text:
“CORBA IDL array determines the number of elements of an array, but
IDL does not specify how elements of the multidimensional arrays are
to be ordered for data transfer between agents. Therefore, for common
and correct understanding of CORBA UML models the same
convention as GIOP (defined in CORBA/IIOP Specification, Chapter
15.3.2.4 “Array”) is used: the array members represented by the
“members” attribute are always in row major order. In row major
ordering the leftmost index (or index of the first dimension) varies most
slowly, and the rightmost index (or index of the last dimension) varies
most quickly.” has been added.

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

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)

Initiated by Frank Pilhofer (Mercury Computer Systems: At the moment there are two OMG specification documents: the UML Profile for CORBA (formal/02-04-01) and the UML Profile for CORBA Component Model (formal/05-07-06). More clarification is needed about relationships between mentioned above two specs and this current final adopted spec. What are the differences between all profiles and migration rules from one to another? 

Resolution:
New chapter 8.7 “Differences and migrations between CORBA based Profiles”
has been added

More clarification text about order of CORBAStruct members is needed

The list of Normative References contains the CORBA Component Model Specification, Version 4.0 twice, but does not have a normative reference to the CORBA specification

Resolution: Delete the second reference and add the CORBA/IIOP reference.

The following constraints in 7.2.10 are incorrect: [1] A ConstantDef must be defined in a Container [2] A TypedefDef must be defined in a Container [6] An ExceptionDef must be defined in a Container [8] An InterfaceDef must be defined within a ModuleDef [9] A ValueDef must be defined within a ModuleDef Each of these can be defined as "global scope" (as is acknowledged in 7.2.3: "Modules can contain any definition that can appear at global scope (type, constant, exception, and interface definitions)" 

Resolution/Clarification:
According to the Chapter 10, Figure 10-2 of the CORBA/IIOP:
Repository or ComponentIR::Repository
ConstantDef
TypedefDef
ExceptionDef
[Ext]InterfaceDef
[Ext]ValueDef
ValueBoxDef
ModuleDef
…                                                                                                                                                                    Repository is an interface that provides global access to the Interface Repository,
it can contain constants, typedefs, exceptions, interfaces, value types, value
boxes, native types, and modules. Repository derives from Container (Chapter
10.5.6 of the CORBA/IIOP), therefore everything in the Repository is defined in a
Container. The constraints 1,2,6 are tautologies and needless. According to the
description of the Repository below the constraints 7, 8 and 9 are not correct:
InterfaceDef and ValueDef can be also defined as “global” and contained
immediately in the Repository object.
Changes: Chapter 7.2.10, page 10: Constraints 1, 2, 6, 7, 8 and 9 have been
deleted from the specification.

The last sentence of the bullet defining the Basic Stream type: "The data is consumed and produced by component implementation logic as octet sequences, unless the basic stream type". The last clause seems misplaced, and should probably be dropped

The replacement text, first bullet: "Array ... 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

Figure 8.12: A first attribute should have type A::B rather than B with clarification

Litteral of the enumeration PrimitiveKind are prefixed with "CORBA" or "Corba", instead of "CORBA" (upper case) for all litterals

P. 51 . The CORBAUses stereotype has a property "multiple" of type PrimitiveKind P. 53 . The CORBAUses stereotype has a property "isMultiple" of type boolean. This looks like a naming and type inconsistency between diagram and tabular representation of the stereotype. If this is the case and isMultiple is really typed boolean, PrimitiveKind becomes useless (I did not find any other use of PrimitiveKind in the profile). If not (I mean PrimitiveKind is the wanted type), it may be better to type the "multiple" property with the "CORBAPrimitive" stereotype instead of creating and using an enumeration like PrimitiveKind.

Chapter 9 should be clearly marked as non-normative. Noted during smsc review. Thus, formal document number not available