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 issue addresses a widely-recognized fundamental omission from UML. As such it is worthy of making an exception to normal RTF policy of not introducing new features to the language, particularly since the new feature is purely additive.
But the wording of the proposed change in the UPMS specification is somewhat problematical. Notably the idea of "incoming" and "outgoing" does not sit very comfortably with the notion of a Port being essentially a bidirectional intermediary entity which specifies both provided and required interfaces.
For this reason we propose a slightly different solution with similar semantic consequences: the introduction of a Boolean property isConjugated (default false) to the metaclass Port. When isConjugated is false, the semantics of Port are what they are today. When isConjugated is true, the calculation of provided and required interfaces from the Port's type is inverted.
This works nicely when the type of a port is a single interface, because it allows a port that provides one interface and a port that requires one interface both to be simply represented. Today, a simple port that requires one interface has to be typed by a class that requires that interface, which is cumbersome and inconvenient.
However, the idea of conjugating a port renders problematical the concept of instantiating the port type in the form of "interaction points" as currently specified in chapter 9. Instantiating the same type at both ends of an asymmetrical link is clearly unlikely to work. From a SoaML point of view, the port type represents a protocol, which will be applied differently at each end of the link depending on the sense of isConjugated. Therefore from a UML point of view we propose to delete all text that suggests direct instantiation of port types.
Finally, it is important for modelers to be able to distinguish conjugated ports in the notation, so we introduce suitable new notation.

In chapter 9 (CompositeStructures) the semantics of ports are given strictly in terms of instantiating the owning classifier and instantiating the ports as “interaction point objects” typed by the type of the port. Yet in chapter 8 (Components), a Component (through its IsIndirectlyInstantiated attribute) may not be instantiated at run time, in which case the inherited semantics of ports and port types cannot apply. The sentence from 8.3.1 “The required and provided interfaces may optionally be organized through ports, these enable the definition of named sets of provided and required interfaces that are typically (but not always) addressed at run-time” clearly states that ports are a way to organize required and provided interfaces of a component at design time, yet this is contradictory to the notion that the provided and required interfaces of a port are derived from its type which is instantiated as interaction point objects. These contradictions should be resolved

Much of this issue is resolved by 13080, in which the text about the interaction point objects being instances of the port types has been deleted.
The remainder of the issue can be handled by some explanatory text as proposed below.

Please explain why constrainedElement has to be an ordered set and not a set

Duplicate

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.

Instance modeling does not take into account stereotypes properties.

Assume I create a stereotype that I apply to some Class. That stereotype adds some property 'p' of type String. Now assume I create an InstanceSpecification of that Class.

I believe I should be able to create a slot for 'p' and assign some value to it.

Constraint [1] on InstanceSpecification 7.3.22 seems to restrict this since it mentions that the defining feature of each slot is a structural feature of a classifier of the instance specification. The properties contributed by the stereotype are not considered to be part of the features of the Classifier (assuming the stereotype is applied to a Classifier)

withdrawn by issue submitter

Typo in attributes section of comment: Remove "multiplicity" (red colored) before attribute body.

No Data Available

A package can only own packageable elements. That excludes comments. On the other hand the comment definition states: A comment can be owned by any element. That's a contradiction. It's important that packages can own comments. Therefore I propose a change of the package to allow the ownership of comments.

Discussion: It is not quite right to say that “a package can only own packageable elements”. The spec only says that “Only packageable elements can be owned members of a package.” That is, any owned members of the package, considered as a namespace, must be packageable elements – this is because packagedMember subsets the ownedMember derived union and no other property of Package does. However, a namespace (and hence a package) can have owned elements that are not owned members. In fact, all elements inherit the Element::ownedComment property that subsets ownedElement. For a namespace, ownedMember also subsets ownedElement, so the owned elements of a namespace (and hence a package) include both comments and namespace members. However, while a comment can thus owned by a namespace, it cannot be a member of the namespace, since it is not a named element. Disposition: Closed, no change.

Using the 07-02-03, 2.1.1 spec we have the following (pg 569 or 583/732 section 15.3.14 Transition :: Constraints)):
[5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind <> #junction) and (source.kind <> #join) and (source.kind <> #initial)) implies trigger->isEmpty()

This OCL erroneously states that Junctions and Joins may have outgoing transitions with triggers. As far as I understand, one can never be waiting in a junction point or join for a trigger to occur.

No Data Available

In the 2.1.1 specification (070205):

Regarding the quote on p128:
"All redefinitions should be made explicit with the use of a

property string. Matching features in subclasses without an explicit redefinition result in a redefinition that need not be shown in the notation. Redefinition prevents inheritance of a redefined element into the redefinition context thereby making the name of the redefined element available for reuse, either for the redefining element, or for some other."

I interpret the following quote from the UML 2.1.1 spec to mean that when a subclass includes a property whose name is equal to a property in one of its general classes, then it should be treated as a redefinition even if there is no explicit redefinition between those properties in the model.
This should be clarified in the spec. It is unclear and also includes at least one spelling mistake. Alternatively, we should ban implicit redefinitions and flag them as simple name conflicts.

Two features of the same kind defined in a class and a superclass (i.e., they are both either structural features or behavioral features) does indeed imply a redefinition and, therefore, must conform to the compatibility constraint on redefinitions.

No Data Available

The definition of Port.isService appears to be redundant with the concept of public/private visibility. Is it valid for an isService=true Port to be private, or for an isService=false Port to be public? What about protected and package visibility for Ports?

Resolution:
From Bran Selic:
Please note that isService=false is intended for modeling so-called SPPs (service provision points) in UML-RT. SPPs are ports that are used by the implementation of a structured class to access run-time services of the underlying support layers. In contrast to ports for which isService=true, SPPs are implementation specific – in other words, they are not part of the services that a component publishes to its clients. On the other hand, they must be public ports or you will not be able to connect to them from the outside.

It is a subtle distinction but an important one. The notion of implementation-specific interfaces is one that has, unfortunately, been generally missed in programming languages. It is a key element of layering.

If you remove this capability, you will certainly invalidate a lot of models based on this notion.

Revised Text:
None.

Disposition: Closed, no change.

Could you please clarify what does the UML2 specifications intend for "provided port" and "required port"? Intuitively, it seems that a port could provide (respectively require) the interface which types it. This is in contradiction with the UML2 definition of port. Nevertheless, I belive a port should be able to require the interface tpeing it: the type of a port and its role (provide/require) should be decoupled. This is basically what the graphical front-end of Rhapsody does. It is also the same approach used for SysML ports, where direction is decoupled from the type of the port.

The idea of decoupling the type from the interface is addressed by 13080. The clarification is addressed here by the text revisions below.

There seems to be an inconsistency in the spec.

Supersturcture v2.2 ptc/2008-05-xx
p 550

The spec mentions:
A state with isSimple=true is said to be a simple state. A simple state does not have any regions **and it does not refer to any submachine state machine.**

It also says in the constraints section ( constraint [4] ) :
A simple state is a state without any regions. isSimple = region.isEmpty()

The constraint seems to be missing the part about not refering to any submachine state machine.

The submitter is correct. Add the missing constraint to the isSimple() operation of State by adding that the
isSubmachineState attribute has to be false

To better express links with InstanceSpecifications, InstanceSpecification should be able to reference Slots owned by other InstanceSpecifications similar to an Association's memberEnd. Currently, when modelling an object diagram with a link like the one in fig. 7.54 on p.85, the specification is unclear on which of the involved InstanceSpecifications (Don, Josh, assoc) should own which Slots (father, son). Assuming that the involved association ends are ownedAttributes of the respective classes (Person), one would expect the object specifications (Don, Josh) to have Slots for these ends. Similarly one would expect the link InstanceSpecification to somehow reference its ends. Since a Slot can only belong to one InstanceSpecification, this is currently only possible by duplicating Slots and InstanceValues between object and link InstanceSpecifications (at least that is how e.g. Rational does it). This leads to two problems. First there is of course a lot of redundancy and chances for inconsistency. Second, and more importantly, there is no easy way to navigate from an object InstanceSpecification to the "connected" link InstanceSpecifications. On type level, an association can reference member ends that are owned by other classifiers. For the sake of consistency and simplicity, we would suggest something similar on the instance level for the InstanceSpecification-Slot relationship, i.e. a memberSlot referencing Slots owned by other InstanceSpecifications (maybe in a specialized LinkSpecification). I have created some diagrams to better illustrate the problem, albeit for a different example: - The example: http://www.reckord.de/uml/example.png - What it currently looks like on the meta level: http://www.reckord.de/uml/example-metaobjects.png - What it could look like: http://www.reckord.de/uml/example-meta-fixed.png

Merged with 9961

The specificMachine association of metaclass ProtocolConformance is of type ProtocolStateMachine, which would seem to prohibit the specificMachine from being a BehaviorStateMachines::StateMachine. However, the text sections of section 15.3.5, including the Description and Semantics sections, are very clear that the conforming StateMachine may be a BehavioralStateMachine::StateMachine, which make sense. So the specificMachine association should be changed to be type StateMachine. Also, Figure 15.5 should be similarly changed.

The protocol conformance relationship was explicitly intended to model relationships between protocol state machines
(this is clearly stated in the spec). It is unclear what would be the precise meaning of that type of relationship between
different kinds of state machines, but, whatever it might be, it is likely to be complex, dealing with issues such as
behavioral equivalence. This is still an open research topic with many different approaches and not something one
should standardize as yet.
Disposition: Closed - No Change

[2] The type and ordering of the result output pin are the same as the type and ordering of the open association end.
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

"AssociationEnd" -> "Propertye"

[3] The multiplicity of the open association end must be compatible with the multiplicity of the result output pin.
270 UML Superstructure Specification, v2.2
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

"AssociationEnd" -> "Propertye"

[4] The open end must be navigable.
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

"AssociationEnd" -> "Propertye"

[5] Visibility of the open end must allow access to the object performing the action.
let host : Classifier = self.context in
let openend : AssociationEnd = self.endData->select(ed | ed.value->size() = 0)>asSequence()>first().end in

"AssociationEnd" -> "Propertye"

See issue 6462 (resolved in UML 2.3) for disposition

1)>[1] The operation allConnections results in the set of all AssociationEnds of the Association.

