The line

"[<visibility>] <name> ‘(‘ [<parameter-list>] ‘)’ [‘:’ [<return-type>] [‘[‘ <multiplicity> ‘]’] [‘

’]]"

has its terms defined under the bulleted list after the first un-indented "where", except for "<parameter-list>".

That term is defined one level too deep, where "<oper-property>" terms are defined.

The bullet found there (i.e., "<parameter-list> is a list of Parameters of the Operation in the following format:") should become the third bullet in the first level of bullets.

In section 17.2.1 InformationFlow (from InformationFlows) page 621, the first constraint states that "The sources and targets of the information flow can only be one of the following kind: Actor, Node, UseCase, Artifact,
Class, Component, Port, Property, Interface, Package, ActivityNode, ActivityPartition and InstanceSpecification except
when its classifier is a relationship (i.e., it represents a link).". Why can't an Activity be the source or target of an InformationFlow, since it is a Behavior as an Use Case?

duplicate, issue closed

Throughout the specification, output parametersets are described as if all (non-optional) output parameters within the set are output. This is not exactly right if the parameterset contains an exception. Please describe how that works and make the document consistent

duplicate of 17927, withdrawn and closed

To put it simply, I'm saying this:

The spec should clearly state that an instance spec is a legitimate value
of a property typed by a classifier.
The spec should make sure that the abstract syntax operations &
constraints involving all kinds of UML classifiers & instance
specifications work according to the above.

The UML spec tacitly agrees with this as shown in several examples:

Figure 7.54 in UML 2.4.1, page 82.
Figures 9.31, 9.32, 9.33 in UML Simplification Revised August draft, p. 143

A legitimate value of a property (actually a Slot) is an InstanceValue, which is what is depicted by figures 9.32 and
9.33.
Disposition: Closed - No Change

In the section diagram is specified that a Comment is a specialization of Element but in the definition of Comment says that Comment have no Generalizations

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

I've encountered one slight problem in the superstructure XMI file of UML2.4.1 .

I've grabbed the ptc/2010-11-18 revision of Superstructure.xmi from here:
http://www.omg.org/spec/UML/2.4.1/

On examining I see that all enumeration literals contain classifier="..." field serialized; e.g.:
> <ownedLiteral xmi:type="uml:EnumerationLiteral"
> xmi:id="Activities-CompleteActivities-ObjectNodeOrderingKind-unordered" name="unordered"
> classifier="Activities-CompleteActivities-ObjectNodeOrderingKind">
There are ~62 such places in Superstructure.xmi (I've not looked into Infrastructure.xmi, but I
think there will also be cases like this)

Classifier metaproperty of EnumerationLiteral metaclass is derived in UML2.4.1 - per Figure 7.13 and
chapter 7.3.17
(EnumerationLiteral::classifier redefines the original InstanceSpecification::classifier, which is
not derived).

Since derived fields are not usually serialized by XMI production rules (unless this is overridden,
which seems not to be the case),
I think these fields should be cleaned out.

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" section, it stated that "Attributes of a class are represented by instances of Property that are owned by the class".
Expected:
"Attributes of a class are represented by Properties that are owned by the class".

In page 43: it is stated that "an association end owned by a class is also an attribute".

In page 36, memberEnd: Property[2..*] indicated that association end is Property.

In all, I think Attribute is Property, only if the Property is owned by a class.
It is confusing to mention instance in this context.

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

The operation "isConsistentWith" is not overridden for any RedefinableElement in this chapter. Hence the contraint expression "A redefining element must be consistent with each redefined element." (from RedefinableElement) evaluates to false for any instance.

Please add an operation for ObjectNode at least.

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

wonder about the arrows used in communication diagramms (superstructure
spec, Page 524).
Do they indicate the type of message - as it is with sequence diagramms
(sync, async) - or do they indicate the direction of message only.
I didn't find a statement in the superstructure spec and several UML related
books offered different oppinions.

Communication diagram can have replies shown, because it can represent any message. There is only the solid arrow
style in communication diagrams.
Disposition: Closed - No Change

An Actor doesn't have an attribute named "ownedAttribute".

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

