GE All the heading should be numbered as subclauses or itemized as lists.

Follow Directives part2 5.2.

There are a large number of Bold headings in the document, which are not numbered. Many OMG specs do this, and it was used in ISO/IEC 19501. Changing the spec at this time to give each one of these Bold headers their own subsection number. e.g., sec 7.3.3 has sub headings "Generalization" , "Description" etc., is too large too large an undertaking to incorporate into version 2.3 of UML.
Revised Text:

Disposition: Closed, No Change

The SoaML submission team understands the concerns about making UML extensions at all, let alone introducing changes too high up in the hierarchy that might introduce additional unintended inheritance issues. But we are also reluctant to submit to the UPMS RFP without addressing the need to distinguish services from requests, and without addressing the usability issues that result from the need to create separate types for both ends of a connector.

Recall that the problem is that ports appear on two ends of a connector. It is very often the case that consumers and providers can agree on the provided and required interfaces, and the interaction characteristics (protocol) and should therefore be able to use the same type to highlight that agreement. This is not possible with UML2. Ports don't have direction to indicate whether the owning component is using the operations or providing them. So users are forced to create "conjugate" types that flip the usage and realization relationships between classes and interfaces. This is especially troubling for the common simple case where the port is typed by a simple Interface.

There have been a number of suggestions about how to solve this problem, many involving how ports define provided and required interfaces, and whether they need a type at all. We wanted to solve this problem without making a lot of changes to UML that may have other unintended consequences, or not sufficiently address the issues. So our updated proposal is very simple, and hopefully not something that would in any way effect future changes to UML2.

We suggest the addition of a new Enumeration called PortDirection which has literals incoming and outgoing. Then add a new ownedAttribute to Port called direction: PortDirection = incoming. This would provide a direction on port that would be used to change how the provided and required interfaces are calculated. If direction=incoming, then the provided interfaces are those realized by the port's type and the required interfaces are those used by its type. If the direction is outgoing, the calculations are reversed: the provided interfaces are those used by the port's type, and the required interfaces are those realized by the port's type. Therefore, provided and required interfaces are calculated from the point of view of the owner of the port based on whether they are using the capabilities defined by the port's type, or providing them.

This does not provide similar capabilities for things like connected collaborationRole Properties in a Collaboration. These properties are of course not Ports, and there is no specific specialization of Property (i.e., Role) that distinguishes the usage of a property in a collaboration that could specify the direction from other usages of property where direction is not relevant. We will miss that capability, but don't want to expand the scope of the UML change to address it at this time. Rather we'll wait and see if the UML2 RTF comes up with a more general solution that is also consistent with port direction.

Is this acceptable?

This is a verbatim duplicate of 13080 which I will address soon.

Revised Text:
None.

Disposition: Duplicate.

The UML 2.1 spec, 06-04-02, has lost the proper content for Figure 13.8, by duplicating the content of Figure 13.7 again and labeling it 13.8. See pages 442 and 443 as paginated in the pdf, 462 and 463 as paginated by Adobe in onscreen display.

above from the 06-04-02 spec, below from the 05-07-04 spec

Discussion: Fixed in an earlier release; also duplicate of10469 Revised Text: N/A Disposition: Closed, no change

It is unclear what exactly is a path in the context of history pseudo states. For example: "Entry actions of states entered on the path to the state represented by a shallow history are performed." Is it the shortest path? The history path? What happens if the history state isn't the first state after the initial state, but located somewhere in the middle of the statemachine?

The word 'Path' has raised ambiguity with respect to how the history state will restore the active state configuration. There is only one way that the history will restore the active state, and that is through an implicit direct path from the history state to the last active state being reactivated (as though a transition is drawn directly from H to the last active substate). It in no way implies a state-by-state approach. (e.g. a path from the initial state to the last active state)