"AssociationEnds" is "Properties", isn't it?

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

[3] The query allParents() gives all of the direct and indirect
ancestors of a generalized Classifier.
Classifier::allParents(): Set(Classifier);
allParents = self.parents()>union(self.parents()>collect(p |
p.allParents())

It seems to be lack of the last parenthesis.

Indeed, there is a missing closing parenthesis.

Classifier has association end "attribute". The association should have the opposite
side of "attribute". Such association end should be "Classifier::attribute".
In the case of "Class", "Datatype", "StructuredClassider" (however, there is a typo),
"Signal", such element have "Classifier::attribute" association end.
However, Interface and Artifact don't have such association end.

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

ownedAttribute : Property[0..*]
References the properties owned by the classifier. (Substes StructuredClassifier:: role,
Classifier.attribute...
~~~~~~~~~~~~~~~~~~~~
Classifier::attribute?

No Data Available

However, according to the class description for Property,
Property is "from Kernel and AssociationClass".
Property is defined in Interfaces Package.
Therefore, it seems Property is "from Kernel, Interfaces and AssociationClass".

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

"clientDependency: Dependency[*]
Indicates the dependencies that reference the client."

This explanations is described in "Attribute" clause, not Associations" of NemedElment.
It seems to be in incorrect clause.

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

"A property related to a classifier by ownedAttribute represents an attribute..."
and in its semantics
"When a property is owned by a classifier other than an association via ownedAttribute, then it represents an attribute of
the class or data type."

However, in the case of "StructuredClassifier", "Signal", "Artifact",
"Interface".
"attribute" is not necessary

The specification should modified as followings.

p125 L7:
"A property related to a classifier by attribute represents an attribute,"

and

p128 L17
"When a property is owned by a classifier other than an association, then it represents an attribute of the classifier."

The issue is not correct. All attributes are in fact owned via a property called ownedAttribute, different in each case,
but this is true for all subclasses of Classifier including Interface, Signal, Artifact, etc. So the text is correct.
Disposition: Closed - No Change

[4]The query isAttribute() is true if the Property is defined as an attribute of
some classifier.
context Property::isAttribute(p : Property) : Boolean
post : result = Classifier.allInstances->exists(C|c.attribute->includes(p))

This OCL means there is at least one element of Property.
Then, it is better to represent as "not classifier->isEmpty, not "Classifer.allinstances"
like opertation [3]. It is better to represent similar style in a same block.

This issue relates to aleady mentioned issue(Issue 11120). However, it is not exactly same.

Merged with 11120

The first paragraph of section 7.8 suggests that the UML kernel is the merge of Core::Abstractions packages. To obtain Classifier in the UML kernel, we would have to merge Classifiers, Super and Generalizations from Core::Abstractions. How is this possible given that: a) there are no generalization relationships among Classifier metaclasses in these Abstractions packages b) there are two matching operations:

::Classifier::parents (a) means that Generalizations::Classifier::parents cannot redefine Super::Classifier::parents. Even if there were a generalization, the resulting merged model would be ill-formed because it would include a generalization self-loop. (b) means that the merge is ill-formed because it violates constraint #4 defined in the general package merge rules in 11.9.3 (p. 164) POSSIBLE WORKAROUND: - split Core::Abstractions::Super in two packages: Super and SuperParents which only defines Classifier::parents - ditto for Core::Abstractions::Generalizations - if Super is to be merged but Generalizations isn't, then merge SuperParents as well. - if both Super and Generalizations are to be merged, then merge GeneralizationsParent but not SuperParents This is a kludge but that's the only short-term workaround I can find for this bug at this time.

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

page 50, the "nestedClassifier" association of Class is described like this: "References all the Classifiers that are defined (nested) within the Class. Subsets Element::ownedMember" page 148, the "packagedElement" association of Component is described like this: packagedElement: PackageableElement [*] "The set of PackageableElements that a Component owns. In the namespace of a component, all model elements that are involved in or related to its definition may be owned or imported explicitly. These may include e.g., Classes, Interfaces, Components, Packages, Use cases, Dependencies (e.g., mappings), and Artifacts. Subsets Namespace::ownedMember." This means a Class may own a Component and this Component may own a Package. I wonder what a Class owning (transitively) a Package could mean.

This is one example of the unintended consequences of Component inheriting from Class. We may observe a related consequence, that it is possible for a Component to own another Component in two ways: as a nestedClassifier, and as a packagedElement. There is no distinction, notationally or otherwise, between these two modes of ownership.
We can resolve these by adding two constraints to Component:
· A Component's nestedClassifier collection is always empty.
· If a Component is nested in a Class, then its packagedElement collection is empty.

for Port, there is a constraint that say :

[1] The required interfaces of a port must be provided by elements to which the port is connected.

I believe that ports are connected by delegation connector, this constraint may not be checked!

Am I right?

You are right, and this constraint is more correctly covered by a revised constraint [1] in chapter 8.

As it is intended by the current specification, an Interaction may be modeled independent of any BehavioredClassifier, which owns it. This would e.g. allow to use Interactions to model communication between analysis objects at a very early analysis stage, where no classes have been designed yet. The intention is manifested in the specification by allowing that a Lifeline or Messages does not have to specify a Property (Multiplicity of 0..1 of Lifelines->represents) or a Connector (Multiplicity of 0..1 of Message->connector) respectively (and that an Interaction does not have to be owned by a BehavioredClassifier). However, the restriction that every OccurrenceSpecification, and as such also every MessageOccurenceSpecification has to be associated with an event (compare Figure 14.5 on page 462) prevents that an Interaction may be used in above described manner. The reason for this is is as follows: 1) As the absense of a MessageEnd has another semantics (the MessageKind is inferred from it), in above described scenario, MessageEnds should indeed be specified (a complete message would be the only appropriate kind to model communication between objects as in above described scenario) 2) Because of above described multiplicity constraint, the MessageOccurenceSpecifications serving as sendEvent and receiveEvent of the message have to refer to some SendSignalEvent/ReceiveSignalEvent or SendOperationEvent/ReceiveOperationEvent respectively. 3) Those events in turn require to specify a Signal or Operation (see Figure 14.2 on page 459). 4) The Signal or Operation would have to be owned by some Classifier. There is however no Classifier in above described scenario, with exception of the Interaction itself (adding the Signals or Operations to the Interaction itself, would however require that all Signals and Operations are named unique, which is inappropriate). I would thus propose to change the specification, so that MessageOccurenceSpecifications (or OccurenceSpecifications) may, but do not have to specify an event (i.e. change multiplicity from 1 to 0..1).

Changing this cardinality in the metamodel is a breaking change, and is unnessary.
It seems that, if you are modeling the sending of a message, then you are modeling that something is being sent. This
.something. can be modeled as a signal, even if, at an early stage of analysis, this is just a placeholder for more detail
to be added later.
There are no constraints requiring that a message signature refer to an operation or signal reception defined for the
type of the ConnectableElement associated with a Lifeline.
Disposition: Closed - No Change

In chapter 15.3.12 (p. 568) the keyword "final" is informally introduced for states: "the states VerifyCard, OutOfService, and VerifyTransaction in the ATM state machine in Figure 15.42 have been specified as

after or below the name of the State."

Agreed. The “final” keyword should be explained in the section describing the notation for state machines
and not in the examples paragraph, it should also be added to the list of keywords in Table C.1 in the
appendix

Section 11.3.25 gives the definition of MultiplicityElement::compatibleWith as: compatibleWith(other) = Integer.allInstances()-> forAll(i : Integer | self.includesCardinality implies other.includesCardinality) While technically correct, this may be a little impractical for any OCL interpreting tool. I think an alternative, that simply uses the upper and lower bounds, would be: compatibleWith(other) = other.includesMultiplicity(self)

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

Various readers are interpreting InstanceSpecification differently. One interpretation is that a particular InstanceSpecification specifies a particular instance. A second interpretation is that a particular InstanceSpecification may be used to specify more than one instance. I prefer the second interpretation. This is supported by the Note at the bottom of page 83 that refers to "... such structures."

It is clear from this sentence: “As an InstanceSpecification may only partially determine the properties of an
individual, there may actually be multiple individuals in the modeled system that satisfy the requirements
of the InstanceSpecification.”
But some of the earlier text seems to imply different - this text is changed.

Please insert a figure showing an AssociationClass that is a ternary association to make clear whether the dashed line is to be connected to a line or the diamond. (Use can re-use figure 7.21 on page 44).

Merged with 8974

Please explain constrainedElement has to be an ordered set and not a set.

The order of the constrainedElements may make a significant difference on the meaning of the constraint. For instance,
a constraint on two numeric elementsmay require that one is less than the other, or a constraint on two sets may require
one to be a subset of the other.
Disposition: Closed - No Change

Chapter 13.3.3, section “Changes from previous UML“: “The metaattributes isLeaf and isRoot have been replaced by properties inherited from RedefinableElement.” RedefinableElement does not have the property isRoot.

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

The car dependency example on page 63 of the UML Super Structure Specification appears wrong to me. The description indicates to me that the arrow should be going from the car to the carfactory not the other way around as depicted.

Merged with 11489

ActivityNode need not specialize “NamedElement (from Kernel, Dependencies)” because is specializes ““RedefinableElement (from Kernel)” which in turn specializes “NamedElement (from Kernel, Dependencies)”.