Figure 12.15 (on page 370) shows a DataStoreNode (which is a subclass of CentralBufferNode) that is conntected to an action ("Assign Employee").
But in the description of CentralBufferNode (p. 361) it says: "They do not connect directly to actions".

This issue is obsolete. The description of CentralBufferNode in UML 2.5 no longer contains the sentence “They do
not connect directly to actions.” (This sentence was intended to mean that ContralBufferNodes are not composed with
Actions the way Pins are, not that they could not be connected by flows to Actions. But it was admittedly confusing.)
Disposition: Closed - No Change

This sentence is apparently missing words:
"through
interactions in the form of <?????> (e.g., sequence diagrams or similar notations)"

This is now clause 17.1.1 of UML 2.5. Change “through interactions in the form of (e.g., sequence diagrams
or similar notations).” to “through interactions in the form of sequence diagrams or similar notations

The UML spec says: "The value of firstEvent[i] is related to event[i]"

So the "event" feature of DurationObservation should be ordered since the order is significant: we need to refer to it by index.

Agreed. While this is a metamodel change, it is necessary for the semantics to make sense.

You wrote "lifeline: LifeLine[0..*]" at page 495 but you should write "lifeline: Lifeline[0..*]".
The "L" must be in lowercase because it is the correct name of the class that represents a lifeline (as you can see at the 14.3.17 section and in the class diagram at page 475).

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

The Superstructure 2.3 mentions (15.3.14, page 573) a constraint for transitions:

“Transitions outgoing pseudo states may not have a trigger (except for those coming out of the initial pseudo state).”

I think this constraint is too limiting.

First of all, it is not observed even in the specification:

On page 546 it says about state lists (15.3.9, page 546):

“Multiple trigger-free and effect-free transitions originating on a set of states and targeting a junction vertex with a single

outgoing transition may be presented as a state symbol with a list of the state names and an outgoing transition symbol

corresponding to the outgoing transition from the junction.”

Conclusion:

1) the transition from each of the states in the list cannot have a trigger

2) the constraint says, that the transition from a junction vertex also cannot have a trigger

==> the transitions out of state lists cannot have triggers

However In figure 15.27 and 15.28 such triggers are shown (e, f, logCard, logVerify).

Second and more importantly, the described situation of “multiple transitions originating on a set of states and targeting a junction vertex” is quite common and therefore should be allowed, whether or not the modeler wants to use state lists.

Suggestion

Transitions from junction vertexes should be an exception to the constraint above. So the constraint on transitions needs to be reformulated:

Page 573: “Transitions outgoing pseudo states may not have a trigger (except for those coming out of the initial or of junction pseudo states).”

Then another constraint needs to be added

Page 573: “The outgoing transitions of a junction pseudo state may have triggers only, when the incoming transitions originate from states and don’t have triggers.”

Adding triggers to transitions emanating from junction points would contradict the fundamental run-to-completion
semantics of UML. This would require the execution of a compound transition chain, which is executed in a single
run-to-completion step by definition, to stop in “mid-stream” at the junction pseudostate to await the arrival of new
events.
There is nothing in UML preventing transitions emanating from different source states to converge on a common join
point (that is what junction points are for), which I think is the capability that the submitter is really asking for. It
is indeed a very common situation. These transitions may have different triggers or, quite often the same trigger.
In the latter case, AND ONLY IN THAT CASE, it is possible to use the state-list notation. However, in that case,
the common trigger is used for the originating “transition” that goes to the common junction point (“transition” is in
quotes here, because it is really just a notational shortcut for the multiple transitions that share the same trigger but
originate from different states). From there onwards, it is possible to have different outgoing transitions with different
guards (but not different triggers) and different effect behaviors.
Note that neither figure 15.27 nor figure 15.28 are examples of the case where a common junction point is the target
of the “transition” originating from a state list (instead, they terminate on a State).
Disposition: Closed - No Change

My previous submission has been resolved. Apparently, the UML spec provides an exception clause in the definition of the /context field to allow the context classifier to propagate downward to sub state machines. I do not know how to find and close the original issue so I'm mentioning it here.

That said, the semantic issue I raise I believe is still present and is illustrated precisely by the need for that exception clause in the /context field definition. I'd like to propose a much simpler solution.

