There are less diagram kinds defined than UML diagrams. In particular I miss a diagram kind for object, deployment and composite structure diagrams
It is unclear what exactly is a path in the context of history pseudo states. For example: "Entry actions of states entered on the path to the state represented by a shallow history are performed." Is it the shortest path? The history path? What happens if the history state isn't the first state after the initial state, but located somewhere in the middle of the statemachine?
The word 'Path' has raised ambiguity with respect to how the history state will restore the active state configuration. There is only one way that the history will restore the active state, and that is through an implicit direct path from the history state to the last active state being reactivated (as though a transition is drawn directly from H to the last active substate). It in no way implies a state-by-state approach. (e.g. a path from the initial state to the last active state)
There are two diagrams on page 164, 'Connectors' and 'The port metaclass'. The two diagrams are the same. Can you send me the picture of this diagram via e-mail? We need it to create a metamodel.
withdrawn, this issue has been resolved
It should be possible to specify multiple constraining classifiers for ClassifierTemplateParameter.
For example, Java programming language allows to specify multiple interfaces as constraining types of template parameter, I see no reasons why UML can't allow several constraining types.
Resolution:
17.5.8
Change multiplicity of "constrainingClassifier" from [0..1] to [0..*].
No Data Available
All rolenames in non-navigable associations in the UML metamodel should be stated, to allow reaching from one element of the association to the other using OCL. Currently, this is limited to un-ambigous type names if the rolename is not stated. For example, in section "9.3.11 Port (from Ports)", Port has required and provided interfaces, and has no rolename on both associations. There is no current way, using OCL, of getting from one Interface to a Port that provides or requires it, as "self.port" is ambigous because it doesn't specify if the programmer is looking for Ports providing or requiring such Interface. The situation repeats in many other associations.
Discussion: It is not required for the specification to name such associations. Navigation is not that hard if this is really desired: find all ports and select the subset that has the appropriate interface. Also, OCL is not constrained by navigability. Discussion: Closed, no change
In UML 2.1.1 L3 metamodel (and the UML 2.1.1 Superstructure spec) EncapsulatedClassifier.ownedPort is declared to be derived. No derivation is provided and it seems unlikely that one was intended. For a list of other properties declared derived for which there is no derivation, see the 2006-12-09 entry here: http://syseng.nist.gov/se-interop/plugfest/tools/changelog
Discussion: This derivation is given: EncapsulatedClassifier.ownedPort is all ownedAttributes that are of type Port. Disposition: Closed, no change
Problem:
The same Classifier could be used only in one template parameter as "constrainingClassifier", it brokes usage of ClassifierTemplateParameters.
Solution:
Change multiplicity of ClassifierTemplateParameter role from "1" to "*" on association between ClassifierTemplateParameter and Classifier in Figure 17.18 - Classifier templates
No Data Available
Section 13.3.31, Trigger indicates the receipt of an event by and active object can either directly cause the occurrence of a behavior, or is delivered to the classifier behavior. This is insufficient. An Event should be able to be handled by any active AcceptEventAction in any thread of control in any running method Activity that is an ownedBehavior of the receiving object. This is how events are commonly handled in business process models and BPEL. It allows an active object to indicate when it is able to accept a call or signal event at a specific point in an already running method activity. If there are more than one such AcceptEventAction, then the AcceptEventAction that handles the event is arbitrary.
No Data Available
TimeEvent has "when" property for time value.
13.3.27 TimeEvent
• when: TimeExpression [1] Specifies the corresponding time deadline.
However in Figure 13.13 - SimpleTime Time Event has association with ValueSpecification.
Model shall correspond to text, so Figure 13.13 shall be fixed.
No Data Available
Problem:
Only one MessageEnd could have the same Message as "message", because of multiplicity [0..1] near MessageEnd on association between Message and MessageEnd in Figure 14.5 - Messages.
Solution:
Change multiplicity [0..1] near MessageEnd on association between Message and MessageEnd to [0..2] in Figure 14.5 - Messages.
No Data Available
nestedClassifier should subset Namespace::ownedMember. There is no ownedMember in Element, i.e. Element::ownedMember is incorrect.
This is a subset of the problem raised in issue 10829 Revised Text: N/A Disposition: Duplicate
Figures 9.4 should show the Port metaclass, but it is identical to Figure 9.3, Connectors
Discussion: Fixed in an earlier release Revised Text: N/A Disposition: Closed, no change
Figure 9.4 duplicates 9.3
Discussion: Fixed in 2.1.2 Revised Text: N/A Disposition: Closed, no change
It should be possible to set the upperBound of a MultiplicityElement to 0 (it's currently forbidden by the constraint [1]). Example : if a class A is associated to a class B with a multiplicity of "0..*" (on the role of B). It should be possible to derive from the class A a class C of which the multiplicity of the role of B is always "0".
No Data Available
Action semantic clarification. In Activities, Action, Semantics, bullet [1], third sentence, after "offered", insert "all necessary".
accepted
StartClassifeirBehaviorAction and classifier behaviors. StartClassifeirBehaviorAction should support passing values to the classifier behavior.
No Data Available
isSingleExecution default. Default of isSingleExecution is in text, but not in metamodel diagram.
This is already resolved in UML 2.1.1 (formal/2007-02-03). Disposition: Closed, no change
Uses notation "Subsets Element::ownedElement" and similar. I believe this should be "Element.ownedElement", as :: is a separator for path. Please check the document throughout.
Discussion: In one of the earlier revisions, the decision was made to use the “::” operator as a qualifier and not the “.” operator. Disposition: Closed, no change
What the time model needs is the concept of an optional time reference that can be attached to a time observation (e.g. to model a spacecraft/ground station situation). The MARTE profile has done some excellent work on this and it should be taken into account when resolving the issue
Resolution: The simple time model is just that: a very simple model to attach time specifications to observations, for example. When a more sophisticated handling of time is required, profiles such as the MARTE profile should be used. The proposal is not to attempt to enhance the simple time model but only fix problems with that model. Disposition: Closed, no change
Join node edge constraint. Join node should have a constraint between the incoming and outgoing flow kinds (control vs data).
Constraint [2] in Section 12.3.34 (JoinNode) of formal/2007-02-03 already says “If a join node has an incoming object flow, it must have an outgoing object flow, otherwise, it must have an outgoing control flow.” Since the intent is to allow a join node to have both incoming control and object flows, it is not clear what other constraint might be needed. Disposition: Closed, no change
Offer ordering on joins. Is the ordering of offers from joins the same as they were offered to the join?
According to the Semantics in Section 12.3.34 (JoinNode) of formal/2007-02-03: “Tokens are offered on the outgoing edge in the same order they were offered to the join.” Disposition: Closed, no change
Multiple activity parameters nodes for a single inout. Can there be multiple activity parameters nodes for a single inout parameter? If not, the node will have both incoming and outgoing edges, which violates constraint [3] of ActivityParameterNode.
There is nothing that prevents a single inout parameter having multiple activity parameter nodes, one with outgoing flows and one with incoming flows. Further, the semantics for activity parameter nodes deals with this case consistently. However, there are actually no limits on the number of activity parameter nodes for a parameter at all, without clear semantics for the general case.
Semantics of fork node wording. The semantics for fork node should say it copies the tokens onto outgoing edges. The wording currently used is the same as initial node and decision node, which do not copy tokens ("offered to all outgoing edges")
The Semantics for ForkNode (formal/2007-02-03, Section 12.3.30) begins: “Tokens arriving at a fork are duplicated across the outgoing edges.” The fact that tokens are duplicated by a fork node is emphasized several times in the subsequent text. Disposition: Closed, no change
ReadLinkAction. In Actions, ReadLinkAction, Semantics, second paragraph, before the fourth sentence (the one starting "The multiplicity of"), add the sentence "The order of the retrieved values in the output pin is the same as the ordering of the values of the links." This aligns with the text added to ReadStructuralFeatureAction and ReadVariableAction by issue 8036 in the UML 2.1 RTF.
accepted
Weight notation. In Activities, ActivityEdge, Notation, Package CompleteActivities subheading, the text in the first paragraph about weight notation is inconsistent with the figure below it.
Correct text as below
Weight description. In Activities, Attribute and Semantics sections, the description of weight in these are not the same. Should be as in the Semantic section.
Fix the Associations and Semantics headings under Section 12.3.5, ActivityEdge
StructuredActivityNode. In Activities, StructuredActivityNode, Semantics, Package CompleteStructuredActivities subheading, first sentence, replace "An object node attached to" with "The contents of an input pin of".
The remainder of the paragraph discusses both input and output pins on structured activity nodes. Both input and output pins are “accessible” within the structured activity node, in the sense that data can flow out of the input pin and into the output pin. Thus, the sentence should refer to all pins, not just input pins.
Semantics of ports needs to be define with regard to interfaces having attributes and associations
Attributes and associations of interfaces do not affect the semantics of ports, and thus, no further definition is required. Disposition: Closed, no change
Could you clarify the semantics of port according to its visibility property, i.e. clarify the following sentence: "A port by default has public visibility. However, a behavior port may be hidden but does not have to be."
The last sentence was added to clarify that a port is not necessarily public, and to highlight that often behavior ports are hidden. However, as the issue submitter points out, that “clarification” is probably more confusing than it is worth. It would be better placed in the description section, but that would require explaining behavior port there. Best to drop.
In Figure 9.4, the role name "required" of the association between Port and Interface is not at the right place.
Resolution: In the current version of the spec, the name is at the correct place. Disposition: Closed, no change
Replace • signal: Signal [1] The signal that is associated with this event. with * ownedAttribute: Property[*] The owned attributes of the signal
No Data Available
Shouldn't be a constraint or a redefinition in order to specify that the client of a manisfestation is its owning artefact?
The requested logic is already provided because artifact subsets owner. Since artifact also subset client, the artifact is
clearly identified as the client. No additional constraints are required.
Disposition: Closed - No Change
Semantics, 2nd paragraph about streaming: "Streaming parameters give an action access to tokens passed from its invoker while the action is executing. Values for streaming parameters may arrive anytime during the execution of the action, not just at the beginning." Since an action represents a single step and is atomic. I think it is not possible that an atomic action comsumes further parameters during execution.
The stated issue presumes that action execution is atomic, which is not necessarily the case, and is certainly not the case for a call action to a behavior with streaming parameters. The whole point of streaming parameters is the semantics given in the quoted sentence, and they would be useless if this was not possible.
However, the quoted sentence is poorly worded, since it is behaviors that have parameters and are invoked, not actions. This may be causing the confusion and should be corrected.
There is an association defined for the Signal metaclass as follows: signal: Signal [1] The signal that is associated with this event. It is unclear what this associaiton is intended to represent. Should this association really be there?
Disucssion: Duplicate of 9576. Disposition: Duplicate
On page 569 in section 15.3.4 (Transitions), constaint # 5 identifies which outgoing transitions, given their source pseudostates, may not have triggers: [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 is incorrect since transitions leaving either a Junction Point, Initial State or a Join should not have triggers. The given OCL specifies the inverse - that only those pseudostates may have triggers. One contradiction to the above OCL exists on page 537 in section 15.3.8 (Pseudostates), constraint #9: [9] The outgoing transition from an initial vertex may have a behavior, but not a trigger or guard. (self.kind = PseudostateKind::initial) implies (self.outgoing.guard->isEmpty() and self.outgoing.trigger->isEmpty()) Furthermore, transitions leaving a fork are also not allowed triggers (constraint #1), so this could also be contained in the transition's OCL constraint (#5). Therefore the OCL for constraint #5 should be written as: [5] Transitions outgoing pseudostates may not have a trigger. source.oclIsKindOf(Pseudostate) and ((source.kind = #junction) or (source.kind = #join) or (source.kind = #initial) or (source.kind = #fork)) implies trigger->isEmpty()
Text has already been fixed in the UML 2.2 specification to be
[5] Transitions outgoing pseudostates may not have a trigger (except for those coming out of the initial pseudostate).
(source.oclIsKindOf(Pseudostate) and
(source.kind <> #initial)) implies trigger->isEmpty()
which resolves the above issue
Revised Text:
N/A
Disposition: ClosedNoChange
State.stateInvariant should subset ownedRule The stateInvariant property of State currently subsets Element.ownedElement. Given that a State is a Namespace and a stateInvariant is a Constraint, the stateInvariant property of State should subset ownedRule. Likewise, the opposite end of this association should subset Constraint.context instead of Element.owner. This change is needed so that a state invariant has a context and, thus, can be specified using OCL.
No Data Available
It is common usage to model a lifeline in a interaction that represents an actor. I can't see how that could be done formally correct. A lifeline represents a connectable element, e.g. a property. It is not allowed to define a property that is typed by an actor.
No Data Available
It is unclear if it is allowed to show the provided and required interfaces of a port in a composite structure diagram (ball and socket notation). That notation is already used for example in SysML. However I can't find the definition of it.
Ball and socket notation is only allowed for Components.
Revised Text:
Disposition: Closed, no change.
The notation section of the classifier refers to the standard notation for nested classifiers. 1. I can't find that standard notation in the spec. 2. Nested classifiers are a feature of classes and not of classifiers. It seems that nesting and owning of classifiers is mixed up here
No Data Available
isReentrant should default to true
Having isReentrant default to false, as it currently does, means that, by default, there can be no concurrent invocations of a behavior, nor can a behavior be recursive. This does not seem to be the normal expectation of modelers when they model the invocation of behavior. Rather, the expected default it that behaviors are reentrant-with the ability to declare them not to be if that makes sense.
On the other hand, it is often the case that, within an activity modeling, for example, a business or manufacturing process, an action invoking a behavior may be locally non-reentrant, in the sense that one invocation must complete before a new one can begin, because there is only a single performer to carry out the action. However, this case is more specifically addressed by Issue 6111. Once this is resolved at the local level, the default for the "global" isReentrant property on Behavior can be allowed to default to true, while "local" reentrancy for actions defaults to false.
Actions on non-unique properties with location specified. Clarify what happens in the actions applying to non-unique features / association ends when they specify location and an existing value (eg, RemoveStructuralFeature and Destroy actions) if the value to be acted on is not at the position specified.
Currently, the WriteStructuralFeatureAction and WriteVariableAction superclasses specify a required value input pin, so all kinds of write structural feature actions must have such a pin in all cases. However, when a removeAt pin is required for a RemoveStructuralFeatureValueAction or RemoveVariableValueAction (that is, when the feature or variable is ordered and non-unique and isRemoveDuplicates is false), the expectation is that whatever value is at the given position is removed. Having to provide any value at all is counterintuitive. If the value is ignored, then it is pointless. If the value has to be the same as the value at the given position, then it is extremely inconvenient and redundant to have to read the value at that position just to remove it!
Therefore, the remove value actions should not have a value input pin in the case they are required to have a removeAt pin. This means that the value input pin should be optional in the write action superclasses, but should then be constrained to be required for the add value actions.
Output of read actions for no values. In the various read actions (links, structural features, variables), what is the output when there are no values read? Is it a null token or no tokens at all?
Suppose the result output pin of a read action is connected by an object flow to an action with an input pin with a multiplicity lower bound of zero. Assuming the second action has no other inputs or incoming control flows, it still will not fire unless it receives some token on its input pin (note that this semantic interpretation of enabled actions is explicit in the Foundational UML specification). Thus, if the read action produces no token in the case that no values are read, then the second action will not fire, even though its input is optional. In order to ensure that the second action can actually fire with no input values, it would be necessary to also model an explicit control flow from the read action to the second action, which is inconvenient and can lead to ordering and sequencing issues between control and object tokens in the case when the read action does produce values.
On the other hand, if the read action produces a null token when no values are read, then this will be offered to the second action, which can accept it, since its input multiplicity allows the case of no values. The second action will thus fire with an empty input, as would be intuitively expected. Note that if the second action's input pin had a multiplicity lower bound greater than zero, the semantics would not be effected by the offering of a null token, since this still would not provide the minimum number of values required for the action to fire.
Therefore, in the framework of the token offer semantics of activities, it makes the most sense for a read action to produce a null token when there are no values to read. Note that this is also consistent with the semantics for call actions implied by the statement in Subclause 12.3.41 that if, at the time an activity finishes execution, "some output parameter nodes are emptyÂ…they are assigned null tokens", in which case one would expect the null tokens to be offered by the corresponding output pins of a call action for the activity. That is, call actions should also offer null tokens in the case that an output has no values.
InputPin semantics wording. In Actions, InputPin, Semantic, second sentence, replace "how many values" with "the maximum number of values that can be".
accepted
Output pin semantics clarification. The current semantics for Action says it won't complete without the output pins having the minimum number of tokens, as specified by the minimum multiplicity. It should be clarified that the output values are not put in the output pins until it the action completes, so the tokens already in the output pins are not included in meeting the minimum multiplicity.
agreed
ForkNode semantics wording. In semantics of ForkNode, the phrase "keep their copy in an implicit FIFO queue until it can be accepted by the target" should not be different from other situations of ordered offers to refusing targets. In particular, it should be refined to clarify that the acceptance of offers by a fork is the same as acceptance by object nodes in the sense that they can't be revoked once accepted, and that for the edges leading to refusing targets, the offers are standing along those edges in the order they were received.
In general, the ForkNode semantics needs to be more carefully worded in terms of offers of tokens, rather than just the tokens themselves "arriving" at a fork node.
Preserving order of multiple tokens offered. In Activities, ActivityEdge, when tokens are offered in groups, for example for weight greater than 1, if the source and target are pins, the multiplicity ordering of the source node, if any, should be preserved in the target node.
The real issue is preserving the ordering of offers as made by the source, whether the source is a pin or not. The relationship of multiplicity ordering on pins to the ordering of offers is handled by the resolution to Issue 9860.
Figur 12.95 - Fork node example has an error. Instead of: |-> Fill Order Fill Order -->| |> Send Invoice It should be: |> Ship Order Fill Order -->| |-> Send Invoice
agreed
Missing constraint for template binding in classifier context There seems to be an omitted constraint for template binding in the context of the classifier metaclass on page 667. Indeed, there is no restriction to the kind of template element to which a classifier can be bound. For example, nothing forbids a class to be bound to a data type or association or even an operation defined as template. There is a need for a constraint similar to the one defined on page 57, where it is stated that a classifier can only specialize classifiers of a valid type. Something like, self.templateBinding -> forAll(tb | self.oclIsKindOf(tb.signature.template.oclType)) Note that the variable oclType is not a valid OCL expression, even though it is referenced more than once in the UML Superstructure document (e.g definition of maySpecializeType on page 58). We therefore here assume that the oclType expression returns the associated metatype of the uml element to which it is applied. Thanks in advance for any feedback Jean-Frédéric Etienne
This is covered in constraint [1] of TemplateParameterSubstitution, section 17.5.5.
Revised Text:
Disposition: Closed, no Change
Is "Set of <name>" a keyword? Or is it allowed to write for example "<name>List" or "<name>Container"?
This issue applies to Figure 15.49 in Subclause 15.4.4 of the UML 2.5 beta specification. Since ObjectNodes
are not MultiplicityElements, the only way that an ObjectNode can contain a set or other collection is if its
type is a collection type. Since UML does not provide any standard such types, the notation cannot be fully
standardized
Execution semantics of deferrable triggers. The execution semantics of deferrable triggers in the notation section of Transition, under Figure 15.44, conflicts with the semantics given in State. The description of deferrable trigger in the State attribute and semantics sections say a deferred event remains deferred until the machine reaches a state where it is consumed. The notation section of Trigger says the deferred event is lost when the machine reaches a state where the event is not consumed and not deferred
No Data Available
The description how values of a stereotyped element can be shown offers three ways. But all of them requires a graphical node. There is no description how to show the values of a stereotyped element that has no graphical notation, e.g. an attribute
Resolution: Duplicate of 9877
Fig. 8.12 shows delegate connectors that are directly connected with an interface. According to the metamodell that's not possible. A connector end can only be connected with connectable elements.
Resolution:
Resolved by the changes specified in 8168.
Revised Text:
None.
Disposition: Duplicate of 8168.
In the defintion of the Property concept, the type of the default attribute is a String. I believe it would be more powerful to type default with ValueSpecification
Actually, Property::defaultValue is a ValueSpecification, which gives what is required. Property::/default is
a derived string, although its current documentation—“A String that is evaluated to give a default value for
the Property when an instance of the owning Classifier is instantiated” — is misleading. Property::/default
only exists at all because of earlier efforts to align superstructure and infrastructure through package merge.
Its derivation makes no sense for default values that are not strings. Since it is derived, removing it would
not affect model serialization. Delete it.
The section 7 contains two concepts, ElementImport and PackageImport, that seems to quite redundant. I believe that the semantics of ElementImport covers the semantics of PackageImport. SO, either clarify the difference (if there are?), or delete the PackageImport or make PackageImport a specialization of ElementImport.
No Data Available
Figure 7.47 - Power type notation Specific classifier-2 has powertype 'classifier-1' but inherits from PowerType Classifier-2. Should the inheritance lines not point to the 'General Classifier'?
No Data Available
Inconsistancy between background fill colouring. Default colour preferences are normally white background, black text, and this issue is then not visible. Changing to a custom colouring to green backgrond, black text, one sees that that some boxes are filled white, whereas others are the same as the selected background colour. Is this intentional? Does this have any semantic meaning? Example in Figure 7.47 (b) Power type notation. The PowerType classifiers use the page background
No Data Available
In the Notation part of CombinedFragment, in the part 'Presentation Options for “coregion area"' the text refers to Figure 14.12 for an example of a coregion. However, on Figure 14.12 there is no coregion. The reference should be changed to Figure 14.22
No Data Available
The body property of OpaqueBehavior (as well as OpaqueExpression and OpaqueAction) should be declared not unique. The OpaqueBehavior can be used to store user code and the given language that it was written in. The specifiction identifies the lists of languages and bodies to be ordered (and by default unique). It makes sense for the list of languages to be uniuqe, but not the bodies. For example, consider the user has written the same code but in 2 different languages (say c and c+, or written an identical comment in c and c+ and java). Currently the UML specification disallows one to have the same body even though it may semantically make sense in both languages
Agreed. In addition, the body and language attributes should be ordered
Use of only the link name as the default for the association name limits the use of both namespace::membersAreDistinguishable() and nameElement::isDistinguishableFrom() operations. The full association name for creating the signature of the element should be at least the concatenation of "memberEndA name - link name - memberEndB name".
No Data Available
Language unit for stereotype create should be named Classes::Dependencies instead of just Dependencies
No Data Available
Context of the Constraint is described as derived property
• / context: Namespace [0..1] Specifies the Namespace that is the context for evaluating this constraint. Subsets NamedElement::namespace.
However it is not derived in Figure 7.7 - Constraints diagram of the Kernel package.
So should it be derived or not? One of these places shall be fixed.
See issue 10830 for disposition
In the first serialization example, the memberEnd refers to property 'id4' and 'id5'. This would lead to 2 inconsistencies: 1. the 'id7' is in ownedEnd, but not in memberEnd. This contradicts the subset defined in chapter 7.3.3. 2. there are two candidates for the derived 'metaclass' attribute of 'Extension': id4.type and id5.type. This contradicts the definition in chapter 18.3.2. Instead it should refer to id7 and id5. The correct XMI file excerpt looks like that: <ownedMember xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home" memberEnd="id7 id5"> <ownedEnd xmi:type="uml:ExtensionEnd" xmi:id="id7" name="extension_Home" type="id3" isComposite="true" lower="0" upper="1"> </ownedEnd> </ownedMember>
No Data Available
Figure 7.15 - Contents of Dependencies package There is a rolename supplierDependency that it not defined in §7.3.33 for NamedElement.
supplierDependency is a non-navigable end and, therefore, cannot be owned by NamedElement. Per the usual style in the UML specification document, non-owned ends are not listed in the documentation for a class.
Revised Text:
None.
Disposition: Closed No Change
As described above the Figure 7.38 I think the arrow should point from Car to CarFactory.
In the UML 2.5 specification, the corresponding figure is 7.19 in subclause 7.7.5. The direction of the
dependency in the diagram is correct: the CarFactory instantiates Cars and so depends on the Car class, but
the Car class does not need to depend on CarFactory specifically instantiating it.
However, the text above the diagram says “the Car Class has a Dependency on the CarFactory Class”, which
is incorrect.
This also resolves duplicate issues 12405, 13136, 13947 and 17804.
Incorrect word renders sentence meaningless: Chap. 12.3.41, "Parameter (from CompleteActivities)" Section "Semantics", 1st paragraph, Beginning of last sentence: Suggestion: Replace: "Arrange for separate executions of the activity to use separate executions of the activity..." by: "Arrange for separate invocations of the activity to use separate executions of the activity..."
agreed
The section titled "Changes from previous UML" is not complete "The following changes from UML 1.x have been made: to be written."
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 constraint for CombinedFragment:
“[1] If the interactionOperator is opt, loop, break, or neg, there must be exactly one operand.” ..
should also include the assert operator.
No Data Available
Figures 12.25-27 show examples of the AcceptEventAction. The actions have an outpin pin which can be omitted in the diagram. But the target actions should show the input pins, e.g. action "Cancel order" needs an input pin "Cancel order request".
The referenced diagrams are correct as drawn when the edges are interpreted as control flows rather than data flows.
Revised Text:
None
Disposition: Closed, no change
RedefinableTemplateSignature::classifier owns this template signature, so it shall redefine inherited TemplateSignature::template, because it is used for the same purpose and subsets Element::owner.
No Data Available
Element is restricted to be imported only once (not possible to import the same element into different namespaces).
I think this is clear bug in Figure 7.4 - Namespaces diagram of the Kernel package
ElementImport multiplicity (on association between ElementImport and PackageableElement) shall be changed from [1] to [*] (as multiplicity of PackageImport).
This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change
This seems odd to me. The ‘owningPackage’ role of PackageableElement is non-navigable, whereas I would expect it to be navigable so that it is possible from a Packageable Element to find its owner. Interestingly Type, which is a PackageableElement does have a navigable role to its parent, but InstanceSpecification, for example doesn’t.
No Data Available
The property isLeaf as inherited by Class from RedefinableElement deals with the concept of redefinition in the context of a classifier. The concept of "this class cannot be subclassed" is missing from UML 2.0 and the current version of UML 2.1. In UML 1.4, the isLeaf property is present in two contexts: Operation and GeneralizableElement. The former refers to the concept of redefinition while the later refers to the concept of subclassing. In UML 2.1, isLeaf from RedefinableElement corresponds to the former. There is nothing corressponding to the later. It is clear from the UML 2.1 specification that redefinition of Classes is related to nesting. In the association class->nestedClassifier between Class and Classifier in Figure 7.12, the source end subsets redefinitionContext. The current constraints for RedefinableElement, Classifier and Class give the following interpretation. Let A be a class with nested class A1, B a class with nested class B1, and B be a subclass of A. Then B1 can redefine A1 as long as A1 has isLeaf = false and A1's visibility is not private. B1 can subclass A1 regardless of the the value of isLeaf on A1. In short, subclassing and redefinition are two separate, orthogonal concepts. The concept of isLeaf for subclassing is not present in UML 2.1.
In UML 1.5, isLeaf is used in 3 contexts, not two:
UML 1.5's Operation::isLeaf and Reception::isLeaf in UML 2 correspond to the concept of a redefinable element that cannot be further redefined.
UML 1.5's GeneralizableElement::isLeaf in UML 2 corresponds to the concept of a classifier that cannot be further specialized in a generalization hierarchy. There are several options to add this capability in UML 2 and the two that are least disruptive to the UML 2 specification are:
a) Rename RedefinableElement::isLeaf to RedefinableElement::isFinal
Add Classifier::isLeaf
b) Keep RedefinableElement::isLeaf
Add Classifier::isFinal
c) Keep RedefinableElement::isLeaf
Add Classifier::isFinalSpecialization
Option (a) would break compatibility with UML 2.2 in a really bad way because the original meaning of "isLeaf" is now "isFinal" and there is a completely different meaning assigned to "isLeaf".
Option (b) preserves the UML 2 meaning of "isLeaf" but adds support for the UML 1.x notion of a classifier that cannot be specialized in a generalization hierarchy. However, option (b) creates possible confusion for end users in distinguishing the purpose of isLeaf vs. isFinal.
Option (c) provides the same advantages as option (b) in addition to providing end users a clue about the role of isLeaf vs. isFinalSpecialization.
Since option (b,c) represent an upwardly compatible change w.r.t. UML2.2, it is preferred to option (a) which would not only break compatibility with UML 2.2 but also create a lot of confusion in comparing UML 2.2 vs. UML 2.3 models. The rest of this resolution follows option (c).
Add a property 'isFinalSpecialization' to a Classifier which is the basis for expressing taxonomic relationships among general and specific classifiers.
Specify a package merge transformation for merging Classifier::isFinalSpecialization according to the principle that a resulting classifier is final if either matching classifier is final.
The description of Constraint mentions the xor-association that is predefined in UML. There's no place in the superstructure (and infrastructure) where that constraint is defined.
Figure 7.34 shows an
{xor} constraint attached to two associations, indicating an Account can be a property of Person or Corporation, but not at the same time. Section 7.3.10 Constraint references “xor” constraint as an example of a UML predefined constraint.
The xor constraint is not explicitly defined in UML. Rather it is used as an example of a constraint between associations as in figure 7.34, and as an example of an expression in section 7.3.18. So the parenthetical remark about xor being an example of a UML predefined constraint in section 7.3.10 should be removed.
Table 8.2 must be named "Graphic paths..." instead of "Graphic nodes..."
This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change
Table 8.2 should contain graphic paths for - delegate connector - component realization
Table 8.2 shows the assembly connector which is an element of a composite structure diagram. But table 8.2 denotes elements of a structure diagram. A table for composite structure diagram elements that are specific for components is missing.
The heading of table 8.2 is incorrect. The table doesn't show nodes, but paths.
The constraint [2] in section 12.3.5 on page 325 ("Activity edges may be owned only by activities or groups") of class ActivityEdge seems to be contrary to the fact that inGroup - the only reference between edge and group - is a simple association but no composition or aggregation. According to figures 12.5 and 12.6 I would think, that edges are always owned by activities (composition) and referenced by groups. There is no composition or aggregation that specifies, that edges can be owned by groups. (http://groups.google.de/group/UMLforum/browse_thread/thread/bdd07d113676a41f/20b33a18f90db3d9?#20b33a18f90db3d9
This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change
In fig. 8.12 on page 153 the delegate connector points directly to an interface or from an interface on the right side. According to the connector definition in 9.3.6 and 8.3.2 it is not allowed to do that. In addition such a notational variant is nowhere described.
This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification.
Disposition: Closed - No Change
Typo in paragraph Presentation options on page 385: insert blank between "12.85" and "maps".
This seems to have already been corrected in UML 2.2 as an editorial change.
Revised Text:
None
Disposition: Closed, no change
Specify constraint that a expansion node can have a regionAsInput and a regionAsOutput, but not both at the same time.
agreed
visibility default value cannot be false
See issue 10831 for disposition
Semantics, rule [2] "If multiple control tokens are available on a single edge, they are all consumed." How does this rule fit to the rule that the default weight of an edge is 1. If multiple control tokens are available only one of them can traverse the edge to the target node
No Data Available
Pin ordering semantics. In Activities, InputPin, OutputPin, the semantics of ordering inherited from ObjectNode should be related to multiplicity ordering inherited from MultiplicityElement. For example, if an output pin of ReadStructuralFeatureAction has an object node ordering of FIFO, and the structural feature is ordered (which means the multiplicity ordering of the pin is also), then perhaps the multiple values posted by a single execution of the action should be drawn from the pin in the same order as in the structural feature. Since the action will post the values to the output pin at the same time, currently FIFO ordering on the pin will be indeterminant
Add text below.
Default weight. In Activities, ActivityEdge, Assocations, the default weight should be unlimited 
. For example, a ReadStructuralFeatureAction of a mult-valued attribute might produce multiple tokens, which flow to the input of an AddStructuralFeatureAction. Do not want the values to be input to separate executions of AddStructuralFeatureAction
The spec says weight determines the minimum number of tokens that must traverse the edge (offers accepted by target) at the same time. And it requires any tokens offered above the minimum to be taken at the same time:
When the minimum number of tokens are offered, all the tokens at the source are offered to the target all at once.
So the default can remain 1 for the example.
Revised Text:
None.
Disposition: Closed No Change
In UML2, it is possible to describe user defined datatypes and propertis may typed by this typed. But, nothing has been defined in the UML2 specifcation to be abble to describe values (of slots for example) which has to be conform to a datatype. One could add a new metaclass (for example, DataTypeValueSpecification inheriting from ValueSpecification) in the Expression package to be abble to denote datatype values. And to define the underlying notation.
Merged with 15248
Section Associations of ActivityNode: /inGroup:Group[0..*] Groups containing the node. should be /inGroup:ActivityGroup[0..*] Activity groups containing the node.
agreed
If there are multiple enabled internal transitions within the active state, should they all be fired? The standard suggests that they should all be fired, but is this done in practice? For example, consider the case of two internal transitions within the same state, triggered by the same event, with no guard condition. If that event occurs, will both transitions fire?
Merged with 9840
What happens if a control value from a control operator stops the following action and there are no more tokens left and no actions are active? Does this terminates the execution of the activity? What if the control value suspends the action? Who can resume the action? There are no more tokens and running actions.
No Data Available
The Description section states: "Note that the included use case is not optional, and is always required for the including use case to execute correctly." This is often understood as stating that the behavior of an included use case has to be executed during every execution of the behavior of the including use case. Example: The following informal use case fragment contains a conditional call of an included use case: Step x: If the user choses to print the reports, <<include>> the use case "Print reports". With the understanding given above, this use case fragment would be invalid (at least if the included use case is not included elsewhere in the including use case). In a similar vein, the Semantics section states: "All of the behavior of the included use case is executed at a single location in the included use case before execution of the including use case is resumed." Besides the obvious error (the sentence should say: "... is executed at a single location in the including use case ..."), this is sometimes understood as stating that the behavior of the included use case must be executed exactly once during the execution of the including use case. Another (equally wrong) interpretation would be that the included use case must be included exactly once in the use case specification (implying, for example, that there must not be two lines in the same textual use case specification containing an <<include>> directive for a certain use case). Both sections should be clarified, clearly stating that: - The behavior specification of the including use case may include an included use case multiply (although this is represented by a single include relationship in the use case diagram). Analogy: A routine that contains multiple calls to a subroutine in its source code. - The including use case is responsible for calling the included use case. It may choose to call it once, repeatedly, or not at all. Analogy: A routine with conditional execution paths or iterative behavior, performing subroutine calls conditionally or iteratively. Proposal for changing the sentence in the Description section: "Note that the included use case is not optional, and is always required for the including use case to be fully specified. The behavior specification of the including use case may include an included use case multiply (although this is represented by a single include relationship in the use case diagram)." Proposal for a change and an addition in the Semantics section: "All of the behavior of the included use case is executed in the including use case before execution of the including use case is resumed. Depending on behavior of the including use case, the included use case may be called once, multiple times or not at all." I would be very pleased to receive a first, quick reply by mail.
Figure 7.48 and the accompanying discussion under 7.3.21 GeneralizationSet>Examples on pp 78-79 uses the example of a generalization set consisting of a single class to explain the proper use of the isCovering and isDisjoint attributes. I believe this example is infelicitous in the context of this exposition because generalization sets consisting of a single class present a special case, and this detracts from the exposition. In what way are they a special case? IF (a generalization set consists of a single class AND it is
{incomplete}) THEN it can only be {disjoint}. This is because if the complement of an {incomplete}generalization set is non-empty, and consists of all instances that are NOT members of the solitary class in the generalization set. In other words, for a generalization set consisting of a single class, the combination
{incomplete, overlapping}is self-contradictory. IF (a generalization set consists of a single class AND it is
{complete}) THEN it can only be {overlapping}. This is because the complement of a {complete}generalization set is the null set, and the null set is a member of every set. In other words, the combination
{complete, disjoint}is self-contradictory. I would recommend pointing out that generalization sets consisting of a single class represent a special case, and I would treat them separately (?footnote). For purposes of the exposition, I would modify Figure 7.48 to include at least two classes (perhaps Employee, Manager) instead of just Employee in the right-hand generalization set.
The type of association 'packageMerge' is shown as 'Package'. In contradiction to this is the describing text of this association and the Figure 7.14 on p. 34 showing that the association 'packageMerge' is from 'Package' to 'PackageMerge'. Correct in chapter '7.3.37 Package (from Kernel)' the type of association 'packageMerge' from 'Package' to 'PackageMerge'.
Some of the concepts defined in the Interaction chapter (n 14), as for example BehaviorExecutionSpecification, are more general than Interaction and shoul dbe part of the chpater 13 which concern is behavior in general. I suggest to review the chapter 14 in order to extract from this section all the concept that are generic w.r.t. behavior and to put them in the chapter 13.
The direction of deployment dependency is wrong in all figures that use this kind of dependency, e.g. figure 10.9 on page 216 (direction is opposite to the one stated in metamodel). The deployment dependency in these figures is being drawn from artifact (client) to target (suplier), though figure 10.4 on page 210 defines Deployment as being dependency with DeploymentTarget as client and DeployedArtifact as supplier, so direction should be opposite - from target to artifact. As an alternative, the metamodel could be adjusted.
Table 14.6., State or condition timeline: It is unclear how the time information is stored in the interaction model. Especially if it is a continuous timeline. Please clarify the repository model for timing diagrams
The abbreviation sd for interaction diagrams should be renamed to id. sd stands for sequence diagram, but there three more interaction diagrams. It is confusing to have a diagram kind sd for a timing diagram.
Using a simple Dependency to define the role bindings of a CollaborationUse seems too "light". I suggest to change for a Realization relationship which has a stronger - and i think more convenient - semantic.
There are 3 kinds (TransitionKind) of transitions: internal, external and local. Are there firing priorities between these? For example, consider the case of an internal transition within a state and an external transition with same state as its source state, triggered by the same event, with no guard conditions. If that event occurs, which transition(s) will fire? The standard states, "An internal transition in a state conflicts only with transitions that cause an exit from that state," but neither the firing priorities nor the transition selection algorithm define how such a conflict should be resolved.
I believe it would be interesting formodelling to be abble to add a feature to the coenpt of NamedElement in order to be abble to define a short name (e.g. an acronym). I propose to add the property: - shortName: String [0..1] the abreviation or acronym assocatied to the NamedElement