No Data Available

Are qualifiers displayed at opposite end of association than role name (or multiplicity) or near the role name (or multiplicity)?

E.g. composition diamond is displayed at opposite end, multiplicity value – at the same end. How about qualifiers?

UML 2.1.2 page 124:

qualifier : Property [*] An optional list of ordered qualifier attributes for the end.

Notation (page 128):

The qualifier is attached to the source end of the association.

What is the “source of the association” ???

Look at figure from UML spec (first sample):

Are these qualifiers owned in association end typed by Bank or Person?

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

What happens with the do activity if a internal transition fires? It is not mentioned in the specification.

Since the state is not exited, the do activity is unaffected by the firing of the internal transition.
Add a clarifying statement to make this point explicit

“Certain kinds of constraints (such as an association “xor” constraint) are predefined in UML” Please insert a reference to the document containing the predefined constraints

See issue 9617 for disposition

Source: UML 2.2 Superstructure document and XMI

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/cgi-bin/doc?ptc/08-05-12

Nature: Unspecified OCL constraint

Summary:

The following constraint on ActivityNode (12.3.8) is unspecified:

[1] Activity nodes can only be owned by activities or groups.

Discussion:

OCL 101.

Revised Text:

Change the specification of the constraint to the following:

[1] Activity nodes can only be owned by activities or groups.
self.activity=self.owner xor self.inGroup->includes(self.owner.oclAsType(ActivityGroup))

Change the Superstructure XMI accordingly.

This issue is obsolete. All constraints have been specified in UML 2.5.
Disposition: Closed - No Change

Source: UML 2.2 Superstructure document and XMI

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/cgi-bin/doc?ptc/08-05-12

Nature: Unspecified OCL constraint

Summary:

The following constraint on AcceptEventAction (11.3.2) is unspecified:

[4] If isUnmarshalled is true, there must be exactly one trigger for events of type SignalEvent. The number of result output
pins must be the same as the number of attributes of the signal. The type and ordering of each result output pin must be the
same as the corresponding attribute of the signal. The multiplicity of each result output pin must be compatible with the
multiplicity of the corresponding attribute.

This constraint implicitly requires that the AcceptEventAction.result property should be ordered to enable order-sensitive comparison with corresponding properties in Signal.ownedAttribute.

• result: OutputPin [0..*]
Pins holding the received event objects or their attributes. Event objects may be copied in transmission, so identity
might not be preserved.

The
– [4a] If isUnmarshalled is true, there must be exactly one trigger for events of type SignalEvent.
– [4b] The number of result output pins must be the same as the number of attributes of the signal.
– [4c] The type and ordering of each result output pin must be the same as the corresponding attribute of the signal.
– [4d] The multiplicity of each result output pin must be compatible with the multiplicity of the corresponding attribute.
self.isUnmarshall implies
(self.trigger->size() = 1 and let e:Event = self.trigger.event->asSequence()->first() in
e.oclIsKindOf(SignalEvent) and
let s:Signal = e.oclAsType(SignalEvent).signal in
Set

->forAll(i|
let ai:Property=s.ownedAttribute->at in
let ri:OutputPin= self.result->at in
ai.type = ri.type and ri.lower <= ai.lower and ri.upper >= ri.upper))

Note: if the result property is not ordered, this constraint can be approximated in the following manner:

(self.trigger->size() = 1 and let e:Event = self.trigger.event->asSequence()->first() in
e.oclIsKindOf(SignalEvent) and
let s:Signal = e.oclAsType(SignalEvent).signal in
Set

->forAll(i|
let ai:Property=s.ownedAttribute->at in
let ri:OutputPin= self.result->asOrderedSet()->at in
ai.type = ri.type and ri.lower <= ai.lower and ri.upper >= ri.upper))

Change the Superstructure XMI accordingly.

Merged with 8702

In the latest 2.2 version of the UML spec, there was a change for issue : 11409 - redirect TimeEvent::when to TimeExpression (from ValueSpecification).
In the resolution to that issue, figure 13.13 (p427) was properly updated but it looks like figure 13.12 has a problem in that the association from TimeEvent should go to TimeExpression

At first it seems like this would be any easy resolution - just update Figure 13.12. The problem is that the Event classes in Figure 13.12, including TimeEvent, are in the CommonBehaviors::Communications package, which is merged in at L1, while TimeExpression is in CommonBehaviors::SimpleTime, which is merged in at L2. Thus, having TimeEvent associated with TimeExpression - which is actually the case in the metamodel - causes a problem in the construction of L1 (which causes issues with the generation of XMI for L1).
Now, one possibility would be to make the TimeEvent class in SimpleTime a merge increment. But the merging of typed elements has the constraint (see 7.3.40):
"Matching typed elements (e.g., Properties, Parameters) must have conforming types. For types that are classes or data types, a conforming type is either the same type or a common supertype. For all other cases, conformance means that the types must be the same."
While not entirely clear, the implication is that the resulting type is the common supertype. In this case, TimeEvent::when has type ValueSpecification in Communications and type TimeExpression, a subclass of ValueSpecification, in SimpleTime. The common superclass is thus ValueSpecification - but if you end up with TimeEvent::when having type ValueSpecification in the merged L2, then there isn't much point in typing it as TimeExpression in SimpleTime!
Another possibility would be to leave the type of TimeEvent::when as ValueSpecification, which would allow a TimeExpression to be used when SimpleTime is included at L3. But this was explicitly changed in the UML 2.2 RTF, indicating a strong desire that the type of TimeEvent::when be TimeExpression (which does make some sense).
It also doesn't seem to be a good idea to merge SimpleTime into L1 instead of L2, just to be able to have TimeExpression available for TimeEvent.
So, the proposed resolution is that TimeEvent be moved into SimpleTime. This means that time events would only be allowed at L2, not L1. But since state machines aren't included until L2 and accept event actions not until L3, it seems unlikely that this would be a real problem.

Source: UML 2.2 Superstructure document and XMI

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/cgi-bin/doc?ptc/08-05-12

Nature: Unspecified OCL constraint

Summary:

The following constraint on Activity (12.3.8) is unspecified:

[1] Activity nodes may be owned by at most one structured node.

Discussion:

OCL 101.

Revised Text:

Change the specification of the constraint to the following:

[1] Activity nodes may be owned by at most one structured node.
self.inStructuredNode->notEmpty() implies (self.inStructuredNode.oclAsType(ActivityGroup)->includesAll(self.inGroup)
and self.inStructuredNode.oclAsType(Element)->includes(self.owner))

Change the Superstructure XMI accordingly.

This issue is obsolete. All constraints have been specified in UML 2.5.
Disposition: Closed - No Change

would like to get some clarification on the use of Profiles.

Although it does not explicitly state this in the UML superstructure specification, there seems to be an implication that only Profiles should actually own Stereotype. The fact that Stereotype can be owned by any Package seems to be an unintended side effect of inheritance. Is it true that the only feature intended to own a Stereotype is Profile::ownedStereotype ?

If it is true that only Profile can own a Stereotype, then it makes working with profiles with many stereotypes somewhat unruly (consider having 50 stereotypes). It would be nice to be able to group stereotypes within nested packages under a profile.

Nesting profiles within profiles does not seem like an appropriate solution since: in order to satisfy constraint [2] in 18.3.6 the nested profile would also have to reference a metamodel; inconvenient. And, how would users use such a profile? Would they apply each nested profile separately? This seems to raise more problems than it solves.

Either way, I would suggest that the spec. should provide some rules or guidelines in this area.

No Data Available

Property – Additional Operations, page 127.

In the description of “isConsistentWith” –

“[1] The query isConsistentWith() specifies, for any two Properties in a context in which redefinition is possible, whether redefinition would be logically consistent. A redefining property is consistent with a redefined property if the type of the redefining property conforms to the type of the redefined property, the multiplicity of the redefining property (if specified) is contained in the multiplicity of the redefined property, and the redefining property is derived if the redefined attribute is property.”

The last word, “property”, should be “derived”.

No Data Available

[3] The query isNavigable() indicates whether it is possible to navigate across the property.
Propery::isNavigable():Boolean
isNavigable = not classifier->isEmpty() or
association.owningAssociation.navigableOwnedEnd->includes(self)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"association", and "owningAssociation" are also associationend on Property.
Then, expression "association.owningAssociation" is not appropriate.
It seems "association" in the expression should be suppressed.

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

For example in UML, States, Transitions, Activities,
Use cases, Components, Attributes, Dependencies, etc.
~~~~~~~~~~
In UML2.2, Attribute isn't model element.
This seems incorrect.
This explanation is example, then, it seems term "Attributes" should be suppressed.

Problem is now out of date.
Disposition: Closed - No Change

Source: UML 2.2 Superstructure document and XMI

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/cgi-bin/doc?ptc/08-05-12

Nature: Unspecified OCL constraint

Summary:

The following constraint on Activity (12.3.4) is unspecified:

[3] The groups of an activity have no supergroups.

Discussion:

OCL 101.

Revised Text:

Change the specification of the constraint to the following:

[3] The groups of an activity have no supergroups.
self.group->forAll(superGroup->isEmpty())

Change the Superstructure XMI accordingly.

This issue is obsolete. All constraints have been specified in UML 2.5.
Disposition: Closed - No Change

Attribute -> Attributes

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

Sturcute CompositeStructure::InternalStructure.
Is it correct?
It seems typo. "CompositeStructures"

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

The sequence expression is denoted as "A1", "B1", "A3".
According to the specification, those messages means
asynchronous messages.
If so, the diagram doesn't show original intention.

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

There are underlined lifeline.
According to UML 2.2 specfication (chapter 14),
lifeline label refrains from underlined notation.
It seems these are not appropriate

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