A UML Behavior describes the dynamic behavior of its context classifier. All attributes and operations that it class during its execution should come from the context classifier. There is no need for the Behavior to own attributes and operations on its own, and I would like to suggest deriving Behavior directly from Classifier rather than from Class in section 13.3.2. I have not investigated the full impact of such a change, but I believe it would not have any significant impact and would improve the semantic integrity of the model.

A simple example is that a Behavior has a specification which could be, for example, a call to an Operation. Although the Operation belongs to a Class (its context), would would argue that the Operation is itself a Class?

The proposed change would actually have a significant impact on both the abstract syntax and semantics of Behavior.
A Behavior may be standalone with no context classifier, in which case it may be useful for the Behavior to have its
own structural and/or behavioral features. And, even if the Behavior has a context, the features of the Behavior may
be different than those of the context classifier, relating, for example, to the execution of the Behavior itself rather than
the state of the context object of the execution, particularly if the execution is asynchronous.
Disposition: Closed - No Change

I recently wrote a code generator for my UML tool for state machines. One of the properties of a state machine is called /context, which is the Class that has the state machine as its Classifier Behavior (if any exists). When I created a submachine state, the /context field of the state machine inside the submachine state was listing the parent state machine as its /context, rather than the class owning the parent state machine. This does not make semantic sense, because the purpose of the context field is the allow the state machine to have access to the methods and data of the class that implements the state machine behavior.

The UML spec says that to find the /context of a state machine, you must travel up the Owner tree until you hit the first Behaviored Classifier. My UML tool vendor pointed out to me that a State Machine is classified as a behaviored Classifier so it qualifies. That did not make sense to me because a State Machine is classified as a Behavior. How can a Behavior also be a class that owns a behavior?

After checking the UML spec further, I discovered that a Behavior, and therefore a State Machine, is derived from Class (Kernel), which is not a Behaviored Classifier. However, after all the packages are merged, Class (Kernel) gets merged with Class (Communications), which is a Behaviored Classifier, and the merge rules allow the class
hierarchy to be merged together. I confirmed this anomaly was present in the merged XMI files at OMG website.

I believe this problem is unique to Class metatype. If you look at Annex F of the UML spec, it shows the complex class hierarchy associated with Classifiers from various packages prior to merging. There are three merge increments for Class in three different places on the tree. These are even called out explicitly in the diagram. You
can see how the inheritance tree would be changed dramatically when these three Class increments are merged together. All other cases where the metatype increments are merged do not change the structure
of the inheritance tree. The Class metatype is unique in this respect.

I thought about a solution and I believe there is an easy fix to this problem. It requires replacing the Class (Communicatoins) increment with a new metatype called BehavioredClass, and replacing the Class (StructuredClasses) increment with the already existing
EncapsulatedClassifier. After this change, a BehavioredClass would be both a Class (Kernel) and a BehavioredClassifier, as is already illustrated in 13.3.8 but would now be more intuitive. Component would now inherit from Class (Kernel) and EncapsulatedClassifier (Ports). Node would inherit directly from EncapsulatedClassifier, thus preserving the pre-merge idea that Node's should not have data and methods associated with them (as with Class (Kernel)). This is another currently odd outcome of merging the packages together.

Because Class (Kernel) is a concrete metatype (and therefore shows up in modeling tools), you would need to make BehavioredClass concrete also. Modelers would have to expose it and I think this would be an improvement. I've always felt that active classes (like OS tasks) and
non-active classes (data and methods only) are such distinct object types that they should have separate representations. The elimination of the Class (StructuredClasses) increment would also prevent the
merge from adding ports to the generic concept of a Class, which is also desirable since ports are not useful without the ability to represent internal structure.

After that modification, there are other modifications that would naturally follow. The one I can see is that the isActive attribute of Class would now be a derived attribute which is set to true for classes that inherit BehavioredClass and false otherwise. With this change, in the fully merged UML package, a StateMachine would be derived from Class with only the Kernel attributes. It would no longer falsely inherit from BehavioredClassifier. A whole bunch of other inherited properties that make no sense would also go away.

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

If I am not mistaken, there is an error in several UML diagrams.