My question regards the following: Syntax for the Message name is the following: <messageident> ::= ([<attribute> ‘=’] <signal-or-operation-name> [‘(‘ [<argument> [‘,’<argument>]* ‘)’] [‘:’ <return-value>]) | ‘*’ <argument> ::= (<[parameter-name> ‘=’] <argument-value>) | (<attribute> ‘=’ <out-parameter-name> [‘:’ <argument-value>] | ‘ -’ First, I see a typo in the argument definition where the beginning of the definition should read as follows (Note the first square bracket and less than symbol): <argument> ::= ([<parameter-name> ‘=’] Second, I would like clarification on this item. From the definition it seems that I cannot specify a message by just showning the parameters. For example, if I have a class that has an operation of setFoo(int value): void, I cannot have a message of the method and its parameters, for example, "setFoo(value)". It would look like this instead "setFoo(value=)" according to the definition in the specification. To me this just doesn't seem right to have this hanging equal sign. There are other examples, pages 458 and 491 for example, that show a parameter without the equals sign. Could someone clarify this for me?

Discussion:
This issue seems to have been fixed already.
Disposition: ClosedNoChange

Activity::node, Activity::edge, and Activity::group do not subset Namespace::ownedMember, but they should

No Data Available

InterfaceRealization is a subclass of Realization that inherits the attribute Realization::realizingClassifier (defined in the Components package). This attribute has a multiplicity of 1, which means that InterfaceRealization must have a "realizingClassifier", even though this attribute only makes sense when the target is a Component and not an Interface. This is complicated further by the fact that InterfaceRealization has its own association end that serves a similar purpose called "implementingClassifier". But, this only makes sense for the case when the target of the realization is an Interface and not a Component.

InterfaceRealization should not be forced to have a "realizingClassifier" attribute. The best way to fix this may be to define a separate subclass of Realization for the case of Components (e.g., ComponentRealization) such that the two cases are kept apart. Alternatively, the multiplicity on Realization::realizingClassifier could be set to 0..1.

This has already been resolved in 2.2.

Revised Text:
None.

Disposition: Closed, no change.

Notation of a component realization is described as the same as the realization dependency, i.e. dashed line with open arrow-head. But the realization dependency has a triangular arrow-head. Please note that all component example figures use the open arrow-head. I would prefer the triangular arrow-head.

This is a duplicate of part of 10651.

Revised Text:
None.

Disposition: Duplicate.

LiteralReal has no default value. It would make sense if it had a value of 0 as for LiteralInteger.

withdrawn by submitter

In a programming language such as C# it is common, in libraries, to create parameterized types such as List<T>, which can be instantiated as List<Foo>, List<int>, List<Boolean> and so on.

UML templates do not permit the equivalent. The parameters of a template are all instantiated objects of a known concrete metaclass. It is therefore invalid for parameter-kind (17.5.4) to be an abstract metaclass, such as Type. This is a very severe limitation when trying to map UML to C#.

withdrawn by submitter, duplicate of 13257

In the Semantics of the AddVariableValueAction there is a line stating: "If isReplaceAll is false and the variable is unordered and non-unique, then adding an existing value has no effect." I find this statement in correct and in conflict with the semantics defined in multiplicity element. multiplicityElement.ordered -> Specifies whether the values are inserted in a certain position which can be identified by an Integer. This has no influence whatsoever on WHAT values can be added to a variable. multiplicityElement.unique -> An instance (of any type) cannot appear more than once in the collection of values. addVariableValueAction.isReplaceAll -> Specifies if all the previous values are removed before inserting the new ones. This does have influence on WHAT values can be added to a variable. Therefore if the addVariableValueAction is true then the input collection only needs to be evaluated. Else the input collection and the existing values need to be cheked. If the variable IS unique then it must be ensured that the add operation does not put the same instance more than once in the variable. This means that input collection will be merged with the existing values collection (empty collection if isReplaceAll==true) and then the repeated isntances will be removed. If the variable IS NOT unique then there is no need to check anything. Having repeated values in an unordered collection might have sense, for example to execute an algorithm to retrieve the number of times a user has logged in.

duplicate of issue # 8972

Under Compliance Levels, the first paragraph following the level descriptions is confusing, since it references the terms "top-tier" and "second-tier" packages without ever defining what those means.
For me, this entire paragraph is meaningless as a result.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

The MOF 2.0 Specification section 12.4 states that "Names are required for all Types and Properties". We should ensure that all Properties in the UML xmi files have names, preferably the same as the ones that were already there in UML 2.1.1 (this is a regression). An example is:

" Classes-Interfaces-A_interface_ownedAttribute-_ownedEnd.0" in Superstructure.xmi (2.3) and " Classes-Interfaces-A_interface_ownedAttribute-_ownedEnd.0" in Superstructure.cmof (2.2) have no names. But " Classes-Interfaces-A_interface_ownedAttribute-interface" in Superstructure.cmof (2.1.1) has names.

The UML 2.1.1 XMI files are fully compliant with the quoted constraint that "Names are required for all Types and Properties". The UML 2.3 XMI files; however, no longer have names for several association end properties (298 in the in Superstructure.xmi; 55 in the Infrastructure.xmi). Most of these association end properties are in fact owned ends of their respective associations. These ownedEnds are MOF Properties that had names in UML 2.1.1. We consider this to be a regression, and we are to repair all such ownedEnds by restauring their name according to the naming convention specified in clause 6.4.2 that was used to name the corresponding association.
In addition, we will ensure that there are no other Types or Properties that have no name. In Superstructure.xmi (2.3), there are 5 Associations which also must be given names. This is an XMI-only change.
The OCL query used to find associations with unnamed association ends using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following:
let As : Collection(Association) = self.allOwnedElements()
->select(oclIsKindOf(Association)).oclAsType(Association) in
As->select(a|a.member->exists(name->isEmpty()))
->sortedBy(qualifiedName).qualifiedName
The OCL query used to report unnamed associations using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following:
let As : Collection(Association) = self.allOwnedElements()
->select(oclIsKindOf(Association)).oclAsType(Association) in
As->select(a|a.name->isEmpty())->collect(a|Tuple

)

The OCL query used to verify that all occurrences of unnamed association ends are in fact owned ends of their associations using RSA 7.5.3 & the RSA-proprietary *.emx representation of the infrastructure & superstructure metamodels is the following:
let As : Collection(Association) = self.allOwnedElements()->select(oclIsKindOf(Association)).oclAsType(Association) in
As->select(a|a.member->exists(name->isEmpty()))
>forAll(a|a.member>one(m|m.name->isEmpty() and
m.oclAsType(Property).association->notEmpty()))

Description:

Notation of ObjectFlow "selection" and "transformation" as a note symbole does not specifiy the content of the note relatively to these behaviors.

In exemples figures 12.75 and 12.112 this note contains OCL constraints or free text.

It could be usefull to specify what needs to be displayed. For exemple :

• if the selection/transformation is an OpaqueBehavior then the body of the OpaqueBehavior is dislayed in the note
• if the selection/transformation is another Behavior then the name of the Behavior is displayed in the note

Note that same problem occurs for ObjectNode selection

This issue is obsolete. The UML 2.5 specification, in subclause 15.2.4, at the end of the paragraph describing the
selection and transformation Behavior notation, has the sentence: “The body of the note symbol may either contain
a textual representation of the Behavior (e.g., the body of an OpaqueBehavior) or the name of a Behavior that is not
represented textually.”
Disposition: Closed - No Change

The text of the description is contradictory. The first sentence says:

“AcceptCallAction is an accept event action representing the receipt of a synchronous call request. ....”

In the second paragraph it says:

This action is for synchronous calls. If it is used to handle an asynchronous call, execution of the subsequent reply action will complete immediately with no effects.

Although the description states twice that it is for the receipt of synchronous calls it then goes on to describe its use for asynchronous calls.

Accept call actions are intended to receive synchronous calls, however they will, indeed, also accept asynchronous calls, but, as already noted in the spec, no reply will be sent in such cases. The description could be better worded to make this clear without sounding contradictory.

What state is UML 2.3 in with respect to filing issues?

In particular, there is a duplicate association name in the Superstructure Library normative XMI file for UML 2.3 that was detected by my CMOF Import:

Duplicate association in package: Logical View::UML::AuxiliaryConstructs::Templates: A_templateParameter_parameteredElement.
Duplicate association in package: Logical View::UML::AuxiliaryConstructs::Templates: A_templateParameter_parameteredElement.

I checked the XMI file and, yes, the association is duplicated

This issue is covered by the resolution to 13330

Revised Text:

Disposition: Duplicate of 13330

Part I, II, III GE This is a multipart standard, use of "Part I, II, III" make confusion. Delete Part III and Make others rewrite as clauses. 7. General Introduction, 10 Infrastructure Library, and renumber other clauses. Also, delete Part III page.

Agree to change word "Part" to "Sub Part" throughout document.

Annex E GE Acknowledgements are not normative specification.

Leave them as OMG only document. Remove Annex E from ISO standard.

Acknowledgements are now in Section 6.3. However agree should be removed from ISO spec.

GE The following standard must be refer.

• XMI ISO/IEC19503
• MOF ISO/IEC19502 ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
  ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)

Issue 14280 proposal adds the proper references for UML 2. The older versions of MOF/XMI and OCL are not compatible with UML 2.

GE The format of normative references doesn't meet ISO format.

Write reference like as follow if you refer OMG's documents
IEC Std Template, IEC, available at <http://www.iec.ch/tiss/templates.htm>

add references with full text.

Part I, II, III,, IV GE This is a multipart standard, use of "Part I, II, III, IV" make confusion. Delete unnecessary Part IV and Make others rewrite as clauses. 7. Structure, 12 Behavior, 19 Supplement and renumber other clauses.

Agree to change word "Part" to "Sub Part" throughout document.

Annex K GE Acknowledgements are not normative specification. . Leave them as only OMG document but not ISO standard. Remove Annex K.

Acknowledgements are now in Section 6.5. Needs to be removed from ISO spec. remove section 6.5 from ISO spec and OMG spec for consistency.

Annex D GE This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as OMG only document.

Remove Annex D from ISO standard.

Resolution:
Agree, this annex is no longer in UML 2.3.
Revised Text:

Disposition: Closed, No Change

Annex C TH This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition.

Remove Annex C or make it informative Annex.

Agreed, but Annex C is no longer in UML 2.3
Revised Text:

Disposition: Closed, No Change

GE ISO standard documents are described with "shall", "should" and "may".

Define this standard with "shall", "should" and "may".

specification uses RFC 2119 Terminology

4,5 GE There is no terms ,definitions and symbols.

Remove the clause "4 Terms and definitions" and "5 Symbols".

Resolution:
Leave section 4 for future revisions to add terms and definitions.
Issue 14279 replaces section 5 with a new Notational Conventions section. see Issue 14279 (JP 2) resolution.
Revised Text:

Disposition: Duplicate of 14279

Japan will approve this DIS if the TH comment will accept.

Revised Text:
See resolution to OMG Issues 14283

Disposition: Duplicate of 14283

Notation for navigable ends owned by an association. Figure 21 should include a notation for navigable ends owned by the association

This was effectively resolved by the introduction of the "dot" notation in UML 2.1 for ends owned by end types.
Revised Text:
None.
Disposition: Closed No Change

In Superstructure.xmi (2.3):

Classes-Interfaces-Interface-ownedAttribute has a one-directional association to Classes-Kernel-Property and subsets Classes-Kernel-Namespace-ownedMember. Adding an instance of a merged Property to Interface-ownedAttribute would fail to populate the ‘owner’ or ‘namespace’ attributes of the Property (because the only slots are ‘class’ and ‘datatype’).

This is inconsistent in 2 ways:

1) The merged Property has the slots ‘class’ and ‘datatype’, but there is no slot for ‘interface’.

2) Compare this to a merged Operation, which has ‘class’, ‘datatype’ as well as ‘interface’ (from Classes-Interfaces-Operation-interface). Also, Classes-Interfaces-Interface-ownedOperation has a bidirectional association with Classes-Interfaces-Operation-interface, which also feels at odds with Classes-Interfaces-Interface-ownedAttribute.