"The Attributes owned by the Data Type. This is an ordered collection.
~~~~~~~~~~
Subsets Classifier::attribute and Element::ownedMember."

Attributes->attributes

Well spotted.

18.3.5 Package (from Profiles)

Description

A package can have one or more ProfileApplications to indicate which profiles have been applied.

Because a profile is a package, it is possible to apply a profile not only to packages, but also to profiles.”

A Profile is a subclass of InfrastructureLibrary::Constructs::Package, which cannot own ProfileApplications and so you can’t apply a profile to a profile.

Profiles does subclass Constructs::Package, but when Profiles is merged with Kernel::Classes::Package in UML compliance level L3, Package gets the ability to have applied profiles, as does its subclass, Profile. So whether a profile can be applied to a profile depends on what Profiles is merged with.

Note that Profiles cannot stand alone, with just an import of Constructs since it defines Class as a merge increment (in order to add extensions). Profiles::Class has no ownedAttributes, so without a merge, Stereotypes would not be able to have Properties.

However, applying a profile to a profile would extend the extensibility mechanisms of UML in non-standard ways that would not be supported by most tools. This would limit interoperability and break model interchange. So it should not be possible to apply a profile to another profile.
Disposition: Closed, no change.

The Semantics section for Feature says:

“A feature represents some characteristic for its featuring classifiers; this characteristic may be of the classifier’s instances considered individually (not static), or of the classifier itself (static).

A Feature can be a feature of multiple classifiers. The same feature cannot be static in one context but not another.”

It seems to me that the second sentence is simply a reiteration of the description of property “/ featuringClassifier: Classifier [0..*]”

The third sentence could be expressed more usefully as a constraint.

I’m also puzzled by the 0..* multiplicity on featuringClassifier. It would be useful if the description of Feature explained when a feature can have more than one featuring classifier.

Much of this issue refers to obsolete text. This resolution addresses its final paragraph. We discussed
this in our face-to-face meeting in Reston in March 2013 and decided to change the multiplicity of Feature::
featuringClassifier to 0..1 (because this is a logical consequence of the remainder of the UML spec and
does not affect serialization), and change the wording accordingly, pointing out the special case of Properties
used as qualifiers which have no featuringClassifier.

The regular ActivityFinalNode stops all possible parallel flows in the activity before
returning to the caller.
There are some cases where it would be interesting to have a variant of this behavior
which would allow returning immediately but without affecting the execution of any
parallel flow.

A use case for this "soft return" construct: An application process a user "search" request.
When it founds a first set of results it returns immediately the response to the user but it
the meantime continues looking for another set of requests to anticipate possible additional
request from the user, without loosing the context of the user request.

For this use case we will use the "soft return" final node to return when finding the first
set of responses and will use a FlowFinalNode at the end of a parallel branch looking for
additional responses.
For sure, it is always possible to encode this use case differently, but such new kind of
final node would allow to model the intended behavior more directly.

Rq: What would happen if a "soft return" is reached after a "soft return" already happened:
I guess the semantics would be to behave as a FlowFinalNode (cannot return twice).
And what if a "regular" ActivityFinalNode is reached after a "soft return": I guess all
existing parallel are stopped but there is no return to the caller (since already returned).

A behavior that is initially invoked via a synchronous call does not have its own thread of control, so it would be a fundamental semantics change to somehow allow it to continue executing after returning from the call. Fortunately, however, the functionality desired by the submitter can be easily achieved using existing UML mechanisms, by first starting the activity asynchronously, either as a classifier behavior or as a standalone behavior execution. Such an executing activity can then accept client requests using an accept event action and respond to them without terminating, as the submitter envisions. The activity can even accept a synchronous call via an accept call action and reply using a reply action, without terminating. In this case, the reply action acts, in effect, as the "soft return" suggested by the submitter.
Revised Text:
None
Disposition: Closed No Change

In section '10.3.12 Property (from Nodes)', the Description states "In the metamodel, Property is a specialization of DeploymentTarget", but a corresponding generalization is not defined under 'Generalization'. Proposed resolution: Add '"DeploymentTarget (From Nodes)" on page 205' to the Generalization section of 10.3.12.

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

section: PackageableElement (from Kernel), subsection: "Attribute" is writen "Default value is false." that it cannt has that value because its type is VibilityKind and can only has one of its enumerated value.

See issue 10379 for disposition

For example A_ownedMember_namespace

Has both its ends marked with isDerived=”true” but not the Association itself.

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

On Page 23 of the UML Infrastructure Spec. it is stated, that "The multiplicity of an association end is suppressed if it is ‘*’ (default in UML).". This implies that omitting to define the multipl. of an association end A means that the multiplicity of A is * (between zero and infinity). However this contradicts most books I know and some examples in the specification itself.

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

The description of MessageOccurenceSpecification defines a property called event. It is useless, because MessageOccurenceSpecification inherits from OccurenceSpecification that already owns this property, as denoted in the figure 14.5.

See issue 14629 for disposition

The list of literal described for the ennumeration MessageSort is not complete according to it sdescription as shown in figure 14.5.

No Data Available

The undefined term 'Element::redefinedElement' occurs three times in the standard where 'RedefinableElement::redefinedElement' is expected.

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

The first sentence of 7.4 states: As was depicted in Figure 7.1, the Profiles package depends on the Core package, .... Figure 7.1 does not shown any dependency between the Profiles package and the Core package

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

UML2 Superstructure specifies how to define a Profile, how Profiles can reference other Profiles through PackageImport and ElementImport, and how one stereotype could extend another through generalization/specialization. However, this is insufficient for profile integration as it results in too much coupling between profiles. What is needed is a more flexible mechanism for integrating UML2 profiles.

For example, both UPDM and SysML are UML2 profiles. UPDM would like to reuse certain stereotypes from SysML in order to provide effective integration in cases where consumers want to use both. However, UPDM would also like to be able to stand alone in cases where SysML isn't needed. The problem is how to model the overlapping stereotypes and classes without creating coupling that would require all applications of the UPDM profile to also require an application of SysML.

Consider a concrete example of overlap between the profiles, the stereotype ViewPoint. Both UPDM and SysML have a similar concept of ViewPoint, for similar purposes. However, each has its own specializations of ViewPoint, and possibly associations between ViewPoint and other stereotypes. There are a number of approaches for handling this overlap, but none are adequate or practical.

1. Profile refactoring: Each profile could factor its stereotypes into packages, and arrange the navigability of its associations to decouple its stereotypes in order to support anticipated reuse. This is what UML2 did, quite unsuccessfully, with the Abstractions packages. This isn't practical because 1) no existing profiles do it, 2) it is impossible to anticipate all the possible reuse opportunities and to design a profile to support them, and 3) it is sometimes impossible to define the associations between stereotypes to ensure the necessary decoupling.

2. Use ElementImport to select only the stereotypes you need, then subclass to minimize the coupling: This can work, but it results in complex profiles with possibly a lot of subclasses simply to integrate with other profiles. For example, UPDM couldn't use ViewPoint directly, it would have to create a subclass, either coming up with a new name, or putting its ViewPoint in a different Package so that it wouldn't collide with SysML. This is confusing, and results in stereotypes with either the same meaning but different names, or two stereotypes with the same name in different packages. This also requires both profiles to exist, even though the both don't need to be applied. This is again an undesirable side-effect of too much coupling.

Both of these approaches end up inhibiting profile integration and reuse resulting in limited integration between OMG submissions. UPMS had wanted to include integrations with many other submissions including RAS, BPDM, BPMN, ODM, QoS, and BMM. However we could not determine a practical way to do this with current technologies and did not include many of these integrations because of the resulting risk, complexity and coupling. This is a particular problem when we consider the OMG specifications, profiles, and metamodels in an enterprise architecture context where the relationships between the parts are critical to delivering value.

UML2 provides a solution to this problem for extensions created using MOF metamodels to model capabilities. PackageMerge can be used to merge metaclasses with the same name from different capabilities in order to mixin their capabilities. What is needed is a similar capability for UML2 profiles.

A proposed solution would be to extend UML2 Profiles to include similar merge semantics when multiple profiles containing the same classes or stereotypes are applied to the same model. When a Profile is applied to a Package, the Classes and Stereotypes in the Profile would be merged with Classes and Stereotypes of other Profiles that have already been applied. The rules for PackageMerge can be used to define how this merge is done as they already apply to Class, and can equally apply to Stereotype which is a specialization of Class. Conflicts resulting from the merge could be considered defects against the profiles that could be handled in an RTF.

Consider the same example above; both UPDM and SysML define ViewPoint.

3. Profile Merge: The UPDM submitters would be careful to use ViewPoint is a manner that is semantically consistent with SysML since SysML already existed. However UPDM conuld extend ViewPoint with additional properties and associations for its purposes. The UPDM submission could note to users that ViewPoint is a stereotype in UPDM that represents a "placeholder" to ViewPoint in SysML. Users could then apply UPDM to a model, and get UPDM's ViewPoint capabilities without any coupling or need for SysML. Later on, another user could decide to apply SysML to the same model in order to use its modeling capabilities. The SysML::ViewPoint would be merged with the UPDM::ViewPoint allowing the shared semantics to be supported without making any changes to the existing model. Similarly, users could have started with SysML and later applied UPDM to achieve the same effect.

This is a significant change to UML2, but may be an urgent issue due to the number of other profiles and submissions looking for a solution to this problem.

No Data Available

At 03:12 PM 8/13/2008, Pete Rivett wrote:

Well-spotted Nicolas: though from your example fragments you’re wrong to say that at 2.2 the ends are given a generic name – they are given a generic xmi:id and no name at all!
Both the change of name and (to a lesser extent) xmi:id, without being mandated by an issue resolution are IMHO serious bugs.
The xmi:id case is more controversial, since xmi:ids do not in general have to be stable. However, since they are frequently used for referencing the elements from outside the file (e.g. using XMI hrefs) then for standard metamodels I think we should keep them stable.