Let me start with page 14, figure 7.3: The name of the package on the left side is "Constructs", but it probably should read "Core", shouldn't it?

This UML diagram seems to be depicted several times in the document cited, which is why the situation is the same in the following places: page 27, second figure; page 29, figure 9.1; page 91, figure 10.1; page 103, figure 11.1.

Also, on page 162, section 11.9.2, subsection titled "Notation", second bullet point, it reads: "If the members of the package are shown within the large rectangle, then the name of the package should be placed within the tab." This would have to be implemented in the UML diagram(s) referred to above (now, the name "Constructs", that is to be corrected by "Core", is within the rectangle instead of within the tab).

I would be very glad to receive some feedback on my remarks.

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

Reading the document cited, I noticed some editorial errors. Thus, below you will find some suggestions for editorial changes.

• Page 23, Section 8.3.2, first sentence: Instead of "are enumerated", it should probably read "is enumerated".

• Page 48, section 9.8.3, subsection titled "Associations": Instead of "owning expression. Subsets", it should probably read "owning expression subsets".

• Page 96, section 10.2.1, subsection titled "Semantics", second paragraph, first sentence: Instead of "features on another class", it should probably read "features of another class".

• Page 98, section 10.2.5, subsection titled "Attributes", last bullet point, last sentence: Instead of "Default value", it should read "The default value".

• Page 111, section 11.3.1, first paragraph, second and third sentences: A space character is missing between the two sentences.

• Page 113, section 11.3.1, subsection titled "Semantics", sixth paragraph, first sentence: Instead of "characterized", it should read "characterizes".

• Page 151, section 11.7.5, subsection titled "Examples": Instead of "imported WebShop", it should read "imported to WebShop".

• Page 154, section 11.8.2, subsection titled "Constraints". Instead of "n operation", it should read "An operation".

• Page 173, section 12, second paragraph, fifth paragraph: Instead of "profile?s", it should read "profile's".

• Page 173, section 12, first numbered paragraph, last sentence: Instead of "more constraining", it should read "more constraining than".

• Page 178, section 12.1.2, subsection titled "Semantics", first paragraph, last sentence: Instead of "at most", it should (probably?) read "at least".

• Page 186, section 12.1.7, subsection titled "Semantics", last paragraph on page, last sentence: Instead of "and or", it should read "and/or".

• Page 191, section 12.1.8, subsection titled "Semantics", first paragraph, fourth and fifth sentences: There seems to be a mistake on the boundary between the two sentences ("all its nested and imported."); probably, something is missing at the end of the fourth sentence after "imported".

• Page 194, section 12.1.9, subsection titled "Semantics", third paragraph on page, second sentence: Instead of "theses stereotypes", it should read "these sstereotypes".

• Page 194, section 12.1.9, subsection titled "Notation", third paragraph, first sentence: Instead of "stereotype?s", it should read "stereotype's".

• Page 195, section 12.1.9, subsection titled "Presentation Options", first sentence on page: Instead of "may shown", it should read "may be shown".

• Page 196, section 12.1.9, subsection titled "Examples", last paragraph on page, second sentence: Before "isRequired", opening quotation marks are missing.

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

UML says: ” Stereotypes can participate in binary 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.”

How are instances of these stereotypes and associations to be serialized?

For example, look at SysML1.3 in which the stereotype ValueType has an association named A_valueType_unit to the stereotype Unit.

How is a SysML 1.3 model supposed to instantiate this? There will be an element representing the stereotype instance of this form:

<sysml:ValueType xmi:id="id1" base_DataType="id2" unit="id3"/>

What should id3 be the identity of? Presumably the target stereotype instance? Or the model element to which the target stereotype instance is applied?

Is such an association allowed to be a composition? If so what would be the deletion semantics?

Also, would we really expect to see any elements of this form?

<sysml: A_valueType_unit xmi:id="id4" valueType="id1" unit="id5"/>?

The following sentence: “For these associations there must be a property owned by the Stereotype to navigate to the opposite class. Where the opposite class is not a stereotype, the opposite property must be owned by the Association itself rather than the other class/metaclass” appears to imply that we would never see such an element, but I don’t know of any statement to confirm this

