Issues for UML Profile for CORBA Finalization Task Force mailing list
To comment on any of these issues, send email to umlcorba-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 3728: The spec. doesn't say precisely which version of CORBA it is targeted to
Issue 3729: Namespace rules
Issue 3730: The UML 1.4 RTF may tighten the definition of a UML profile.
Issue 3731: Add long double to the coverage of CORBA primitive types.
Issue 3732: Name of the model element for CORBAUnions
Issue 3733: Change the VMM
Issue 8754: Section: 3.5.19 - 3.5.20
Issue 3728: The spec. doesn't say precisely which version of CORBA it is targeted to (umlcorba-ftf)
Click here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary:
Recommendation: Specify this (probably CORBA 2.4) and flag IDL features that
the submission covers but that haven't been made available yet. (Since
local has been placed in 2.4, attributes raising exceptions is the only
feature that falls into this category). The conformance language for
forward engineering tools should be correspondingly tightened.
Resolution:
Revised Text: Edits made to the Adopted Spec
Inserted Section A.1.1 "Versions" which states that: "All conformance points below require implementations to model CORBA IDL as specified in CORBA 2.4, using
UML models as specified in UML 1.3."
Added a Note to Section 3.5.15 (now 3.5.16) "Exceptions" stating that in CORBA 2.4 attributes may not raise exceptions. No further notes are necessary, as there is no
example or implication in the text that IDL attributes could raise exceptions.
Actions taken:
June 28, 2000: received issue
May 22, 2001: closed issue
Discussion: Proposed Resolution:
The Conformance Statement will explicitly state that IDL as specified by CORBA 2.4 will be the target of mappings from the Profile to IDL. A Note
will be inserted into the Attribute and Exception sections to state that Attributes may not raise exceptions.
Issue 3729: Namespace rules (umlcorba-ftf)
Click here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue: Namespace rules have been changed in the latest CORBA core
specification. Specifically, a parent and child can't have the same name.
This restriction holds only for children and does not hold for grandchildren
and more distant descendants.
Recommendation: Fix the formal constraints about namespace containment
specified in the submission.
Resolution: An English constraint and equivalent OCL expression will be inserted to reflect this IDL constraint.
Revised Text: Edits made to the Adopted Spec
Clarified Namespace containment of Classes and Features in Section 3.5.2 "CORBA User-defined Types" and added
Constraints for CORBAUserDefinedType (Core::Classifier) and CORBAModule (ModelManagment::Package)
[1] All model elements representing CORBA Namespaces may not directly contain another element of the same name.
self.ownedElements->forAll(ownedEl | not ownedEl.name = self.name)
Actions taken:
June 28, 2000: received issue
May 22, 2001: closed issue
Issue 3730: The UML 1.4 RTF may tighten the definition of a UML profile. (umlcorba-ftf)
Click here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary: Recommedation: If possible, synchronize the FTF report with the UML RTF
report.
Resolution: I have no way to resolve this issue, and I suggest we close this issue without further action.
Revised Text:
Actions taken:
June 28, 2000: received issue
May 22, 2001: closed issue
Issue 3731: Add long double to the coverage of CORBA primitive types. (umlcorba-ftf)
Click here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue: The submission's coverage of CORBA primitive types (section 6.5.1.1)
does not cover the long double primitive type.
Recommendation: Add long double to the coverage of CORBA primitive types.
Resolution: long double will be added to the set of primitives in the same style as long long.
Revised Text: Added long double to the list of Primitives in Section 3.5.1.1
Actions taken:
June 28, 2000: received issue
May 22, 2001: closed issue
Issue 3732: Name of the model element for CORBAUnions (umlcorba-ftf)
Click here for this issue's archive.
Source: Ivar Jacobson International AB (Mr. Ed Seidewitz, eseidewitz(at)ivarjacobson.com)
Nature: Uncategorized Issue
Severity:
Summary: The name of the model element for CORBAUnions may conflict with
legitimate member names of the union.
Recommendation: Instead of specifying a naming convention for the model
element representing a switch, define a stereotype for a switch and use this
stereotype to denote that a model element represents a switch. There will
need to be one stereotype that extends AssociationEnd and one that extends
Attribute, because the model element representing a switch is an
AssociationEnd if the switch's type is non-primitive, and is an Attribute if
the switch's type is primitive.
Resolution: resolved
Revised Text: Edits made to the Adopted Spec
Added VMM stereotypes "switch" and "switchEnd" to figure 3-9.
Changed the following text in 3.5.14 (now 3.5.15) "Discriminated Union"
Elminate "_switch" naming convention. Replaced this text with "which is stereotyped as a <<switch>> or <<switchEnd>> respectively."
Changed Constraint [1] for Unions to reflect this: " ...must be stereotyped as <<switch>> (in the case of an Attribute) or <<switchEnd>> (in the case of
AssociationEnd).
self.allAttributes->select(attrib | attrib.type.isStereotyped("switch") )->size = 1 xor
self.navigableOppositeEnds->select(end | end.type.isStereotyped("swutchEnd") )->size = 1"
Changed Constraints [2] and [3] by replacing "attrib.name = self.switchName" by "attrib.type.isStereotyped("switch")" and "end.name = self.switchName" by
"end.type.isStereotyped("switchEnd")" to select the correct model elements.
Deleted the OCL convenience operation for determining the switch name.
Updated example in Fig 3-24.
Actions taken:
June 28, 2000: received issue
May 22, 2001: closed issue
Discussion: The text about the "_switch" naming convention will be removed, and two new stereotypes will be added to the specification with bases:
AssociationEnd, and Attribute which denote the switch member of the CORBAUnion class. The VMM will be updated to show these, and a constraint
added to state that only one may be present for any given instance of a union definition.
Issue 3733: Change the VMM (umlcorba-ftf)
Click here for this issue's archive.
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity:
Summary: Issue: The VMM elements derived from CORBAWrapper need not be stereotypes of
Class; Classifier would suffice. Cleaning this up would require a small
rearrangement of the VMM. This only affects abstract stereotypes, so it
doesn't change how one actually models.
Recommendation: Change the VMM accordingly.
Resolution: resolved
Revised Text: Edits made to the Adopted Spec
Modified VMM diagrams as specified above. In addition made the following text changes:
Note: The Issue and Resolution above understate the case: The use of Class as the baseElement of CORBAWrapper is incorrect, as wrappers sometimes apply
to Classes, and sometimes to Datatypes (the CORBA Primitives). In order to fix this the parent of both these UML metaclasses, Classifier, is used instead. This
requires some changes to be stated in terms of Classifier, and some in terms of giving both possible concrete types: Class and Datatype. Also, the
specialization of CORBAException from CORBAStruct was incorrect, as UML Excpeptions do not derive from Class, even though both CORBAStruct and
CORBAException derive from Classifier. Hence the introduction of the Abstract stereotype CORBAStructType that defines constraints on Classifier.
In Section 3.5.2 "CORBA User Defined Type": changed many uses of "Class" to "Classifier".
In Section 3.5.8 "CORBA Wrapper Types": changed many uses of "Class" to "Classifier".
In Section 3.5.9 "TypeDef": changed many uses of "Class" to "Classifier". Changed "Class" to "Class or DataType" in "UML Standard Elements" and "Stereotypes and
Tagged Values" and "Notation" subsections.
In Section 3.5.12 "Constructed Types", changed the text saying that Constructed types are Classes to:
"Each of the IDL constructed types is represented by a stereotype of UML Classifier or one of its derived metaclasses. Specifically UML Exception is
derived from Classifier, and is used to model CORBA exceptions, while UML Class is derived from Classifier and is used to model ther other Constructed
types."
Inserted a new section ahead of "Struct": Section 3.5.13 "CORBAStructType". It's text is a copy of the Constraints of "Struct", and the "Stereotypes and
TaggedValues" section has been replaced by:
The virtual metamodel contains an abstract stereotype <<CORBAConstructedType>> which is a generalization of <<CORBAStruct>>,
<<CORBAUnion>> and <<CORBAException>>. The following constraints apply to all stereotypes derived from <<CORBAConstructedType>>.
The Notation subsection of 3.5.13 says: "See the concrete stereotypes CORBAStruct and CORBAException."
Throughout 3.5.13: Changed several occurances of Class to Classifier in the Constraints. Also changed CORBAStruct to CORBAStructType.
Removed the constraints in the Constraints subsection of 3.5.14 "Struct", as these are now in CORBAStruct. Changed the text to say "The constraints from
<<CORBAStructType>> apply to all <<CORBAStruct>>-stereotyped Classes. "
Changed text in Section 3.5.17 to alter references to "CORBAStruct" to "CORBAStructType". Also changed "Class" to "Classifier" in the Constraints where it
previously refered to the baseElement of CORBAStruct, and changed "Class" to "Exception" where it refers to the baseElement of CORBAException.
Changed 3.5.18 "Indexed Types" to reflect the change to CORBAStructuredType being a set of constraints on Classifiers, while constraints on all CORBAIndexedType
are on Classes.
Actions taken:
June 28, 2000: received issue
May 22, 2001: closed issue
Discussion: Proposed Resolution:
Change the base element for CORBAUserDefinedType shown in Figure 6-2 from Class to Classifier. Change the structure of the VMM shown in
Figure 6-4 to add a new (abstract) descendant of CORBAConstructuedType called CORBAStructType with all the constraints currently on CORBA
Struct. Change CORBAStruct and CORBAException to directly specialize CORBAStructType. Show on Figure 6-4 that CORBAStruct, CORBAUnion
and CORBAEnum have Class as their base element, while CORBAException has Exception as its base. Show on Figure 6-6 that CORBAIndexedType
has Class as its base element. (Note that CORBAObjectType on Figure 6-4 picks up the restriction to Class from its specialization of the type
stereotype.) Update all textual descriptions to be consistent with this.
Issue 8754: Section: 3.5.19 - 3.5.20 (umlcorba-ftf)
Click here for this issue's archive.
Nature: Clarification
Severity: Significant
Summary: in UML Profile for CORBA, where it describes the UML notation examples for mapping of CORBA sequences/arrays...there is some significant confusion on my part with respect to the notation examples given. See Figure 3-27 for an example. In this figure the class stereotyped as <<CORBAAnonymousSequence>> has a composition association with a class stereotyped as <<CORBAPrimitive>>. The latter class has the following text appearing in the name compartment: "CORBA::short". I am bewildered at how the type can be represented in the name compartment of the class. I am trying to use a tool to auto-generate IDL from UML, and have no way to represent this, and I am unsure if this is even valid as per the UML specification. Is this legal, or is necessary to have an attribute that is of type CORBA::short in the attribute compartment?
Resolution:
Revised Text:
Actions taken:
May 2, 2005: received issue