In fact I’d say that we should probably treat this as an urgent issue and produce a new XMI file ASAP.

>From the difference between the 2 fragments I spotted another discrepancy/bug in UML 2.2 – there is an incorrect owningAssociation attribute on the Property. This must not be serialized since it’s the opposite of the composite owner of the Property (Association.ownedEnd) and so redundant.

Clearly we should do more to perform diffs between the different versions of XMI files in order to catch inadvertent changes such as this.

Pete

From: Nicolas Rouquette [ nicolas.rouquette@jpl.nasa.gov]
Sent: 13 August 2008 19:15
To: uml2-rtf@omg.org; executableUMLFoundation@omg.org; Conrad Bock; Bran Selic; Ed Seidewitz; Stephen Mellor
Subject: unalabelled association-owned memberEnd property names affect the name of an association

I noticed strange differences between the XMI serialization of the UML superstructure in:

UML 2.1.2, i.e: http://www.omg.org/spec/UML/20061001/Superstructure.cmof
UML 2.2 beta1, i.e: http://www.omg.org/cgi-bin/doc?ptc/08-05-12

For example, in UML 2.1.2, we have:

<ownedMember xmi:type="cmof:Association" xmi:id="Actions-CompleteActions-A_result_readExtentAction" name="A_result_readExtentAction" memberEnd="Actions-CompleteActions-ReadExtentAction-result Actions-CompleteActions-A_result_readExtentAction-readExtentAction">
<ownedEnd xmi:type="cmof:Property" xmi:id="Actions-CompleteActions-A_result_readExtentAction-readExtentAction" name="readExtentAction" lower="0" type="Actions-CompleteActions-ReadExtentAction" association="Actions-CompleteActions-A_result_readExtentAction"/>
</ownedMember>

whereas in UML 2.2beta1, we have:

<ownedMember xmi:type="cmof:Association" xmi:id="Actions-CompleteActions-A_result_readExtentAction" name="A_result_readExtentAction" memberEnd="Actions-CompleteActions-ReadExtentAction-result Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0">
<ownedEnd xmi:type="cmof:Property" xmi:id="Actions-CompleteActions-A_result_readExtentAction-_ownedEnd.0" type="Actions-CompleteActions-ReadExtentAction" lower="0" owningAssociation="Actions-CompleteActions-A_result_readExtentAction" association="Actions-CompleteActions-A_result_readExtentAction"/>
</ownedMember>

In both cases, this association is described in Fig. 11.13 Object Actions (CompleteActions) in a way where the name of an association-owned memberEnd property isn't shown whereas the name of a class-owned memberEnd property is shown according to the conventions specified in clause 6.4.2 of the UML superstructure spec.

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/

The problem here is that the unlabelled association-owned memberEnd properties have been given generic names such as ownedEnd.0 instead of the convention defined in clause 6.4.2 – i.e., the name of the class with a lowercase initial.

Is it OK for association names to change in this manner from one rev to another or is this a bug?

Regardless of whether it is a bug or not w.r.t. current OMG specs, there is certainly a very undesirable consequence in name-level changes between revisions for a given concept when these revisions have not changed the semantics of that concept. Such incidental name-level changes create a lot of problems w.r.t. a stable notion of identity across revisions for detecting semantically-relevant changes from semantically irrelevant changes.

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

Section 2.2 introduces two compliance levels: L0 and LM. Section 2.3 states: "Compliance to a given level entails full realization of all language units that are defined for that compliance level. This also implies full realization of all language units in all the levels below that level. “Full realization” for a language unit at a given level means supporting the complete set of modeling concepts defined for that language unit at that level. Thus, it is not meaningful to claim compliance to, say, Level 2 without also being compliant with the Level 0 and Level 1." This is confusing as there is no such thing as Level 1 or Level 2 defined. This concept is repeated in section 2.4: "(as a rule, Level (N) includes all the packages supported by Level (N-1))" It may be worth mentioning that the superstructure document will introduce further levels on top of the infrastructure level L0. Also, if I understand it correctly: LM builds on L0, and so does L1. So we have two parallel paths of compliance: L0 <- LM and L0 <- L1 <- L2 <- L3 So how does LM fit in with the L(N) compliant is also L(N-1) compliant scheme? Do you need to specify L2 and LM compliance?

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

Source: UML 2.2 Superstructure document and XMI

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/cgi-bin/doc?ptc/08-05-12

Nature: Unspecified OCL constraint

Summary:

The following constraint on AcceptEventAction (11.3.2) is unspecified:

[1] AcceptEventActions may have no input pins.

Discussion:

OCL 101.

Revised Text:

Change the specification of the constraint to the following:

[1] AcceptEventActions may have no input pins.
self.input->isEmpty()

Merged with 8702

Source: UML 2.2 Superstructure document and XMI

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/cgi-bin/doc?ptc/08-05-12

Nature: incorrect OCL constraint

Summary:

The following constraint on BehavioredClassifier (13.3.4) is incorrectly specified:

[1] If a behavior is classifier behavior, it does not have a specification.
self.classifierBehavior->notEmpty() implies self.specification->isEmpty()

Discussion:

self.specification does not resolve to any attribute of BehavioredClassifier.
self.classifierBehavior resolves to a Behavior which can have 0 or 1 BehavioralFeature specification.
Hence, the correct OCL navigation expression should be self.classifierBehavior.specification instead of self.specification.

Revised Text:

Change the specification of the constraint to the following:

[1] If a behavior is classifier behavior, it does not have a specification.
self.classifierBehavior->notEmpty() implies self.classifierBehavior.specification->isEmpty()

Change the Superstructure XMI accordingly.

agreed

OCL reuses Boolean, Integer, String, UnlimitedNatural from UML Infrastructure.

OCL uses Real in a very similar fashion, but there is no corresponding
definition of Real in either OCL or UML Infrastructure.

The primitive type “Real” needs to be added to the PrimitiveTypes package for consistency with the OCL Real type. “Real” has also been defined separately by SysML and MARTE specifications and the new Diagram Definition Submission, so adding it to the PrimitiveTypes package will encourage reuse.
Another argument for adding a primitive type “Real” is that there is currently no normative way to notate real numerals in UML models. So, even if some model library adds a “Real” primitive type, there is technically still no normative way to write a literal for that type in a UML model. This suggests the need for a Real Literal definition as well.
(Note that the revised text below presumes the resolution to Issue 13993.)

UML Superstructure V2.2, Section 17.5.9 RedefinableTemplateSignature.

The paragraph in the "Semantics" section RedefinableTemplateSignature mentions the following:
All the formal template parameters of the extended signatures are included as formal template parameters of the extending signature, along with any parameters locally specified for the extending signature.

I beleive this would imply that the "parameter" feature would need to be derived which it is currently not.

/inheritedParameter is indeed derived and is a subset of parameter, which corresponds to the semantics.
Disposition: Closed - No Change

Source: UML 2.2 Superstructure document and XMI

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/cgi-bin/doc?ptc/08-05-12

Nature: Unspecified OCL constraint

Summary:

The following constraint on ActivityEdge (12.3.5) is unspecified:

Package CompleteStructuredActivities
[1] Activity edges may be owned by at most one structured node.

Discussion:

OCL 101.

Revised Text:

Change the specification of the constraint to the following:

Package CompleteStructuredActivities
[1] Activity edges may be owned by at most one structured node.
self.inStructuredNode->notEmpty() implies
(self.inStructuredNode.oclAsType(ActivityGroup)->includesAll(self.inGroup)
and self.inStructuredNode.oclAsType(Element)->includes(self.owner))

Change the Superstructure XMI accordingly.

This issue is obsolete. All constraints have been specified in UML 2.5.
Disposition: Closed - No Change

Source: UML 2.2 Superstructure document and XMI

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/cgi-bin/doc?ptc/08-05-12

Nature: Unspecified OCL constraint

Summary:

The following constraint on ActivityEdge (12.3.5) is unspecified:

[2] Activity edges may be owned only by activities or groups.

Discussion:

OCL 101.

Revised Text:

Change the specification of the constraint to the following:

[2] Activity edges may be owned only by activities or groups.
self.source.activity = self.activity and self.target.activity = self.activity

Change the Superstructure XMI accordingly.

This issue is obsolete. All constraints have been specified in UML 2.5.
Disposition: Closed - No Change

Source: UML 2.2 Superstructure document and XMI

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/cgi-bin/doc?ptc/08-05-12

Nature: Unspecified OCL constraint

Summary:

The following constraint on Activity (12.3.4) is unspecified:

[2] An activity cannot be autonomous and have a classifier or behavioral feature context at the same time.

Discussion:

OCL 101.

Revised Text:

Change the specification of the constraint to the following:

[2] An activity cannot be autonomous and have a classifier or behavioral feature context at the same time.
self.isActive implies (self.getContext()>isEmpty() and self.classifierBehavior>isEmpty())

Change the Superstructure XMI accordingly.

This issue is obsolete. All constraints have been specified in UML 2.5.
Disposition: Closed - No Change

Source: UML 2.2 Superstructure document and XMI

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/cgi-bin/doc?ptc/08-05-12

Nature: Unspecified OCL constraint

Summary:

The following constraint on Activity (12.3.4) is unspecified:

[1] The nodes of the activity must include one ActivityParameterNode for each parameter.

Discussion:

OCL 101.

Revised Text:

Change the specification of the constraint to the following:

[1] The nodes of the activity must include one ActivityParameterNode for each parameter.
self.node->select(oclIsKindOf(ActivityParameterNode)).oclAsType(ActivityParameterNode).parameter->asSet()>symmetricDifference(self.ownedParameter>asSet())->isEmpty()