Clarify non-trivial aspects of associations defined in the context of a profile:
• Serializing instances of associations is optional for XMI.
• Associations can be composite or not.
• Clarify the kinds of Types allowed to be defined or imported in a Profile.
• Instances of stereotypes are owned by the link instance of the composite association corresponding to
the mapping of the stereotype extension.
• Fix the incorrect reference to section 14.3 of the MOF Core spec to 14.4 instead.
Note that clause 12 lacks a notation for instances of Profile-defined Classes, DataTypes and Associations.
Specifying such notation is a separate issue.

The caption of the first package(left) of the figure 7.3 is not wrong? The correct should not be Core(instead Construct)? That figure had me confused at the beginning

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

It is written that the Lifeline head has a shape that is based on the classifier for the part that this lifeline represents.

I think you want to tell that we can have a "stick man", if the lifeline represents an Actor.

It should be good to show an example for a lifeline that represents an Actor (it was the case in UML 1.3 at page 343, Figure 3-48).

Merged with 11068

In the UML spec there are several places where the color of the notation is specified. For example, the composition diamond is specified as black, the state machines junction ball is specified as black, and the lost/found message is specified as black, and the information identifier is a black triangle.

Similarly there are few cases where white and grey are specified.

This is overly limiting, some tools use a solid color for the items specified as black, or let the user select the color (usually selecting the same as the line color). It would not be good to limit the representation to only black color, as that would invalidate most PowerPoint and several tools.

Please change the color black to “solid” or “filled with the line color” and change “white” to “hollow” or “un-filled”.

For grey/gray it should be “a distinguishable value between the solid and the hollow”

Put some clarification into “How to read this specification”.

I probably discovered a little error in the UML 2.4.1 Superstructure Specification on page 109 in section “Associations” (from Chapter “7.3.38 Package (from Kernel)”):

The property “packagedElement: PackageableElement [*]” is not a derived property and should therefore not be prefixed with a ‘/’.

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

Action::inputPin and Action::outputPin are both derived unions. Both also have opposite association owned ends that are not derived. While I don't think the metamodel is actually incorrect, those owned ends are implicitly derived unions too. So I think it would make more sense to make that explicit.

I've just picked two examples, however I believe there are more in the specification.

The FTF agrees that the other ends ought to be derived unions. Because all cases of this are associationowned
ends, this does not affect serialization. There are ten cases of this in the metamodel, which are the
opposite ends for:
DirectedRelationship::source
DirectedRelationship::target
Classifier::attribute
StructuredClassifier::role
Action::input
Action::output
RedefinableElement::redefinedElement
RedefinableElement::redefinitionContext
Namespace::member
Relationship::relatedElement

In the semantics of activity, it is written "A token contains an object, datum, or locus of control, and is present in the activity diagram at a particular node." The term "locus of control" seems strange, and I think it should be "focus of control".

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

In V2.4.1 from 11-08-05 on page 14 in Figure 7.3 – „The Core packages“ the outer package is named „Constructs“. Is that correct or should it be called “Core”?

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

Section [notation] there is a wrong description. [* default is

] is wrong, isn't it? [* default is

] is correct, maybe. Because, [Attributes] says isDisjoint that's default value is false

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

In V2.4.1 from 11-08-05 on page 14 in Figure 7.3 – „The Core packages“ the outer package is named „Constructs“. Is that correct or should it be called “Core”?

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 internet I found a reference to something called a "SynchState" for state machines. I searched the UM Superstructure but didn't find this defined there, although there is an index entry for it.
Either the index entry is irrelevant or the state was omitted from the document

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

"coveredBy : InteractionFragment" is stated with a multiplicity of "[0..1]" although in the comment it says "References the InteractionFragments" and the machine readable XMI file of the superstructure has "*" as the value of the upper value of the coveredBy attribute.

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

ChangeEvent has defined association changeExpression:Expression[1], but the figure 13.12 depicts the association toward UML::Classes::Kernel::ValueSpecification.

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

The EnumerationLiterals in the XMI include values for the ‘classifier’ property which is redefined to be derived in the metamodel.

Even if not derived it would be the inverse of the owning composition so should not be serialized.

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