3) Since Classes-Interfaces-Interface-ownedAttribute explicitly subsets ‘Classes-Kernel-Namespace-ownedMember’, we would expect that the association to ‘Classes-Kernel-NamedElement-namespace’ should produce a result. However since ‘namespace’ is a derived-union with no slots that accept an ‘Interface’, this remains empty (and consequently so does ‘owner’ even though the Property IS being owned by an Interface).

I would like to suggest the following:

1) Add a cmof:Class ‘Classes-Interfaces-Property’ to the package ‘Classes-Interfaces’ as an ‘ownedMember’ and change the ‘type’ of ‘Classes-Interfaces-Interface-ownedAttribute’ to ‘Classes-Interfaces-Property’.

2) Add a cmof:Property ‘Classes-Interfaces-Property-interface’ as an ‘ownedAttribute’ of ‘Classes-Interfaces-Property’. This attribute should be 0..1 with the type ‘Classes-Interfaces-Interface’ and should subset ‘Classes-Kernel-RedefinableElement’, ‘Classes-Kernel-Feature-featuringClassifier’ and ‘Classes-Kernel-NamedElement-namespace’. Its’ association should be ‘Classes-Interfaces-A_interface_ownedAttribute’.

3) Modify ‘Classes-Interfaces-A_interface_ownedAttribute’ to have the member ends be ‘Classes-Interfaces-Property-interface’ and ‘Classes-Interfaces-Interface-ownedAttribute’.

This inconsistency issue is substantiated as explained; the suggestion amounts to repairing Classes::Interfaces as a package merge extension of Classes::Kernel. In fact, the "copy-down" suggested in item (2) is implicitly shown in the fact that 'Property' like all of the other metaclasses defined in the Classes::Interfaces package are unqualified whereas the other metaclasses defined but not copied in this package are fully qualified.

The body of the ‘Core-Constructs-Operation-isConsistentWith’ Operation in Infrastructure.xmi uses an attribute called ‘formalParameter’, which does not exist in the metamodel:

result = (redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.formalParameter.size() = op.formalParameter.size() and self.returnResult.size() = op.returnResult.size() and forAll(i | op.formalParameter[i].type.conformsTo(self.formalParameter[i].type)) and forAll(i | op.returnResult[i].type.conformsTo(self.returnResult[i].type))

We should instead borrow the body from Superstructure.xmi which does not have that problem:

result = (redefinee.oclIsKindOf(Operation) and let op: Operation = redefinee.oclAsType(Operation) in self.ownedParameter.size() = op.ownedParameter.size() and forAll(i | op.ownedParameter[i].type.conformsTo(self.ownedParameter[i].type))

Resolve discrepancies for RedefinableElement amongst the following artifacts:

• Infrastructure document (clause 11.4.4)
• Superstructure document (clause 7.3.46)
• Infrastructure XMI: Core::Constructs::RedefinableElement
• Superstructure XMI: Classes::Kernel::RedefinableElement
  Resolve discrepancies for Operation::isConsistentWith amongst the following artifacts:
• Infrastructure document (clauses 11.3.4 & 11.8.2)
• Superstructure document (clause 7.3.36)
• Infrastructure XMI: Core::Constructs::Operation
• Superstructure XMI: Classes::Kernel::Operation

JP4 3 GE The following standard must be refer.

• XMI ISO/IEC19503
• MOF ISO/IEC19502
• OCL 2.0 ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
  ISO/IEC 19503:2005 Information technology – XML Metadata Interchange (XMI)
  OCL 2, OMG, available at
  <http://www.omg.org/spec/OCL/2.0/PDF>

Issue 14260 proposal adds the proper references for UML 2. The older versions of MOF/XMI and OCL are not compatible with UML 2.

The format of normative references doesn't meet ISO format.

Write reference like as follow if you refer OMG's documents
IEC Std Template, IEC, available at <http://www.iec.ch/tiss/templates.htm>

add references with full text.

On C.1 StandardProfileL2 the stereotype «create» is on language unit Dependencies, and «responsability» is on language unit Classes::Kernel. I think both belong to language unit Classes::Dependencies

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Specification: UML Superstructure v2.2 (formal/09-02-02)

In the superstructure specification, when a class is intended primarily as an increment to be merged with some other “base” class, this is usually documented by listing the “base” class under the Generalization section, with the annotation “(merge increment)”. While such documentation of merge intent is extremely useful for the understanding of the reader, putting this documentation under the “Generalization” section is confusing, since the way package merge is now used in the superstructure abstract syntax model has nothing to do with generalization. Further, this documentation convention is not always consistently applied, especially when the class also has “real” generalizations.

So, the specification should retain documentation for merge increments, but the overall approach for doing this should be revised and clarified, and then this approach should be applied consistently across the specification.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

ISO standard documents are described with "shall", "should" and "may".

Define this standard with "shall", "should" and "may".

specification uses RFC 2119 Terminology

Japan will approve this DIS if the TH comments will accept.

The TH comments (OMG Issues 14271 - JP14, 14274 - JP17) were accepted in the approved resolutions for UML 2.3. See resolutions to OMG Issues 14271 and 14274
Revised Text:

Disposition: Duplicate of 14271 and 14274

There are many errors in the example XMI serialization for the profile and the profile application and the xsd in section 18.3.6:

The UML namespaces (in the definitions and the hrefs) refer to version 2.0 (and in some places inconsistently to 2.1) and should be correct for the current version

The profile definition is missing a definition of a namespace and prefix for xmi

The ownedMember tag should be packagedElement to be consistent with how superstructure is serialized.

The isComposite, lower and upper tags are not valid in a superstructure serialization (and upper is not valid in an infrastructure serialization).

The examples are corrected to follow the rules. We remove the schema example altogether because it presupposes that we are publishing an XML Schema for UML, and we are not doing so. The text just preceding the schema example is incomprehensible and unnecessary so is deleted.

shouldn't the OCL statement for the Utility [1] return a collection: collect(dependency|dependency.supplier)

instead of

collect(dependency|dependency.client) ?

and in the OCL statement for the Utility [2] shouldn't it be (classifier.clientDependency->...)

instead of

(classifier.supplierDependency->...) ?

Please clarify.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In several places of §7.3.44 one speaks about the value(s) of a property. However, there is no property on the Property meta-class that map to this value, except the defaultValue property. On the other hand, it is stated that "If a property is derived, then its value or values can be computed from other information " but nothing make mandatory the specification of how this value is computed.

"isDerived", "defaultValue" and the missing "valueSpecification" property of the Property meta-class cannot be totaly independent.

Suggested resolution :

• Add an optional valueSpecification property to the Property meta-class with the type ValueSpecification

• Change defaultValue to be derived according to the following constraint: {OCL}

  defaultValue = if self.isDerived then self.valueSpecification else NULL endif

There is some confusion in the issue. In the UML 2.5 text it is made clear that the phrase “value of a property”
describes the state of instances of the classifier. The property has no value except in the context of an instance.
Disposition: Closed - No Change

In UML 2.3 and earlier, Interface-redefinedInterface subsets RedefinableElement-redefinedElement. However, since Interface specializes Classifier, the property should subset Classifier-redefinedClassifier instead, which will in turn subset RedefinableElement-redefinedElement

It is legal for Interface::redefinedInterface to have a subset relation with Classifier::redefinedClassifier, even if the latter is not a derived union. Such a relation simply means that, even though there are two distinct associations, any redefinedInterface must also be a redefinedClassifier – but that there may be redefinedClassifiers (of an interface) that are not redefinedInterfaces.
Of course, if it is desired that an interface only be able to redefine another interface, then the simplest thing to do would be to just add a constraint to Interface that all redefinedClassifiers must be interfaces. Actually, the proper way to do this is to redefined the OCL operation RedefinableElement::isConsistentWith.
On the other hand, if we make redefinedClassifier a derived union, then we also need to add non-derived subsetting associations to all the subclasses of Classifier, not just Interface. And this would result in a definite semantics change. For example, right now a class can, seemingly, realize any classifier.
RedefinableElement::isConsistentWith is false by default, and needs to be “must be overridden for subclasses of RedefinableElement to define the consistency conditions”. Class and Interface would therefore need to override isConsistentWith in order to define the meaning of redefinition of specific kinds of classifiers. Redefinition of classifiers was introduced in order to allow behaviors, which are Classifiers, to redefine other behaviors.
This is possibly a bigger problem. The model for redefinable elements sets up a relatively simple but quite flexible mechanism for establishing the consistency of the redefinition of various kinds of elements. But this simply has not been used properly in the specification of most kinds of redefinable elements. However, section 7.3.24 does have a simpler error, redefinedInterface cannot subset Element::redefinedElement since it doesn?t exist. See figure 7.9 and figure 7.16. Rather than address the meaning of interface redefinition in this resolution, the error should be corrected so that at least the redefineInterface contributes to a valid subset as suggested in the issue.

under Attributes -
visibility: VisibilityKind [1]
Default value is false.

'false' is not a member of VisibilityKind. I assume 'private' is intended, though I notice some tools have gone for 'public'.

No Data Available

The standard specifies the guard of an activity edge like this:

guard : ValueSpecification [1..1] = true

Hence it is required that every activity edge has a guard. This should be changed to [0..1] to make the guard optional.
The standard should also say that if a guard is not present it means the same as a "true" guard.

Note that the guard of a state machine transition is optional, so this change will make things more consistent

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In Core::Abstractions::Super::Classifier::hasVisibilityOf there is
Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
pre: self.allParents()>collect(c | c.member)>includes
if (self.inheritedMember->includes ) then
hasVisibilityOf = (n.visibility <> #private)
else
hasVisibilityOf = true

This is wrong because “NamedElement” doesn’t have “visibility” attribute. In fact “Feature” doesn’t have “visibility” attribute as well, so all of the properties and operations for Classifier needs to be public. That’s why I think that for now “hasVisiblityOf” should be fixed to:
Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
pre: self.allParents()>collect(c | c.member)>includes
hasVisibilityOf = true

but maybe it should be considered to add visibility attribute to Feature.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

When you specify a property as an ordered derived union, with the implied derivation of union-ing the subsetting properties, how do you specify the order of the resulting union?

This problem actually occurs in the UML spec itself, in the definition of ExceptionHandler::output_pins
which relies on the ordering of Action::output, which is a derived union.
We can specify a determinate order for the common case where all of the subsetting properties are class
owned and there is single inheritance: which is the case for Action::output. In other cases, we can just say
that the order is undefined.

The term "Package Extension" on page 142 seems to be obsolet and possibly may be omitted

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In the first table of section C.2, the first row, <<buildComponents>>, in the column called "Description" the word development is misspelled in the phrase ”for the purpose of system level decelopment activities"

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

1)
In paragraph "7.3.8 Classifier (from Kernel, Dependencies, PowerTypes)" is constraint:
[4] self.inheritedMember->includesAll(self.inherit(self.parents()->collect(p | p.inheritableMembers(self)))

2)
inheritableMembers() is query with definition:
[4] Classifier::inheritableMembers(c: Classifier): Set(NamedElement);
pre: c.allParents()->includes(self)
inheritableMembers = member->select(m | c.hasVisibilityOf(m))

3)
hasVisibilityOf() is query with definition:
[5] Classifier::hasVisibilityOf(n: NamedElement) : Boolean;
pre: self.allParents()>collect(c | c.member)>includes
if (self.inheritedMember->includes) then
hasVisibilityOf = (n.visibility <> #private)
else
hasVisibilityOf = true

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

For NamedElement there is:

namespace: NamedElement [0..1]

when it should be

namespace: Namespace [0..1]

No Data Available

For Slot there is:

value : InstanceSpecification [*]

when it should be

value : ValueSpecification [*]

See issue 10005 for disposition

There is:

importMembers = self.excludeCollisions(imps)>select(imp | self.ownedMember>forAll(mem |
mem.imp.isDistinguishableFrom(mem, self)))

when it should be

importMembers = self.excludeCollisions(imps)>select(imp | self.ownedMember>forAll(mem |
imp.isDistinguishableFrom(mem, self)))

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Fig. 7.15 contains two misplaced

-clauses.

In the two associations between Dependency and NamedElement,

only makes sense for property supplier; the same holds for

and property client.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

GT Regarding Description, Notation and Semantics section, It is difficult to distinguish MetaClass name from general term, since there are several confusing occurrences which are shown in lower case letter. It seems those are inconsistent.

Clarify their usages through the entire specification.

Resolution:
Context is often required to distinguish use of names - sometimes the name means both the metaclass and the common meaning of the term. Ideally, the spec should have notational conventions for these and follow them, but this would be too large an undertaking to incorporate into version 2.3 of UML.
The Japanese National body provided the following clarification on this issue:
"Could you just confirm the capitalization?
We have to translate this standard to establish the Japanese Industrial Standard (JIS) after ISO standardization. In that case, unclear usage of the capitalization will make us confused."
In many cases the capitalization is an editorial matter. There is not enough time to make a detailed proposal for making capitalization more consistent in time for this RTF.
Should leave this issue of consistent capitalization open for discussion in future RTF for detailed proposals to be considered for resolution in the next UML version..
Revised Text:

Disposition: Deferred

JP5 4,5 GE There is no terms, definitions and symbols.

Remove the clause "4 Terms and definitions" and "5 Symbols".

Leave section 4 for future revisions to add terms and definitions. Issue 14259 replaces section 5 with a new Notational Conventions section. see Issue 14259 (JP 2) resolution.
Revised Text:

Disposition: Duplicate of 14259

Fig. 13.15, 13.17, 14.12, 14.16~31, …, 16.10 E The annotations with red characters and a red arrow which outside the framework are not parts of example. They are class names and/or their attributes. Also, the arrow symbol is same as UML notation. Thus, those annotations lead misunderstand.
*Add annotation convention to somewhere.

• Unify the arrow symbol, someone are white hatching, others are red hatching.

Suggest adding description of red annotations to section 5, Notational Conventions.

12.4, E There is no subheading representing a particular diagram.

Add subheading "Activity Diagram".

Since the section 12 is titled Activities, it serves as the context for sub-section 12.4
Revised Text:

Disposition: Closed, No Change

TL It is unclear whether the names of diagrams, e.g. Class Diagram, are within normative part or informative part of the standard.

State clearly whether the names of diagrams, e.g. Class Diagram, are within normative part or informative part of the standard.

RTF does not see why Japan thinks the names might be anything but normative - they are in Annex A clearly marked as Normative. Resolution to Issue 14265 (JP 8) results in all annexes being labeled as normative or informative.
Revised Text:

Disposition: Closed, No Change

Annex I TH This annex .defines OMG and related companies's copyright and patent condition. But ISO defines another copyright and patent condition. Remove Annex I or make it informative Annex.

agreed, Annex I is no longer in UML 2.3
Revised Text:

Disposition: Closed, No Change

Table 16.1 E Many people may misunderstand the annotations inside table 16.1 are notations of graphical nodes. Remove annotations inside table 16.1.

Resolution:
add explanation of annotations.
Revised Text:
See Issue 14272 revision, which adds explanation of graphical annotations.

Disposition: Duplicate of 14272

GE There are a lot of sentences which start with Metaclass name (in upper case letter) without preceding letter. In that case, It is difficult to distinguish Metaclass name from general term.

Clarify their usages through the entire specification. When sentence starts with metaclass name, put certain preceding letter, for example article, and make it distinguishable.

Context is often required to distinguish use of names - sometimes the name means both the metaclass and the common meaning of the term. Ideally, the spec should have notational conventions for these and follow them, but this would be too large an undertaking to incorporate into version 2.3 of UML. Leave Issue open for consideration in future Revisions.
Revised Text:

Disposition: Deferred

16.4 E There is no subheading representing a particular diagram.

Add subheading "Use Case Diagram".

Since the section 16 is titled "Use Cases", it serves as the context for sub-section 16.4
Revised Text:

Disposition: Closed, No Change

15.4 E There is no subheading representing a particular diagram.

Add subheading "State Machine Diagram"

Since the section 15 is titled "State Machines", it serves as the context for sub-section 15.4.
Revised Text:

Disposition: Closed, No Change

GT Distinction between normative and informative part is unclear.

Make distinction between normative and informative part.

Ensure that all annexes are labled as "normative" or "informative"
All statements in the body of the spec (unless explicitly stated as informative) are considered as normative. The formal semantics of use of term "may" from resolution to Issue 14259 (jp 2) clarifies its use as in normative statements.
Eg: In Section "Notation" in 7.3.3 Association" the sentence:
"Users may conceptualize the dot as showing that the model includes a property of the type represented by the classifier touched by the dot."
is a normative statement.

17.3.1 1st paragrap, Semantics section. (There are several "physical" in the section) TH According to the standard, "Model" is restricted to "physical system". However, It is required to apply to conceptual/logical system.

Remove "physical". Otherwise, add "conceptual/logical" before "system".

agreed to remove prefix "physical" before "system" in Section 17.3.1, para 1

Annex J GE This is ISO standard, thus it is unnecessary OMG's procedure. Leave them as only OMG document but not ISO standard.
Remove Annex J.

Resolution:
Agree, this annex is no longer in UML 2.3
Revised Text:
Annex J already removed in UML 2.3.

Disposition: Closed, No Change

Figure 18.15 does not reflect the example before. The property names "wrap" and "resolution" do not match. Moreover, a link is missing from :Extension to :Class which has the "metaclass" and "extension" as a role names

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

The XMI document contains "<ownedMember>" elements which should be "<packagedElement>" due to the change in the abstract syntax (see Fig. 18.2). Actually, Eclipse UML support correctly exports "<packagedElement>". The same holds for all other XMI documents.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

chapter 2.2, p.3 Last paragaph, second sentence: "Note that each of the four packages..." There are more than four packages.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In the "Associations" part of the "9.10.3 Slot" chapter/section the text : "• value : InstanceSpecification [*]" should be changed to : "• value : ValueSpecification [*]" according to the diagram provied at page 54.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In paragraph 4, the text should read "Class has a derived association ...". Currently, the sentence is missing "a".

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In paragraph 2, the package reference to InfrastructureLibrary::Constructs::Class omits intermediate package "Core".

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Third paragraph below Figure 18.8, second word: isStrict instead of isStric

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Subsets target and subsets source at the associations from Dependency to NamedElement are at the wrong side. They are property strings of the association ends supplier and client.

No Data Available

Figure 13.2 shows class InfrastructureLibrary::Profiles::Element. Section 13 doesn't define a class named Element. The "Generalizations" on p. 185 says it generalizes Core::Basic::Element. Is that correct? Other classes in Core::Profiles generalize a class from Core::Constructs

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Figure 13.2 shows an association between ProfileApplication and Profile that has role "appliedProfile". The text on p. 196 states that the role is "importedProfile". The respective statements of subsetting also do not correspond.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

p.4, fig 2.2. The package L0 is missing which should also be merged into L1.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In the Attributes section, "integer" should be capitalized

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Remove the $ character in 'extension$_' stereotypeName

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

(This is quite a nasty and significant issue that arose from discussions of issues raised on the UPDM profile. It may well be declared as Urgent.)

(start of issue)

The Profiles chapter claims in a few places (with an example in Figure 18.16) that it’s possible to have a single Stereotype extend many metaclasses. However this is contradicted by the description of Stereotype semantics defined by means of a MOF metamodel equivalent (in Figure 18.4) which shows a ‘base_Interface’ 1..1 composite ownership property on the Home Stereotype. Which makes intuitive sense since you cannot have a free-floating stereotype instance (unattached to any element). However in the case of a Stereotype extending 2 metaclasses this would result in it having 2 mandatory composite owners (e.g. for the example in Figure 18.16 base_Class and base_Component) – which is not permitted (you could never have a valid model since an instance can only ever have one composite owner) and would not make sense (it would require each instance of the Stereotype to be attached to 2 distinct model elements – each property is mandatory).

This 1..1 property is also reflected in the XMI serialization of a Profile (in 18.3.6) that makes the multiplicity of the base_Interface property 1..1 (by default). And in the Profile XSD where the xsd:element and xsd:attribute are again 1..1 (by default).

Note that this issue also arises when a Stereotype inherits from another Stereotype and they both extend different metaclasses. This situation could however be addressed in the restricted case that one metaclass is a specialization of the other and by declaring that one property redefined the other. For example assume we modify Figure 18.16 to have an additional Stereotype SuperClock which generalizes Clock and extends Class (instead of Clock directly extending Class). We could then define that Clock::base_Component

SuperClock::base_Class. This however only works because Component specializes Class. In the general case (for example if SuperClock extended Package) then redefinition would not be possible and SuperClock::base_package would have to be changed to be optional. This violates the general design principle that extending something should not change it.

D) Due to the complications with C), a further variant of B) is to make explicit the multiplicity of the base_X property, in the same way that it can be made explicit for