Change the Superstructure XMI accordingly.

This issue is obsolete. All constraints have been specified in UML 2.5.
Disposition: Closed - No Change

As describe, a "Substitution" looks more like a derived property than like a relationship, except if it must be interpreted as an explicit inheritence restricted to the external contracts (with possible redefinition). The point is that is not clear with the current description

The revised text in UML 2.5 is clearer.
Disposition: Closed - No Change

Keyword ambiguity for DataType Section 7.3.11 Describes the use of the 'dataType' keyword (along with Figure 7.36). Whereas, the example depicted in Figure 7.39 shows a DataType with the 'datatype' keyword.

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

Source: UML 2.2 Superstructure document and XMI

http://www.omg.org/cgi-bin/doc?ptc/08-05-05
http://www.omg.org/cgi-bin/doc?ptc/08-05-12

Nature: Unspecified OCL constraint

Summary:

The following constraint on ActivityEdge (12.3.5) is unspecified:

[1] The source and target of an edge must be in the same activity as the edge.

Discussion:

OCL 101.

Revised Text:

Change the specification of the constraint to the following:

[1] The source and target of an edge must be in the same activity as the edge.
self.source.activity = self.activity and self.target.activity = self.activity

Change the Superstructure XMI accordingly

Change the specification of the constraint to the following:

[1] The source and target of an edge must be in the same activity as the edge.
let edgeActivity:Set(Activity) = self.inGroup->closure(inGroup).inActivity->asSet()>union(self.activity>asSet()) in
let sourceActivity:Set(Activity) = self.source.inGroup->closure(inGroup).inActivity->asSet() in
let targetActivity:Set(Activity) = self.source.inGroup->closure(inGroup).inActivity->asSet() in
edgeActivity->symmetricDifference(sourceActivity)->isEmpty() and
edgeActivity->symmetricDifference(targetActivity)->isEmpty()

Change the Superstructure XMI accordingly.

There is an association of EncapsulatedClassifier (9.3.8) ownedPort which is derived and subsets Class::ownedAttribute. The problem I have is that I don't see how ownedPort can subset Class::ownedAttribute. I don't see an inheritance path from EncapsulatedClassifier to Class. Also, which Class is it referring to? Class (from Kernel), Class (from StructuredClasses), etc. This problem exists for all "subsets" statements in the specification. Thank you.

It should in fact refer to StructuredClassifier::ownedAttribute

Version of Spec: 2.1.1 2007--2-05, Section 7.3.46 p.130

The definition of RedefinableElement::isLeaf indicates that "If the value is true, then it is not possible to further specialize the RedefinableElement". However there is no explicit constraint that actually enforces this (at least none that I could find). I believe that a constraint should be created to address this.

This issue is not a duplicate of issue 9831 which is closely related to issue 10515.

We are concerned with the UML specification forcing an Behavior's parameter list to be in sync with its behavioral feature.

>From the UML 2.1.1 07-02-03, page 431 (or 445/732) it states in the 13.3.2 Behaviors section the following constraint:
[1] The parameters of the behavior must match the parameters of the implemented behavioral feature

We feel that this constraint is unnecessary. The parameter list of a Behavior element can be derived from its behavioral feature. Forcing the Behavior to have its own list of parameters has practical implementation problems such as needlessly increasing the size of the UML model, and worse, forcing one to preform the tedious task (or the tool to preform the extra overhead) of keeping the parameter lists of the Behavior and its behavioral feature in sync.

We would like to request that this constraint is removed from the specification.

Merged with 7626

The way the PackageMerge relatrionships are used in the specification doesn't seem to be rigorous or, at least, are not clear. For instance: * §7.3.7 indicates that the "Class" from Kernel metaclass is a specialization of “Classifier (from Kernel, Dependencies, PowerTypes)”. That is not correct if you refere to the corresponding package diagram: "Class" from Kernel doesn't inherit from Dependencies and PowerType merge increment of "Classifier" * §7.3.6 "BehavioredClassifier" from Interfaces) is a merge increment of "BehavioredClassifier" from BasicBehavior) but not for "BehavioredClassifier" from Communications (it's the opposite). * etc... Then, i suggest to define PackageMerge relationships of the metamodele in a more formal way than simple diagrams and to validate that metaclass definition are consistent with these relationships.

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

Problem 6. 6.1 Operation is having very wide type (Type) as an exception instance (raisedException). Theoretically it is possible that Association may be thrown as an exception. ++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Agreed. I wish that this was the only place where the metamodel suffers from overgeneralization. Unfortunately, this is almost endemic in how things are done in UML.

If we were to constrain the type of exceptions, we might invalidate user models. There seems no reason to make a
change here.
Disposition: Closed - No Change

Problem 4 4.1. Exceptions raising is provided on L2 compliance level (RaiseExceptionAction from Actions/StructuredActions) while handling is provided on L3 (ExceptionHandler from Activities/ExtraStructerdActivities). That functionality is an integrated part and raising and handling exceptions should be provided on the same compliance level. ++++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Agreed. We did not focus too much on the modeling of exceptions – it was not a priority item at the time. It should probably be so now. Your work is definitely timely. Andrzej Zielinski: That is about my Ph.D thesis

Discussion
This issue is obsolete. There are no compliance levels in UML 2.5.

Problem 2 2.1 Relation raisedException of Operation and BehavioralFeature classes not consistently set (CommonBehaviors/Communications) (L2 compliance). Operation (Classes/Kernel) (L1 compliance level ) inherits from BehavioralFeature (Classes/Kernel) (L1) and redefines raisedException to Type. On that level there is no problem. But in CommonBehaviors/Communications BehavioralFeature redefines raisedExceptions to point to Classifier. As a result Operation points to Type, while BehavioralFeature to Classifier. Classifier is more specific than Type (Classifier inherits from Type) +++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Yes, that is a problem. I will relay it on to the OMG to be officially registered.

There does not seem to be any reason for Communications::BehavioralFeature to have a raisedException attribute. It is not used anywhere in Communications. Kernel::BehavioalrFeature already has a raisedException property that will be included when the BehavioralFeature merge increments are actually merged.

Problem 1 Some classes in certain packages are abstract, while they are not in packages that are on a higher (or the same) compliance level. 1.3. Pin in Activities/BasicActivities (L1 compliance level) (Fig. 12.4 p.299 ) and Activities/CompleteActivities (L3) (Fig.12.16 p. 305) are not abstract, while in they are in package ActionsBasicActions (L1) (Fig. 11.3 p. 221) ++++++++++++++++++++++++++++++++++++++++++ from Bran Selic <bran.selic@gmail.com> hide details Jun 9 to Andrzej Zielinski <072404@gmail.com> date Jun 9, 2008 7:46 PM subject Re: UML 2.x issues mailed-by gmail.com Bran Selic: Yes, that is a problem. I will relay it on to the OMG to be officially registered.

agreed

The behavior of an OpaqueExpression should itself be opaque

Under Subclause 13.3.21, it says that the extension to OpaqueExpression "Provides a mechanism for precisely defining the behavior of an opaque expression." It is hard to see how one can precisely define behavior, if the behavior is itself opaque. Indeed, specifying the behavior of an OpaqueExpression with, say, an activity is the only way to model an expression in UML in terms of executable actions, so this should not be precluded.
Revised Text:
None.
Disposition: Closed No Change

The multiplicity of the "signal" property of a Reception is [0..1]. What's the semantic of a Reception that would be associated with no signal?

Areception should be required to specify a signal.

Classifiers are specialized to hold useCase properties in the UseCases package but this package is not merged/imported by any other ones. Does it formally mean that - for instance - no version of the metaclass "Class" should be able to hold use cases?

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

In order to be complinat with the semantics, "body" and "language" properties of an OpaqueExpression shall be ordered

No Data Available

Section: 18.3.2 (Extension)

Extension::metaclass has the type Class. When the Profiles package is merged into L2, Profiles::Class is merged into L2::Class. This means that the metaclass for an extension has to be represented as a UML Class (at L2 or, after further merging, at L3).

However, the UML abstract syntax metamodel is not actually a UML model, but a CMOF model. This means that UML metaclasses are instances of CMOF::Class, not UML::Class (at L2 or L3). This means that it is not possible to actually construct a stereotype extension that points to a metaclass representation of the correct type.

UML tools currently get around this my referencing metaclasses from a version of the UML abstract syntax metamodel that is expressed in terms of UML L3, rather than CMOF. Or they just don't worry about the type checking. But that is not technically correct, and it means that stereotypes in each tool are referencing non-normative representations of the UML metamodel, rather than standard metaclass object IDs.

The problem is resolved by shipping a normative version of the UML metamodel expressed in terms of UML, and changing the text accordingly.
A couple of decisions need making about this metamodel, which we?ve discussed extensively in email:
1. Which compliance level of UML is used to create it? We?ll use the lowest compliance level that we can, which is L1. This means we cannot use Model, so the root of the metamodel will be a uml:Package.
2. Do we apply any stereotypes such as «metamodel» or «metaclass» in the normative UML model? The answer is no and follows from (1): since we don?t use Model, we cannot use «metamodel». Also, using stereotypes in order to specify stereotypes (see 14092) might give circularity or fixed-point issues. We are justified in omitting these by the wording of PresentationOptions in 18.3.1: “A Class that is extended by a Stereotype may be extended by the optional stereotype «metaclass» …”

In OCL 2.0 specification, section Operation Body Expression, it specifies that
expression must conform to the result type of the operation.

However, in UML 2.1.2 specificaiton, it is specified that bodyCondition of an
operation is a constratin which must evaluates to a boolean expression.

The problem is that UML equates the term "constraint" with "boolean-valued
expression that holds true at some time." The OCL usage of the term is not so
narrow. A constraint is a model element that specifies more precise semantics
for another model element than what its structure alone can achieve.

So, for example, an attribute constrains its values to conform to some type,
but a derivation expression (whose value conforms to the attribute type) more
precisely constrains its values. Likewise the operation body expression
constrains the value of an operation by computing it from the parameters and
the context object. Note that OCL actually calls this constraint a "body
expression," not a "body condition" as UML does. OCL's notion of "constraint"
even extends to definition of helper operations and attributes.

Consider what it means to require boolean values for operation body
constraints. They must be formulated like postconditions, as boolean
expressions on the "result" variable. In OCL, the body condition does not have
a "result" variable; only post-conditions have it. Furthermore, consider an
example: an operation phi() defined in the Real primitive type. According to
UML's rules, it could be defined like this:

context Real::phi() : Real
body: result = (1.0 + 5.0.sqrt()) / 2.0

or like this:

context Real::phi() : Real
body: (result - 1.0) = (1.0 / result)

These are isomorphic constraints, but neither is friendly to OCL tool
implementations (certainly not the second). According to OCL, the constraint
would by formulated like this:

context Real::phi() : Real
body: (1.0 + 5.0.sqrt()) / 2.0

and there really is no other kind of formulation. IMO, this is much more
practical for all concerned.

Consider an operation that has parameters, for which I write an ineffectual
body constraint like this:

context Foo::doSomething(bar1 : Bar, bar2 : Bar) : Baz
body: bar1 <> bar2

What does this mean?

All in all, it is far mare useful to have an OCL expression that can readily be
evaluated to compute the value of the operation. This leaves no room for
ambiguity.

The UML stipulation that Constraints in all contexts must be boolean
expressions, as in operation precondition and classifier invariant context, is
unnecessary. What is the benefit? It would be nice to see it removed in UML
2.3.

merged with 15259

I had a recent ‘argument’ with Steve Cook on his blog. There is a lot of confusion with regards to whether there can be multiple Associations with the same name in a Package. Steve made the valid point that Association does not redefine “isDistinguishableFrom”, which it gets from being a NamedElement. This is overridden for BehavioralFeature, but not for Association, thus based on that rule from NamedElement, I assume that there may not be multiple Associations with the same name (including empty) in a Package.

However, I came across the following cases that seem to ignore this notion:

1) In the rules for PackageMerge (7.3.40), they allow for the ability to have multiple Associations with the same name by taking into account their member ends: “Elements that are a kind of Association match by name (including if they have no name) and by their association ends where those match by name and type (i.e., the same rule as properties).”