In Figure 8.2, A_realization_abstraction_component appears over Component - ComponentRealization composition line. But this name (association name?) is not used anywhere.

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

In Adobe Acrobat Reader, there are no "Subpart I" and "Subpart II" whereas there are "Subpart III" and "Subpart IV" .
This seems inconsistent

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

In Figure 17.13, the default value of ClassifierTemplateParameter#allowSubstitution is truncated to "...".

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

enumeration TransitionKind should appear in Figure 15.2.

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

Two association ends "interval" are hidden by class "Interval" and the last letters ("l") are not displayed.

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

"nonuni..." must be appeared as "nonunique"

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

It seems that "io-oargument" is misspelling of "io-argument".

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

"nonuni..." must be appeared as "nonunique"

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

In Figure 12.4, RedefinableElement has no note "(from Kernel)". I think all classes that do not belong to BasicActivities should be noted as "(from SomePackage)" within class compartment.

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

Abstraction class has defined association "mappings" of type Expression, but on page 35, figure 7.15 depicts Abstraction with the association of type OpaqueExpression.

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

Figure 12.21 blurs. In additon, the default value of LoopNode#isTestedFirst looks "fal...". (I suppose "false").

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

In Figure 12.22, there is "

must be located near +bodyOutput, rather than +clause.

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

Section 7.3.32 states in its Notation subsection that an asterisk denotes "unlimited (and not infinity)". Section 7.3.33 states that an asterisk represents "the unlimited (or infinite) upper bound". That one is infinite and the other not seems a contradiction

Merged with 18096

current text: “The behaviors of a UseCase can be described by a set of Behaviors (through its ownedBehavior relationship), such as Interactions, Activities, and StateMachines, or by pre-conditions and post-conditions...”

[AC] The “or” in “ or by pre-conditions and post-conditions” is ambiguous, because it can be interpreted as an XOR, while it is not exclusive. In fact, but several lines below, it is correctly stated that “These descriptions can be combined”. I suggest to remove the “or”.

agreed

current text: “An Actor models a type of role played by an entity that interacts with the subjects of its associated UseCases (e.g., by exchanging signals and data), but which is external in the sense that an instance of an Actor is not a part of the instance of a subject of an associated UseCase. “

[AC] In my opinion, this is ambiguous, and could be replaced with “in the sense that, in a specific modeling context, an instance of the Actor is not a part of the instance of the subject of an associated UseCase”.

The offending sentence is unclear, and the concept of “external” is vague and dubious. Better clarity can be
achieved by removing it altogether.

current text: “Although the owning Classifier typically represents the subject to which the owned UseCases apply, this is not necessarily the case.”

[AC] I would add: “as is shown in Figures 18.10 and 18.11”.

agreed

current text: “When a UseCase has an association to an Actor with a multiplicity that is greater than one at the Actor end, it means that more than one Actor instance is involved in initiating the UseCase.”

[AC] I would delete the term “initiating”, because it is wrong. Not only [may] a use case may be time-triggered, but the multiplicity may be >1 even if an instance of actor initiates the use case, then another instance is involved.

agreed

current text: ”If the condition of the Extend is true at the time the first ExtensionPoint is reached during the execution…

As it is unclear whether an omitted condition is true, clarify the situation by explicitly handing it. Replace the start of this paragraph with "If the condition of the Extend is missing or evaluates to true at the time the first ExtensionPoint is reached during the execution…”

Accept the proposal.

current text: “Therefore, it is not easy to capture its structure accurately or generally by a formal model.”

[AC] I would say “it is not possible”.

Delete the whole sentence, which adds no value to what can be deduced from the preceding sentence

current text: “Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior defined in a UseCase.”

[AC] According to the metamodel, if I'm not wrong, this should be “in one or more UseCases”.

agreed

current text: “The subject for a set of UseCases (sometimes called a system boundary) may be shown as a rectangle with its name (and associated keywords and stereotypes) in the top-left corner, with the UseCase ellipses visually located inside this rectangle.”
[
AC] I would add at the end “as shown in figure 18-2”.

General note: the numeric ordering of figures should be aligned with the sequence in which they are referenced in the text.