stereotypes. So SuperClock::basePackage may be explicitly declared to be 0..1. If defaulted to 1..1 then that prohibits it from being specialized – except by a stereotype which extends a subclass of Package and {redefines) SuperClock::basePackage with a [0..1] property. So that makes the use of [1..1] for base_X the equivalent of declaring in Java that the Stereotype is ‘final’ and cannot be extended.

To summarize the impact of these options on existing profiles:

A) Requires a change only for Stereotypes that extend more than one metaclass (directly or indirectly) and probably requires new Stereotypes to be created to cover the multiple metaclasses. In those cases it will have an impact on models applying those Steretypes (to migrate to the new Stereotype) but this is a transformation that can be easily automated.

B) Requires a change to the XMI serialization of all Stereotypes in all existing Profiles (though not models applying those profiles) and their XSD files

C) Requires a change only for Stereotypes that extend more than one metaclass (directly or indirectly) and requires a change to the XMI serialization of their profiles and XSD but for those stereotypes only and possibly their general stereotypes (which could be in another Profile: I think though the only case I’m aware of that does this is UPDM itself which has not yet been Finalized).

D) Has the same impact on existing profiles as C), but has the benefit of simpler and more predictable generation rules.

Option A) has the advantage of retaining the current simple 1..1 structural constraint which is amenable to MOF and XSD validation without the need for OCL support. The other options make it harder to validate that an instance of a stereotype is applied to exactly one instance of a UML metaclass.