2) The MOF 2.0 XMI file almost never names its’ Associations, thus having many Associations with the same name.

3) The UML 2.1.1 Superstructure XMI file also has multiple associations with the same name. As an example, see the package with id “AuxiliaryConstructs-Templates”. It owns 3 associations with the name “A_templateParameter_parameteredElement” (ids “A_templateParameter_parameteredElement”, “A_templateParameter_parameteredElement.1” and “A_templateParameter_parameteredElement.2”).

Is it intended that multiple Associations with the same name be allowed in a Package or not? If not, then we need to fix Superstructure, MOF, and we can also relax the PackageMerge rule for Associations. If we do allow it, then we should add a new redefinition of “isDistinguishableFrom” for Association that specifies a similar rule to the one described in PackageMerge, that an Association type is distinguishable from another Association if the set of its name and the names of all its member ends is not equal to the corresponding set of the other Association.

A redefine of isDistinguishableFrom for Association is not desired. As such, the PackageMerge rule for Association, which implies the possibility of multiple Associations in a Package with the same name, including if they have no name, provided their member ends differ in some way, is to be amended as it can result in ill-formed merged Packages. This is supported by the following 2 constraints:

1. MOF 2.0 Specification, under section "12.4 EMOF Constraints" there is the following constraint (which would be violated if the Associations have no name):
"[3] Names are required for all Types and Properties (though there is nothing to prevent these names being automatically generated by a tool)."

2. In "9.14.2 Namespace" of the UML 2.1.2 Infrastructure Specification there is the following constraint (which would be violated if the Associations have the same name):
"[1] All the members of a Namespace are distinguishable within it."

As such, explicit rules are also to be added to PackageMerge requiring well-formedness of the merged Package.

The XMI elements cited as examples of clashing Association names are to be renamed.

Regarding UML 2.2 Superstructure

P479L.14 Section "Notation" in 14.3.10 ExecutionOccurences

ExecutionOccurences
~~

No Data Available

Figure 18.2 (which describes the contents of the Profiles package) is currently misleading. On this diagram the majority of the elements have their specializations to infrastructure elements shown (either directly or indirectly). However, Class and Package (which are also infrastructure specializations) do not have their specializations shown. This makes them appear to be the superstructure Class and Package when they aren't (as the diagram is being shown in the context of the superstructure specification). I suggest that you add the missing specializations to make the diagram clearer. Due to the differences between infrastructure Class and superstructure Class, you wouldn't want to confuse them.

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

Say we want to expose a ParameterableElement as a formal template parameter.
If we want to create the following List<E>, then the template parameter would refer to some parameterable element E whose type we would have to choose (say uml:Class).
Now, say we wanted to create List< Interface >, or List < Class >, or List < DataType >. I don't think we would be able to then create TemplateParameterSubstitution for all these elements since the type of formal and actual parameters are inconsistent.

The problem is that we must pick a concrete type for that ParameterableElement - we can't for example use Classifier as the template parameter because it's abstract.

This is a general issue with the way TemplateParameters are handled in the UML abstract syntax, and it would require
a major change in the approach to templates to resolve it in general. However, the specific (and most common) case
mentioned in the issue, that of a template for which it is desired to expose a Classifier as a parameter, is actually
covered by a special case in the specification.
In the UML 2.5 specification, subclause 9.3.3 describes the semantics of ClassifierTemplateParameters, which are
TemplateParameters where the parameteredElement is a Classifier, optionally constrained by a set of constraining-
Classifiers. Toward the end of this section, it says “if the constrainingClassifier property is empty, there are no constraints
on the Classifier that can be used as an argument.” Thus, in defining a template List<E>, it is possible for the
parameteredElement of the formal TemplateParameter E to be a Class, but to still, in a binding for List, substitute for
E with an argument that is any kind of Classifer (including Interface, DataType, etc.).
Disposition: Closed - No Change

The specification of ClassifierTemplateParameter has a flag allowSubstitutable. The definition of ClassifierTemplateParameter::constrainingClassifier says “If the allowSubstitutable attribute is true, then any classifier that is compatible with this constraining classifier can be substituted”. What does “compatible” mean? If we look in Templates::Classifier we find this:

Semantic Variation Points If template parameter constraints apply, then the actual classifier is constrained as follows. If the classifier template parameter:

• has a generalization, then an actual classifier must have generalization with the same general classifier.

• has a substitution, then an actual classifier must have a substitution with the same contract.

• has neither a generalization nor a substitution, then an actual classifier can be any classifier.

If template parameter constraints do not apply, then an actual classifier can be any classifier.

Firstly, the spec for classifier template parameters needs to clarify what compatible means; and this clarification must surely include the possibility that the relationship between the constrainingClassifier and the template parameter can be an InterfaceRealization as well as a Substitution.

Secondly, this text for Semantic Variation Points is weird. Presumably it means that the constraints on substitutability of ClassifierTemplateParameter are a SVP. If so it should say so, and the SVP text should be under ClassifierTemplateParameter.

Finally, it appears that given the existence of Substitution, InterfaceRealization is completely redundant. A good simplification would be to eliminate InterfaceRealization altogether; failing that to make it a subclass of Substitution to clarify that it has contract compatibility semantics.

Most of this issue is obsolete: these semantic variation points have been clarified in the text. Changing the metamodel
as suggested in the final point would be too disruptive.
Disposition: Closed - No Change

The OCL definitions of how Component.provided and Component.required are still invalid, even though they were altered in 2.2. The subexpressions self.implementation and self.realizingClassifier, which appear in both derivations, are not valid: there are no such properties on Component.

It seems that the first "let" clause of each constraint is supposed to do what the second "let" actually does. So we'll delete the first one.

In transitionkind Constraints, the document said: [1] The source state of a transition with transition kind local must be a composite state. [2] The source state of a transition with transition kind external must be a composite state. Does these two constraint means that simple state can not have a outgoing transition?

The cited constraints are not present in the UML 2.5 version of the spec.
Disposition: Closed - No Change

The dependencies in 8.10 should surely point from the Component (the client) to the realizing Classifiers (the suppliers). Also there is a redundant sentence “Alternatively, they may be nested within the component shape” above that figure which is repeated below.

The first part of this issue is wrong (see resolution to 11008 for explanation). The notation for the diagram is wrong which will be fixed by 10651.
The second part is correct.

The Presentation Options section of 9.3.1 seems both inappropriately named and in entirely the wrong place. It is about usage dependencies, constructors and instance specifications and should appear somewhere in chapter 7.

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

In Section 9.3.1 the second paragraph starts “A class acts as the namespace ...”. This semantic about nested classes is part of normal classes and should be moved to 7.3.7.

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 paragraph describing Figure 2.2, the text refers to "four packages". Figure 2.2 contains more than four packages. The corresponding figure in Version 2.0 of the Superstructure displayed four packages; presumably the text wasn't updated along with the figure.

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

The definition of 'isCompatibleWith' for ValueSpecification starts with 'Property::isCompatibleWith[...]', instead it has to start with 'ValueSpecification::isCompatibleWith[...]'.

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