Accept the proposal in the first paragraph of the issue, using text to clarify that the figure is an example, and
explain what kind of subject is shown in the example.
The numeric ordering of figures is by editorial policy the order in which they appear, and that will not be
changed regardless of how they are referenced

current text: “Include is a DirectedRelationship between two UseCases, indicating that the behavior of the included UseCase (the addition) is inserted into the behavior of the including UseCase (the includingCase). It is also a kind of NamedElement so that it can have a name in the context of its owning UseCase.”

[AC] I would add at the end “(the includingCase)”.

accept the proposal

The InformationFlow element has an additional constraint that only allows a few classifiers to be source and target of an information flow. I don’t know why an Activity ­ or more general a Behavior ­ is not allowed to be a source or target of an information flow.

I propose to allow Behavior source/target of an InformationFlow.

Seems like a reasonable request. Although not truly a duplicate of issue 18415, we merge this issue with 18415
because both issues affect the same OCL constraint. It will be less confusing to construct a reply to both problems in
one place.
Disposition: Merged with 18415

Current text Figure 18-9 illustrates an ownedUseCase of a Class using an optional ownedMember compartment.
In the figure 18-9, the title of the compartment is owned use cases. The description should explain the discrepancy.

Optional compartment naming is specified in 9.2.4.

Please explain the multiplicity as used on this Figure 18-2. Without a good explanation, an example doesn’t really help
Something like this.
In this example, a Customer or Administrator may or may not participate in any of their associated Use Cases (hence the 0..1 multiplicity). From the Use Case perspective, it must have an Actor to initiate it (hence the 1 multiplicity). The Deposit and Register ATM use cases require participation by the Bank, while the bank can participate with many Deposit and Register ATM use cases at the same time.

This description will address open UML 2.4 issue 8854

Accept the proposal. This also resolves issue 8854

current text: “An Actor is represented by “stick man” icon with the name of the Actor in the vicinity (usually above or below) the icon.”

[AC] I would add at the end “See figure 18-6”

Accept the proposal, using text to clarify that the figure is an example; and fix the typo.

current text: “A UseCase may also be shown using the standard rectangle notation for Classifiers with an ellipse icon in the upper-right-hand corner of the rectangle. In this case, “extension points” is an optional compartment. This rendering is more suitable when there are a large number of extension points or features.”

[AC] I would add at the end “See figure 18-5”

Accept the proposal, using text to clarify that the figure is an example

current text: “An Include relationship between UseCases is shown by a dashed arrow with an open arrowhead pointing from the base UseCase to the included UseCase. The arrow is labeled with the keyword «include»..”
.”

[AC] I would add at the end “See figure 18-4”

Accept the proposal, using text to clarify that the figure is an example

current text: “An Extend relationship between UseCases is shown by a dashed arrow with an open arrowhead pointing from the extending UseCase towards the extended UseCase. The arrow is labeled with the keyword «extend». The condition of the Extend as well as references to the ExtensionPoints are optionally shown in a note symbol (see 7.2.4) attached to the corresponding arrow.”

[AC] I would add at the end “See figure 18-3”

Accept the proposal, using text to clarify that the figure is an example

current text: “The nesting (owning) of a UseCase by a Classifier may optionally be represented by nesting the UseCase ellipse inside the Classifier rectangle in a separate compartment. This is a case of the optional compartment for ownedMembers described in 9.2.4.”

[AC] I would add at the end “See figure 18-9”

Accept the proposal, using text to clarify that the figure is an example

current text: “Other icons that convey the kind of Actor may also be used to denote an Actor, such as using a separate icon for non-human Actors.”

[AC] I would add at the end “See figure 18-8”

Accept the proposal, using text to clarify that the figure is an example

It might be useful to explain in the text somewhere that the «Subsytem»ATM System is (necessarily) a component.

This clarification will address open UML 2.4 issue 16494

Explain that the subsystem is a Component; also clarify the notation to insist that the metaclass of the subject
should be explicitly shown in cases where it is ambiguous.
This also resolves issue 16494.

current text (696): A UseCase specifies a set of actions performed by its subject, which yields an observable result that is of value for one or more Actors or other stakeholders of the subject