(end of issue)

The FTF agreed that this is an issue that needs to be resolved. The solution is to provide another example in
the specification besides the single metaclass example given in Figure 12.15 for multiple metaclass extension
and its MOF equivalent class. Furthermore, informal constraints need to be added to the Stereotype’s
classifier description, stating that: The upper bound of a base property is always 1
• The multiplicity of the base property in single metaclass extension is always 1..1
• The multiplicity of all base properties in multiple metaclass extension is always 0..1, whereas only
one base property is allowed to contain a value at any point during runtime

According to 13.3.2 context is calculated as follows: “If the behavior is owned by a BehavioredClassifier, that classifier is the context; otherwise, the context is the first BehavioredClassifier reached by following the chain of owner relationships.” Also according to 13.3.2 ”When a behavior is instantiated as an object, it is its own context.” These two statements are contradictory.

The second quoted sentence is confusing, though the intended meaning is not contradictory with the calculation of the context classifier. The intent is that, when a Behavior without a context classifier is instantiated then, at runtime, the behavior instance acts as its own context object, even though it is not its own context classifier.

The use of "internal" transition is used incorrectly in many places where "local" should be used. The specification should be updated to correct this inconsistencies. For example, on page (575/748) of UML2.2, it states: "An entry pseudostate is used to join an external transition terminating on that entry point to an internal transition emanating from that entry point. An exit pseudostate is used to join an internal transition terminating on that exit point to an external transition emanating from that exit point" However, internal transitions are not meant to be used in this context and must be connected directly to a state. A 'local' transition is used to navigate to a subvertex which is more the use case being described here.

This misuse of the term “internal transition” was rectified in UML 2.5. An inspection of the text reveals no remaining
cases.
Disposition: Closed - No Change

In the infrastructure 6.2.1 it says

If no multiplicity is shown on an association end, it implies a multiplicity of exactly 1.

However, in

8.3.3 Associations

The opposite ends of associations connected to the class are also listed in the same way. The sub clause states if the association is derived, or if it is a specialization of another association. The multiplicity of an association end is suppressed if it is ‘*’ (default in UML).

It appears that the default is 1 and the default is also * which is confusing.

I believe it should be clarified something like this.

When an association is shown as an attribute/property, the default multiplcity is the same as the default attribute/property multiplictty (1)

When an assocation or attribute is shown as a association (that is, on the end of a line), the default multiplicity should be

The default multiplicity is always 1.
This text appears only in the section describing the structure and conventions used by the specification itself. Superstructure has the following similar text:
The “Attributes” sub clause of a concept description lists each of the attributes that are defined for that metaclass. Each attribute is specified by its formal name, its type, and multiplicity. If no multiplicity is listed, it defaults to 0..*.
Which is inconsistent with the Infrastructure text for Attributes:
The multiplicity of the attribute is suppressed it defaults to „1? (default in UML). In practice both documents are now explicit about all association multiplicities, and suppress only attribute multiplicities of [1].

text on page 144: "Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageExtension • PackageImport" Search in the document for "PackageExtension" produces a single result on this same page, which means that the term "PackageExtension" is no longer defined. Most likely, the text above should have "PackageMerge" instead, smth like: Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageMerge • PackageImport

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Specification: UML 2.1 Beta 1 (2008/05/01)

Section: 12.2 Activities (Abstract Syntax), Figure 12.18

Summary:

This figure shows Parameter::effect : ParameterEffectKind in a way that suggests that its multiplicity is [1..1] when in fact it is [0..1]. Also, the figure incorrectly shows an Eclipse ECore stereotype, <<eAttribute>>.

Proposed Resolution:

In Figure 12.18:

• Remove the <<eAttribute>> stereotype notation for the Parameter::effect attribute

• Show the multiplicity of the attribute explicitly, i.e.: effect : ParameterEffectKind [0..1]

This issue is obsolete. The attribute Parameter::effect is shown on Figure 9.9 in the UML 2.5 specification, and the
problems identified in the issue have already been resolved.
Disposition: Closed - No Change

Figure 12.95 - "Fork node example" shows "Fill Order" twice, while it should show - as explained right above - that when "Fill Order" is completed, "Ship Order" and "Send Invoice" get control.

See issue 10818 (resolved in UML 2.3) for disposition

Section 14.3. 18 says “An InteractionUse refers to an Interaction. The InteractionUse is a shorthand for copying the contents of the referred Interaction where the InteractionUse is.” What is the relationship of the Lifelines in the used interaction to those in the using interaction? Are they supposed to be the very same lifeline instances, or are they matched by name?

UML 2.5 added constraints on covered lifelines of interactionUse stating “Lifelines are common if they have
the same selector and represents associationEnd values.” It also clarified that selector values are constrained
to be LiteralString or LiteralInteger
However, it is necessary to fix some Bugs in the new lifeline and interactionUse constraints. Fix constraint
interaction_uses_share_lifeline of lifeline and all_lifelines of interactionUse to ensure coverage of Literal-
Integer Selector value. Also Fix selector_int_or_string constraint to properly cover both LiteralInteger and
LiteralString options for Selector value.
This resolution also incorporates the change from Issue 18465, which proposes changing
: “x.oclIsKindOf(T)->notEmpty()” To: “x.oclIsKindOf(T)’’

In the XMI, Ownerships::Element erroneously includes an association for ownedComment. Similarly, the XMI for this package includes an association A_ownedComment_owningElement. These more properly belong in the Comments package of Abstractions.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In the XMI, Ownerships::Element fails to include a superClass attribute for Elements::Element

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

The XMI for the various operations integerValue, booleanValue, stringValue and unlimitedValue fails to include a "lower" attribute, so the default of [1..1] is assumed.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

The UML XMI fails to include an ownedRule for the Constraint specified for an OpaqueExpression

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

"Table 7.3 - Graphic paths included in structure diagrams" on pp.143-144 includes PackageImport but does not include ElementImport, described in "7.3.15 ElementImport (from Kernel)". It is also missing on p.144 in: "Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageExtension • PackageImport" It should look smth like: "Package diagram The following nodes and edges are typically drawn in a package diagram: • Dependency • Package • PackageMerge • PackageImport • ElementImport

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

In the Statemachine diagram in section 15.3.12 diagram 15.42 (and the text above) it is specifying the use of 'final' to define that a redefinable element (state or transition in this case) can not be redefined. However, there is no other mention of this 'final' in the rest of the document (maybe its leftover from before?). RedefinableElement's have an isLeaf attribute which is used to determine this property. Therefore we should probably use

.

Merged with 12380

"Some of the resolutions that affected the superstructure doc in RTF 2.3 also have implications for Infrastructure. Please do the proper changes to Infrastrcture to keep the two documnets in sync"

This is confirmed. All the relevant changes are proposed below.

"Currently in the metamodel:

1- InternalStructures::StructuredClassifier specialize Kernel::Classifier and InternalStructures::StructuredClassifier::ownedAttribute subsets Kernel::Classifier::attribute

2- InternalStructures::Classifier and its "attribute" association are there but not referenced any where else.

A question: is the subsetting in 1 valid?

The answer appears at least to me as "No". The type of the InternalStructures::StructuredClassifier::ownedAttribute is InternalStructures::Property, and the type of Kernel::Classifier::attribute is Kernel::Property, and there is no generalization between the two types. That is probably why the Classifier merge increment was introduced in InternalStructures, to make "attribute" of compatible type to "ownedAttribute", but it was never reflected in the metamodel.

So to make things consistent, as Nic said, we should:

• Make InternalStructures::StructuredClassifier specialize InternalStructures::Classifier instead of Kernel::Classifier
• Make InternalStructures::StructuredClassifier::ownedAttribute subset InternalStructures::Classifier::attribute instead of Kernel::Classifier::attribute.

in addition:

• don't we need to change 9.3.2 to indicate that Classifier comes from both Collaboration and InternalStructures?
• Ironically, the "generalization" section in 9.3.2. says that Collaborations::Classifier specialize Kernel::Classifier (as seen in Figure 9.2 "Internal Structures"), where it is supposed to be as given in Figure 9.7 "Collaboration".
• So to document "Classifier" property in 9.3.2, there would be two generalization headings one "Package InternalStructure" and "Package Collaborations" with different content. "

For chapter 8, this resolution incorporates part of the resolution from the accepted resolution 7364, but modifies it in order to copy down the merged class and features required for the OCL constraint to parse in the context of the receiving package.
For chapter 9, it sorts out InternalStructures::Classifier, which was introduced according to this "copy down" principle, but is not documented properly. Also Collaborations::Classifier inherits more than is necessary, so to simplify the overall documentation of Classifier in chapter 9, we can make both InternalStructures::Classifier and Collaborations::Classifier just specialize Kernel::Namespace.

My inclination would be to remove StructuredActivities::InputPin, and have it only in CompleteStructuredActivities, with OutputPin in both StructuredActivities and CompleteStructuredActivities. The constraints, if they are in the model at all in their unformalized form, should only be on the InputPin and OutputPin classes in CompleteStructuredActivities. Then we can deal as a separate issue with the proper constraints for flows into and out of OutputPins and InputPins at L1 and L2."

Make InputPin only coming from CompleteStructuredActivities (and remove it from StructuredActivities in the metamodel).
Then, for OutputPin sections add "Package CompleteStructuredActivities" as a subheading for the constraint (and move it in the metamodel to the counterparts in that package).

The BNF of Constructs::Property defines <Visibility> ::= '+' | '-' clearly missing the package and protected visibilities. This Contradicts the Superstructure in 7.3.44, where the BNF states all four visibilites.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Specification: UML Superstructure, v2.2

Section: Annex C, Standard Profiles

It is not clear what the names actually are of the stereotypes in the standard profiles of UML. The stereotypes are listed in Annex C as they would be applied (using guillemet notation). However, Subclause 18.3.8 has the style guideline: “The first letter of an applied stereotype should not be capitalized.” Due to the above style guideline, this leaves it ambiguous as to whether the actual stereotype model element is named “metaclass” or “Metaclass”. This affects XMI serialization of an application of the stereotype, because the XML element for the stereotype should use the actual stereotype model element name.

Indeed, as a classifier, the normal practice would be for its name to be capitalized but it would then still be allowable to display this on the diagram using a lower case letter, as in «metaclass». Unfortunately, there is no normative XMI for the standard profiles, so there is currently no way to resolve this based on the normative standard.

The resolution is to provide normative XMI for the standard profiles, and to fix up the document accordingly. In order to do this properly we need to resolve 13306 by shipping a normative version of the UML metamodel expressed in UML. Having done this we can resolve 14092 by shipping standard profiles that refer to this normative UML metamodel.
We change the convention so that references to stereotypes are shown with upper case letters, and change all the examples accordingly, fixing errors as we go.
We permit lower case references but remark that they are stylistically obsolete.

In the SysML 1.2 RTF, we found a small bug in the normative UML 2.3 infrastructure.xmi here:
https://dev.enterprisecomponent.com:9992/repos/UML-RTF/trunk/Documents/Specification/Deliverables/UML2.3%20Normative%20XMI.zip

The bug is described at the bottom of the SysML 1.2 RTF wiki page where I described how I adapted Maged’s excellent instructions for generating the normative UML 2.3 xmi to SysML 1.2.
It was a bit more complicated for SysML 1.2 because we added an OCL constraint in SysML issue 11091 that required the same “copy down” package merge trick we did for UML issue 7364.
Fortunately for SysML, it was easier for us since we had to mimick what we did in UML. Nonetheless, we should do something to avoid these annoying last-minute surprises.

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Constraint [2] in 15.3.15 says:

[2] A transition with kind external can source any vertex except entry points.
context Transition inv:
source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint implies kind = TransitionKind::local)

• Is the text and OCL saying that same thing? I think the text is saying "A implies not B", while the OCL is saying "B implies C", where:

A : kind = TransitionKind::external
B : source.oclIsKindOf(Pseudostate) and source.oclAsType(Pseudostate).kind = PseudostateKind::entryPoint
C: kind = TransitionKind::local (this is not the oppsite of "A" as there is a third kind of transition "internal")

This constraint should be fixed to match the text.

"Actually, reading 7.3.8 Classifier [8], I realize that the constraint in the resolution 9374 is superfluous since [8] already prevents a Class from specializing an AssociationClass or an Association from specializing an AssociationClass.

So, the options are:

1) leave the constraint editorially fixed as we did and file an issue to remove it at the next RTF
2) cancel the editorial fix and editorially remove the (superfluous) constraint from 9374

Either way is fine with me but I think that option (2) is better than (1)."

No Data Available

The introduction to section 17.4 states the following:

A number of primitive types have been defined for use in the specification of the UML metamodel. These include

primitive types such as Integer, Boolean, and String. These types are reused by both MOF and UML, and may potentially

be reused also in user models.

However the XMI for UML provides the definitions only as CMOF types not as UML types – so they cannot reliably/interchangeably be used/reused or referenced from user models. There would also need to be a normative URI defined for them.

Indeed for better interchange of UML user models, there needs to be a normative PrimitiveTypes package (with a normative URI) with the common primitive types that can be referenced by UML XMI documents.
Additionally, since such primitive types are also needed by almost all CMOF-based metamodels, a PrimitiveTypes CMOF package is needed. Unfortunately, the PrimitiveTypes package provided in the InfrastructureLibrary is meant to be package merged vs. referenced by metamodels. Since only few metamodels merge it (still resulting in private copies), the rest duplicate these primitive types in their context.
This resolution proposes moving the PrimitiveTypes package out of InfrastructureLibrary.cmof and into its own independent package (PrimitiveTypes.cmof). This package can then be referenced instead of copied (through package merge) by metamodels. Additionally, the package can also be exported in UML XMI as PrimitiveTypes.xmi, to be referenced by user models.

Issue on UML 2.2 Superstructure, Section 7.3.32:

1. There are 2 constraints numbered [1]

2. The 2nd of these is: lowerBound()->notEmpty() implies lowerBound() >= 0.

However the way lowerBound() is defined (operation [4]) means it can never be empty: lowerBound = if lowerValue->isEmpty() then 1 else lowerValue.integerValue() endif

It makes more sense to have the constraint condition apply to the stored lowerValue. i.e. lowerValue()->notEmpty() implies lowerBound() >= 0

3. Likewise constraint [2] should be: upperValue()->notEmpty() implies upperBound() >= lowerBound()

4. Note that this omits the test currently in constraint for lowerValue notEmpty since lowerBound will then default to 1 – and it’s necessary to have the constraint check that upperValue is not less.

5. /upper and /lower are defined as [0..1]. However since they are defined in terms of upper/lowerValue – which always has a value - then they will never be empty so should be declared as [1].