The three formal definitions of 'isCompatibleWith' start with: 'isCompatibleWith = p->oclIsKindOf(self.oclType) and [...]'. This is wrong, p and self have to be swapped, that is: 'isCompatibleWith = self.oclIsKindOf(p.oclType) and [...]'. Rationale: As defined in the OCL-specification formal/06-05-01, the function 'oclIsKindOf(t)' determines if t is either the direct type or one of the supertypes of the object, on which this function is called. That is, if the function returns true, the type t is a generalization or equal to the type of the current object. The corresponding has to be valid for 'isCompatibleWith(p)': If the function returns true, the type of p has to be the same or a generalization of the type of the object, on which this function is called (otherwise, the constraints [1] of 17.5.4 and 17.5.5 would make no sense).

Agreed. (The operations in question are ParameterableElement::isCompatibleWith, ValueSpecification::
isCompatibleWith and Property::isCompatibleWith.)
This also resolves Issue 17870.

For the association 'ownedTemplateSignature' of a Classifier, 'Subsets Element::ownedElement' is specified. This should be replaced by 'Redefines TemplateableElement::ownedTemplateSignature' (because a Classifier inherits 'ownedTemplateSignature' from its superclass TemplateableElement). Correspondingly, in figure 17.18 '

' should be replaced by '

'.

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

There are two occurrences of the term 'templatedElement' in the Standard (both in an OCL-expression), but this term is nowhere defined. I propose to replace 'templatedElement' by 'template' on page 629 respectively 'Template::templatedElement' by 'TemplateSignature::template' on page 636.

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

StructuredActivityNode, based on both common sense and its semantics, requires input and output pins. However StructuredActivityNode::input and StructuredActivityNode::output, both inherited from Action are derived unions and so cannot be used directly. StructuredActivityNode::result is a concrete property but has a special meaning.

What is needed is some solution that subsets StructuredActivityNode::input and StructuredActivityNode::output but can be used to describe input and output pins of StructuredActivityNode.

The semantics of StructuredActivityNode does, indeed, talk specifically about pins on such nodes. Further, having pins on StructuredActivityNodes is assumed as being allowed in and is required by the Java to UML activity model mapping in the Foundational UML specification. The submitter is correct, however, that the abstract syntax model itself does not seem to explicitly support this.

I just noticed that in formal/07-02-05 section 7.3.8, Classifier, includes:

An abstract Classifier can be shown using the keyword

after or below the name of the Classifier.

However this is not listed in Annex B of keywords.

Merged with 18454

Section 13.1.6, figure 13.11 (of Infra) and 18.2.7, figure 18.11 (of Super) show an example of a profile containing Types which are available for use when the profile is applied. This rests on the statement “(since profile application is a kind of import)”. However this is not the case: ProfileApplication only inherits from DirectedRelationship.

To achieve the end effect of the example there seem to be two alternatives:

a) Alter the metamodel to make ProfileApplication inherit from PackageImport, with appropriate redefinitions.

b) Explicitly state that ProfileApplication has exactly the same semantics as PackageImport without inheriting from it. More awkward but lower impact. And will mean that generic processing that works off Imports will not pick up ProfileApplications.

This area is causing significant consternation for groups such as UPDM trying to define sophisticated profiles that make use of common elements or other profiles.

ProfileApplication makes stereotype names visible to the referenced metamodel, not the model the profile is applied to. ProfileApplication is not a kind of PackageImport because of this crossing of metamodel levels. As with package import, profile application does not expose the names of nested profiles. Therefore alternative b) is the appropriate choice.

The UML Superstructure section on profiling (18, 18.3) is vague about the datatype usage in profiles.
In particular, it is not clear what (if any) datatypes can the user define and use in his profile as types of the tags.

--------------------------------------------------------------------------------
Datatypes used in profiles (e.g. as types of the tags) are not ordinary UML datatypes, but MOF datatypes (if I am not mistaken).
Hence it is not obvious if all of the various datatype possibilities, defined in CMOF, can be used by a profile creator.

It would be nice to have some clarifying statement in the Semantics section of the 18.3.6 Profile paragraph
In the same manner as the possible associations between stereotypes is clarified there (page 663, at the bottom):

Stereotypes can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is
owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by
the Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than
the other class/metaclass
(a little side note - I am not sure if this passage is correct - ?metalevel mixing? but this is irrelevant for the issue I am describing)

--------------------------------------------------------------------------------
I can think of the 4 distinct cases of datatypes that the modeler might use in his profile:

#1 Enumerations
#2 New primitive types, narrowing the existing primitive types - String, Integer, Boolean, UnlimitedNatural.
e.g.

#3 Completely new primitive types, e.g. Double
#4 Complex datatypes, defined by the user, composed of fields of primitive types and other complex types.
e.g.

#1 and #2 are the least problematic. #1 is widely supported even in the current crop of modeling tools and
#2 is conceptually simple (handling is the same as existing primitive types + additional constraints)

What I am worried about is #3 and #4.
#3 is problematic; the question arises about how the values of this type are then handled in the model and how they are
serialized into the XMI.
Maybe we could state here that if the tool allows the user to define his own primitive types, then the user is responsible for
extending the tool (through some kind of plugin mechanism) - providing at least the rules of how to serialize such datatypes into the string,
to be written into the XMI.

#4 Is theoretically non problematic (supposedly, it is described how to serialize such complex datatype values - XMI 2.1.2 spec, 07-12-01.pdf, 4.8.7 paragraph).
However I haven't seen live implementations of this. Is the usage of such datatypes in the profile legal?

--------------------------------------------------------------------------------
So, to summarize, we should clarify here, if all of these cases must be supported by the UML tool. Are there any
semantic variation points or compliance levels here?

No Data Available

Version 2.1.1 2007-02-05 of the spec.

TemplateSignature p. 625
parameter : TemplateParameter[] Should mention that it is a derived union of TemplateSignature::ownedParameter ( or show ‘/’ )

ownedParameter: TemplateParameter[] Should mention that it subsets TemplateSignature::parameter.

TemplateParameter p. 623

default : ParameterableElement should mention that it is a derived union of TemplateParameter::ownedDefault ( or show ‘/’ )

parameteredElement::ParameterableElement[] should mention it is a derived union of TemplateParameter::ownedParameteredElement

StructuredClassifier p. 186

There seems to be some discrepency in the spec in regards to Role : ConnectableElement[]. The spec mentions that it is a derived union (it uses the term Abstract union which is inconsistent ) that subsets Classifier::feature. I believe we should have StructuredClassifier::ownedAttribute subsetting StructuredClassifier::role.

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 2.1.1 specification (070205):

Gates are simply MessageEnds and not some form of OccurrenceSpecification. This makes relative ordering of messages between gates on different InteractionUse within an interaction impossible.
In addition to gates on InteractionUse, gates on Interaction that have outgoing messages cannot specify any relative ordering.

The inability to specify ordering of messages connected to gates is problematic.
__________________________________

Add clarification that Gates are messageEnds which are ordered by the occurrences at the opposite ends of
the two messages linked by the gate. UML 2.5 already added several clarification on semantics of Gates.

The semantics of an assembly connector remains unspecified: it is not possible to understand which port is the source and which port is the target of the data that are meant to "flow" at run-time on the assembly. The specification indeed refer to "required port" to express the semantics of a connector, but the concept of "required port" doesn't exist in UML. The real problem is the following: it is not possible to specify which interfaces provided/required by a port are involved in an assembly. A possible solution could be: - Have a port typed to an interface - Specify if the interface is provided or required using a tag (in a way similar for the direction of SysML FlowPort)

I am not sure that this is really a semantics question. If the semantics are in doubt, that is an issue about connectors in general. I believe this is actually the issue about the ball and socket notation, which is resolved by the changes specified in 8168 and 8900, by restricting the notation to parts with simple ports.

Revised Text:
None.

Disposition: Duplicate of 8168 and 8900.

UML2 Activities support two different approaches for exchanging data between actions: "push semantics" of token passing over ObjectFlows and "pull semantics" of typical programming languages using ActionInputPins or ValuePin. The fromAction of an ActionInputPin could be a ValueExpression that references a Variable of the Activity or StructuralFeature of the context Classifier. However, support for pull semantics is incomplete. The first issues is 9247 where there is no ReadParameterAction or WriteParameterAction to support pull semantics for Activity Parameters. These Actions should be provided so that ActivityParameterNodes are only needed for ObjectFlows allowing the Activity Parameters to be directly referenced for pull semantics. This would also allow Parameters, Variables and StructuralFeatures to be all handled the same way.

Despite the misleading title, this issue appears to be essentially a duplicate of issues 9247 and 8470. It looks like the text in this issue was just introductory to that of issue 12162, and was incorrectly made an issue of its own.
Revised Text:
None.
Disposition: Duplicate

In the 2.1.1 specification (070203) states on page 583/732 (or pg.569), it states:
[1] The query isConsistentWith() specifies that a redefining transition is consistent with a redefined transition provided that
the redefining transition has the following relation to the redefined transition: A redefining transition redefines all
properties of the corresponding redefined transition, except the source state and the trigger.

This restriction seems a little harsh. Consider the use case:
1) a user has a state machine, in a top level abstract class, and there exists a transition between two states with no triggers.
2) the users expect to add triggers to the transition in the concrete sub class state machines. (i.e. redefine in the sub class context and add a trigger)

The way the above constraint is written does not allow new triggers to be added to redefined transitions. I am requesting a clarification point that will state that new triggers can be added to the redefined transition.

Merged with 6395

Towards the bottom of the page there is a paragraph on "deferred events". This appears to be a holdover from UML 1.x, as the current specification speaks of "deferred triggers" (see p.550). Adjust this paragraph to match the current abstract syntax. Similar changes must be made to the corresponding paragraph on p.554.

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 description of Lifeline the coveredBy association has a multiplicity of [0..1]. However, in Figure 14.4 the multiplicity is *, in the XMI it has also * as upper bound, and the text talks also about multiple InteractionFragments ("References the InteractionFragments in which this Lifeline takes part").