Missing OCL to enforce this constraint.

Merged with 18045

current text (696): A UseCase specifies a set of actions performed by its subject, which yields an observable result that is of value for one or more Actors or other stakeholders of the subject

Missing OCL to enforce this constraint.

Merged with 18045

current text: “An Actor may also be shown as a Classifier rectangle with the keyword «actor», with the usual notation for all compartments.”

[AC] I would add at the end “See figure 18-7”

Accept the proposal, using text to clarify that the figure is an example.

Figure 18-10 duplicates Figure 18-2.

No, it doesn’t. It reuses part of 18.2 in a different context. Needs a better explanation

Missing constraint or discussion anywhere that the chain of includes relations must not contain loops

There is already a constraint to this effect: UseCase::cannot_include-self.
Disposition: Closed - No Change

Title: UML2.5, section 11: feature inheritance (of attribute properties,
ports and connectors) should be orthogonal to the topology of well-formed
connections in a structured classifier

Summary:

SysML uses extensively UML's StructuredClassifiers.
In UML 2.4.1, the well-formedness constraints for UML's
StructuredClassifiers were written in English only.
In UML 2.5, the well-formedness constraints have both English descriptions
and OCL specifications.

Unfortunately, the UML 2.5 OCL specifications for the well-formedness of
UML's StructuredClassifiers are too restrictive for SysML in 3 areas:

1) StructuredClassifier::/role is a derived union that is subsetted only
once by StructuredClassifier::ownedAttribute.

This means that inherited attributes of a StructuredClassifier are not
considered to be roles of that StructuredClassifier.

2) StructuredClassifier::/part is derived and the derivation is:
ownedAttribute->select(isComposite)

This means that inherited attributes of a StructuredClassifier are not
considered to be parts of that StructuredClassifier.

3) Connector has a constraint, roles, stated as follows:

The ConnectableElements attached as roles to each ConnectorEnd owned by a
Connector must be roles of the Classifier that owned the Connector, or
they must be Ports of such roles.

inv: structuredClassifier <> null
and
end->forAll( e |
structuredClassifier.role->includes(e.role)
or
e.role.oclIsKindOf(Port) and
structuredClassifier.role->includes(e.partWithPort))

There is a significant conceptual asymmetry between the two disjuncts of
the forAll() clause.

The first disjunct is: structuredClassifier.role->includes(e.role)

This restricts the ConnectableElement to be a role of the
StructuredClassifier owning the Connector; that is, the ConnectableElement
must be an ownedAttribute of that StructuredClassifier.

The second disjunct is: e.role.oclIsKindOf(Port) and
structuredClassifier.role->includes(e.partWithPort)

This also restricts the ConnectableElement::partWithPort to be a role of
the StructuredClassifier owning the Connector; however, the
ConnectableElement Port may be inherited!
(see ConnectorEnd::role_and_part_with_port)

The conceptual asymmetry is that it is OK to connect inherited ports of
owned attributes but it is not OK to connect inherited attributes.

>From a conceptual point of view, UML 2.5 does not provide a rationale for
restricting the connectivity of UML StructuredClassifiers to owned
attributes only.
>From a conceptual point of view, feature inheritance (I.e., of attribute
properties and of connectors) should be orthogonal to the topology of
connections in a StructuredClassifier.

Merged with 18697

I've just came across another issue: "ConnectableElement-end" has @isOrdered='true'. Since it is derived (and not derivedUnion) there is a corresponding operation for that attribute. However, the 'return' parameter for that operation doesn't declare @isOrdered='true'.
Shouldn't the return parameter of operations that describe derived attributes always 'match' the corresponding attribute ?

The result of the operation should be ordered if the property is ordered. But the operation cannot produce
an order, and there seems to be no requirement for the property to be ordered

There are three closely related problems in this issue:

1) incorrect constraint in Structured Classifiers, clause 11, Connector:

roles The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be roles of the Classifier that owned the Connector, or they must be Ports of such roles.
inv: structuredClassifier <> null
and
end->forAll( e |
structuredClassifier.role->includes(e.role)
or
e.role.oclIsKindOf(Port) and structuredClassifier.role->includes(e.partWithPort))