1. This is no longer relevant in UML 2.5.
2. Actually, lowerBound can be empty, because lowerValue.integerValue() will be empty if lowerValue does
not have an integer value. Redefining lowerBound() to check if lowerValue.integerValue() is null, rather
than just lowerValue, would ensure that lowerBound always was non-empty. With this change, simply
lowerBound() >=0 would be sufficient for the constraint. (But see also the resolution to Issue 17583.)
3. Similarly changing the definition of upperBound() to check upperValue.unlimitedValue() would mean
that upperBound() >= lowerBound() would be sufficient as the constraint.
4. Actually, including the constraint upperValue->notEmpty() is not correct. Because if the upperValue is
empty, then upperBound() defaults to 1, which still needs to be greater than or equal to lowerBound().
5. Actually, upper and lower are defined in terms of upperBound() and lowerBound(), not upperValue
and lowerValue. Modified as described above, those operations will always return a value. So, the return
parameters for upperBound() and lowerBound() should have multiplicity 1..1, as well as the attributes upper
and lower.
This also resolves Issue 17808.

In RedefinableTemplateSignature.Associations we have this

extendedSignature : RedefinableTemplateSignature[*] The template signature that is extended by this template signature. Subsets RedefinableElement::redefinedElement.

It should read “The template signatures that are extended ...”

Similarly the constraint says:

The inherited parameters are the parameters of the extended template signature.

And should read “extended templates signatures”.

More seriously, the semantics says nothing about what happens when more than one of the extended template signatures have parameters with the same name. Is it an error? Are they merged (in which case what happens if they are different types)? Are they all there in which case what is the syntax for differentiating them? (e.g. Super1::T : Class, Super2::T : Class)

Correct the plurals, and explain that qualified names will be used to differentiate in the case of clashes. Fix
the logic of qualified names so that template parameters have them. This is a bit tricky because TemplateParameter,
TemplateSignature, TemplateableElement and ParameterableElement do not specialize NamedElement.
The approach adopted is to change the allNamespaces() operation on NamedElement so that if the
template is a namespace, it is used as the enclosing namespace for the ParameterableElement, which is in
fact guaranteed to be a NamedElement because all specializations of ParameterableElement are

The fact that StructuredActivityNode specializes ExecutableNode but does not specialize Action in figure 12.21 is intentional. The StructuredActivities package is merged into L2, and at this level it is intended that “simple” structured nodes be usable on activities without being actions themselves, without pins, etc. This is to support a “procedural” style of the use of actions (along with the use of variables, sequence nodes and value pins).

It is only in CompleteStructuredActivites (figure 12.22) that StructuredActivityNode specializes Action. CompleteStructuredActivities is merged into L3. As a result, at this level, StructuredActivityNode ends up specializing both ExecutableNode and Action, even though this is redundant. But I don’t think it is avoidable if the structured nodes are to be kept as non-actions in StructuredActivities and L2.

Finally, the extra ActivityGroup element that appears on figure 12.21 seems to be completely irrelevant. ActivityGroup already has an association with Activity as originally defined in FundamentalActivities, so the merge increment doesn’t seem to add anything. And, as you note, StructuredActivityNode doesn’t even specialize it. My (unresearched) guess is that there was a change at some point to have StructuredActivityNode specialize FundamentalActivities::ActivityGroup rather than the StructuredActivities::ActivityGroup merge increment, and then the latter was just never removed (and remained unnoticed in its little corner of the diagram!).

So, I think the class description text is OK, but there should be an issue filed to remove StructuredActivities::ActivityGroup – it is probably more than should be done “editorially”. But this is not particularly urgent, since the extra ActivityGroup merge increment on figure 12.21 doesn’t actually hurt anything in the end.

See issue 15264 for disposition

I noticed that in section 18.3.6 (as well as Infrastructure 13.1.6) the addition operation allOwningPackages is defined in the namespace of NamedElement and not Profile. In the metamodel, this operation is defined in InfrastructureLibrary::Profiles::NamedElement, which is a class that is not defined in the spec doc in clause 18 (neither in clause 13 in InfrastructureLibrary).

Shouldn't there be a section NamedElement in clause 18 (superstructure) and clause 13 (infrastructure libary) to define this additional operation, as implemented by the metamodel now? (since the operation is already defined in that namespace)

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Based on UML 2.2 Diagram 9.2, it appears that Property is optionally part of StructuredClassifer. Now I understand that Properties may also be part of other things (such as associations and interfaces). But it appears that in all such places such ownership is optional.

As Properties are features, looking at the multiplicity on Feature, we see Feature:featuring Classifier is 0..*. This means that Properties (and other features) need not be part of anything.

So can you have a “free-floating” property? Where can you put it? Since Properties are not packagable, they can’t be owned by Packages.

There are (at least) two ways of solving this (I prefer the first)

1) Make properties packageable. This gives us the advantage of making a package or model-library of constants properties.

2) Fix the hole and make properties required to be owned by something.

A nearly identical argument arises from Connectors which also may be free-floating, but are not packageable.

In SysML there is some interest in making connectors packageable (possibly as we care not about code-generation in the UML sense) as it would allow us to use Binding connectors (a SysML type of connector that declares equivalence) in package or class (in SysML, Block) diagrams

Again there are two ways of solving this (I prefer the first)

1) Make connectors packageable.

2) Fix the hole and make connectors required to be owned by something.

A more general solution may be to just apply the solution strategy to features as a whole, which would minimize the changes.

The issue is incorrect to state that properties/connectors need not be owned. They both inherit Element::mustBeOwned(),
which means that they must have an owner.
Disposition: Closed - No Change

In UML, Operation-interface should subset Feature-featuringClassifier and NamedElement-namespace, just like Operation-class and Operation-datatype. This is needed since the opposite of Operation-interface, which is ‘Interface-ownedOperation’ subsets ‘Classifier-feature’ and ‘Namespace-ownedMember’.

This issue affects the XMI and the specification document of the UML2 superstructure.

Actor constraint [1] says: self.ownedAttribute->forAll ( a | (a.association->notEmpty()) implies ((a.association.memberEnd.size() = 2) and (a.opposite.class.oclIsKindOf(UseCase) or (a.opposite.class.oclIsKindOf(Class) and not a.opposite.class.oclIsKindOf(Behavior))))

But Actor has no ownedAttribute property, so this constraint is ill-formed.

Merged with 10780

Class::nestedClassifier currently reads:

nestedClassifier: Classifier [*] References all the Classifiers that are defined (nested) within the Class. Subsets Element::ownedMember

Element::ownedMember does not exist. It should say Subsets Namespace::ownedMember.

See issue 10829 for disposition

The diagram on page 83 states that Classifier generalises Namespace, but the text of 9.19.1 states that Classifier (as specialized) generalises Classifier. Which is it? Should it be both?

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Currently is it possible for a Classifier to specialize the same classifier directly more than once, that is, generalization.general contains duplicates. There should probably be a constraint to make this invalid.

This seems harmless. Also, there might be scenarios where the same pair of classifiers are related by more than one
generalization each associated with different GeneralizationSets. Prohibiting this might also invalidate existing models
unnecessarily.
Disposition: Closed - No Change

the definition of nestedClassifier is misleading. Maybe something like: "Classifier definitions owned by the class. Subsets NameSpace::ownedMember" would be better.

Rephrase the metamodel documentation, and remove a difficult-to-parse and redundant sentence from the
semantics.

The diagram on page 50 shows that a Classifier is generalized from Type , whereas the accompanying text states that Classifier is generalized from Type AND Classifier (as Specialized). Should Classifier (as Specialized) be added to the diagram? Thanks, Paul

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Classifier::parents() is defined as "parents = generalization.general". However there is a type mismatch: the operation return type is a Set whereas the expression is a Bag. It should be defined as "parents = generalization.general->asSet()".

This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change

Spec. version 2.2 ptc/2008-05-xx

Regarding section 12.3.48 on page 412, I believe that both StructuredActivityNode::node and StructuredActivityNode::edge should also subset Namespace::ownedElement.