Unified Modeling Language Avatar
  1. OMG Specification

Unified Modeling Language — All Issues

  • Acronym: UML
  • Issues Count: 496
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UMLR-480 Can passive classes have ClassifierBehaviors? UML 2.4.1 open
UMLR-542 Figure 12-15 (MOF Model Equivalent …) p.284 - MOF Model Equivalent navigation and ownership incorrect UML 2.4.1 open
UMLR-582 What is a DurationInterval UML 2.4.1 open
UMLR-584 What is a DurationInterval UML 2.4.1 open
UMLR-528 Location: Figure 15-43 ActivityFinalNode example - Balancing Decision / Merge UML 2.4.1 open
UMLR-530 Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26 UML 2.4.1 open
UMLR-354 State machine semantics for transition between regions of an orthogonal state UML 2.4.1 open
UMLR-488 Interaction parameters. UML 2.4.1 open
UMLR-489 How should context be represented? UML 2.4.1 open
UML25-345 Location: 9.6.4 Notation p 128: Confusing indentation UML 2.4.1 UML 2.5 Resolved closed
UMLR-617 Location: 18.1.5 Examples Figure 18-2. 689 - Explain about Navigation UML 2.4.1 open
UML241-47 No unambiguous way in UML 2.4 to serialize StructuredActivityNode UML 2.4 UML 2.4.1 Resolved closed
UML25-682 InformationFlow cannot have an Activity as source or target UML 2.4.1 UML 2.5b1 Resolved closed
UML25-681 Location p 162 ParameterSet associationends: Exceptions and parametersets UML 2.4.1 UML 2.5b1 Resolved closed
UML25-671 an instance spec should be a legitimate value of a property typed by a classifier UML 2.4.1 UML 2.5 Resolved closed
UML25-668 A comment is a specialization of Element UML 2.4.1 UML 2.5 Resolved closed
UML25-667 Surplus classifier field serialized in Superstructure.xmi UML 2.4.1 UML 2.5 Resolved closed
UML25-670 Attribute is represented by Property UML 2.4.1 UML 2.5 Resolved closed
UML25-669 Operation "isConsistentWith" is not overridden for any RedefinableElement UML 2.4.1 UML 2.5 Resolved closed
UML25-664 Question About Arrows In Communication Diagramms UML 2.4.1 UML 2.5 Resolved closed
UML25-663 Constraint [1] uses undefined attribute "ownedAttribute UML 2.4.1 UML 2.5 Resolved closed
UML25-662 Inconsistency: CentralBufferNode (ch .12.3.16) and fig. 12.15 UML 2.4.1 UML 2.5 Resolved closed
UML25-665 missing words in section 14.1 UML 2.4.1 UML 2.5 Resolved closed
UML25-666 DurationObservation#event should be ordered UML 2.4.1 UML 2.5 Resolved closed
UML25-661 LifeLine instead of Lifeline UML 2.4.1 UML 2.5 Resolved closed
UML25-630 UML 2.3: Transitions outgoing junction vertexes should be allowed to have triggers UML 2.4.1 UML 2.5 Resolved closed
UML25-660 Behavior should be derived from Classifier, not Class UML 2.4.1 UML 2.5 Resolved closed
UML25-659 Package merge on Class metatype causes semantic issues - particularly with state machine context UML 2.4.1 UML 2.5 Resolved closed
UML25-648 Error in UML diagrams? UML 2.4.1 UML 2.5 Resolved closed
UML25-647 Suggestions for editorial changes UML 2.4.1 UML 2.5 Resolved closed
UML25-654 how to instantiate associations between stereotypes UML 2.4.1 UML 2.5 Resolved closed
UML25-653 Core package caption wrong UML 2.4.1 UML 2.5 Resolved closed
UML25-658 Add an example for the lifeline head shape UML 2.4.1 UML 2.5 Resolved closed
UML25-657 color of the notation is specified UML 2.4.1 UML 2.5 Resolved closed
UML25-656 The property “packagedElement: PackageableElement [*]” is not a derived property and should not be prefixed with "/" UML 2.4.1 UML 2.5 Resolved closed
UML25-655 Opposite ends of derived unions should be derived unions UML 2.4.1 UML 2.5 Resolved closed
UML25-651 Use of term "locus of control" UML 2.4.1 UML 2.5 Resolved closed
UML25-650 V2.4.1 from 11-08-05 on page 14 in Figure 7.3 UML 2.4.1 UML 2.5 Resolved closed
UML25-646 default is wrong UML 2.4.1 UML 2.5 Resolved closed
UML25-645 V2.4.1 from 11-08-05 on page 14 in Figure 7.3 UML 2.4.1 UML 2.5 Resolved closed
UML25-649 Reference in index to item that does not exist in contents UML 2.4.1 UML 2.5 Resolved closed
UML25-652 incorrect upper value of coveredBy of Lifeline UML 2.4.1 UML 2.5 Resolved closed
UML25-632 ChangeEvent association mismatch UML 2.4.1 UML 2.5 Resolved closed
UML25-631 EnumerationLiterals in the XMI UML 2.4.1 UML 2.5 Resolved closed
UML25-635 "A_realization_abstraction_component" is useless UML 2.4.1 UML 2.5 Resolved closed
UML25-634 Subpart I and II are missing in Bookmarks UML 2.4.1 UML 2.5 Resolved closed
UML25-644 default value of ClassifierTemplateParameter#allowSubstitutable is "..." UML 2.4.1 UML 2.5 Resolved closed
UML25-643 Figure 15.2 does not include TransitionKind UML 2.4.1 UML 2.5 Resolved closed
UML25-640 role "interval" appears "interva" UML 2.4.1 UML 2.5 Resolved closed
UML25-639 OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..." UML 2.4.1 UML 2.5 Resolved closed
UML25-642 misspelling: io-oargument UML 2.4.1 UML 2.5 Resolved closed
UML25-641 OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..." UML 2.4.1 UML 2.5 Resolved closed
UML25-636 RedefinableElement (from Kernel) is preferable UML 2.4.1 UML 2.5 Resolved closed
UML25-633 UML Superstructure Specification UML 2.4.1 UML 2.5 Resolved closed
UML25-637 poor figure resolution and a misspelling: fal...( false ) UML 2.4.1 UML 2.5 Resolved closed
UML25-638 {ordered} is rather far from +bodyOutput UML 2.4.1 UML 2.5 Resolved closed
UML25-491 Conflict in use of unlimited natural UML 2.4.1 UML 2.5 Resolved closed
UML25-414 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Or Pre-conditions appears limiting UML 2.4.1 UML 2.5 Resolved closed
UML25-417 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Clarification meaning of not part of the subject UML 2.4.1 UML 2.5 Resolved closed
UML25-416 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Point to Figures to help explain subject vs owner UML 2.4.1 UML 2.5 Resolved closed
UML25-415 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Initiating ? Interacting with UML 2.4.1 UML 2.5 Resolved closed
UML25-420 18.1.3 Semantics Use Case and Actors Extends P. 687 - Omitted conditions are true UML 2.4.1 UML 2.5 Resolved closed
UML25-419 18.1.3 Semantics Use Case and Actors Extends P. 687 - Easy UML 2.4.1 UML 2.5 Resolved closed
UML25-418 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Additional behavior vs Additional use case UML 2.4.1 UML 2.5 Resolved closed
UML25-422 Location: 18.1.4 Notation P. 688 - Point to diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-421 18.1.3 Semantics Use Case and Actors Extends P. 687 - Clarify role of owner UML 2.4.1 UML 2.5 Resolved closed
UML25-512 Behavior is not allowed to be source or target of an InformationFlow UML 2.4.1 UML 2.5 Resolved closed
UML25-432 Location: 18.1.5 Examples Figure 18-9. 690 - Description does not match figure 18-9 UML 2.4.1 UML 2.5 Resolved closed
UML25-431 Location: 18.1.5 Examples Figure 18-2. 689 - Explain about multiplicity UML 2.4.1 UML 2.5 Resolved closed
UML25-424 Location: 18.1.4 Notation P. 688 - Point to diagram (03) UML 2.4.1 UML 2.5 Resolved closed
UML25-423 Location: 18.1.4 Notation P. 688 - Point to diagram (02) UML 2.4.1 UML 2.5 Resolved closed
UML25-429 Location: 18.1.4 Notation P. 688 - Point to diagram (08) UML 2.4.1 UML 2.5 Resolved closed
UML25-428 Location: 18.1.4 Notation P. 688 - Point to diagram (07) UML 2.4.1 UML 2.5 Resolved closed
UML25-427 Location: 18.1.4 Notation P. 688 - Point to diagram (06) UML 2.4.1 UML 2.5 Resolved closed
UML25-426 Location: 18.1.4 Notation P. 688 - Point to diagram (05) UML 2.4.1 UML 2.5 Resolved closed
UML25-430 Location: 18.1.5 Examples Figure 18-2. 689 - Explain about «Subsystem» UML 2.4.1 UML 2.5 Resolved closed
UML25-436 Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - At least one actor UML 2.4.1 UML 2.5 Resolved closed
UML25-435 Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - At least one actor UML 2.4.1 UML 2.5 Resolved closed
UML25-425 Location: 18.1.4 Notation P. 688 - Point to diagram (04) UML 2.4.1 UML 2.5 Resolved closed
UML25-433 Location: 18.1.5 Examples Figure 18-10. 691 - Duplicate Diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-434 Location: 18.2 Classifier Descriptions Include Constraints. 696 - Includes must be a DAG UML 2.4.1 UML 2.5 Resolved closed
UML25-470 Section 11: feature inheritance should be orthogonal to the topology of well-formed connections in a structured classifi UML 2.4.1 UML 2.5 Resolved closed
UML25-469 ConnectableElement-end" has @isOrdered='true' UML 2.4.1 UML 2.5 Resolved closed
UML25-468 UML2.5: clarification about the semantics of redefinition UML 2.4.1 UML 2.5 Resolved closed
UML25-467 Lifeline has no type. UML 2.4.1 UML 2.5 Resolved closed
UML25-466 Location: Table B.1 UML Keywords p 778 - Use of # in Semantics col UML 2.4.1 UML 2.5 Resolved closed
UML25-451 Location: B.4.4 State Shapes P. 752 - State List Limitations UML 2.4.1 UML 2.5 Resolved closed
UML25-450 Location: B.2.4 P. 739 - confusing model and diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-441 Location: Table 21-1 PrimitiveType semantics Real P. 726 - IEEE 754 UML 2.4.1 UML 2.5 Resolved closed
UML25-440 Location: 21.1 Summary P. 726 - Missing header UML 2.4.1 UML 2.5 Resolved closed
UML25-438 Location: Figure 18-3 Example Extend p.689 - Circle on comment "anchor" not standard UML 2.4.1 UML 2.5 Resolved closed
UML25-437 Location: 18.1.1 Summary p 685 - emergent behavior UML 2.4.1 UML 2.5 Resolved closed
UML25-445 Location: Table 21-1 String P. 726 UML 2.4.1 UML 2.5 Resolved closed
UML25-444 Location: Table 21-1 P. 726 - Title of table not great UML 2.4.1 UML 2.5 Resolved closed
UML25-443 Location: 21.2 Semantics P. 726 - Subsection title UML 2.4.1 UML 2.5 Resolved closed
UML25-442 Location: Table 21-1 PrimitiveType semantics Real P. 726 - Real Number representation UML 2.4.1 UML 2.5 Resolved closed
UML25-448 Location: Figure 21-3 UML 2.4.1 UML 2.5 Resolved closed
UML25-447 Location: Table 21-1 P. 726 - Row ordering UML 2.4.1 UML 2.5 Resolved closed
UML25-446 Location: Table 21-1 Unlimited Natural P. 726 - Infinity UML 2.4.1 UML 2.5 Resolved closed
UML25-439 Location: Figure 20-4 and accompanying text P. 719 - InformationItem can represent multiple types? UML 2.4.1 UML 2.5 Resolved closed
UML25-449 Location: B.2.3 P. 738 - confusing model and diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-456 Location: Annex C Keywords p 777 - Capitalization of «trace» UML 2.4.1 UML 2.5 Resolved closed
UML25-455 Location: Annex C Keywords P. 777 - Previously unmentioned constraints given in Keywords Annex UML 2.4.1 UML 2.5 Resolved closed
UML25-453 Location: B.6 UMLILabel Constraints. P 766 - Use Case Oval. UML 2.4.1 UML 2.5 Resolved closed
UML25-452 Location: B.6 Classifier Description UMLInheritedStateBorderKind [Enumeration] Literals p 763 UML 2.4.1 UML 2.5 Resolved closed
UML25-458 Location: Table B.1 UML Keywords p 778 - Keywords should be in index UML 2.4.1 UML 2.5 Resolved closed
UML25-457 Location: Annex C Keywords p 777 - Capitalization of «create» UML 2.4.1 UML 2.5 Resolved closed
UML25-464 Location: Index p. 796 among others - Index items with only one page UML 2.4.1 UML 2.5 Resolved closed
UML25-463 Location: Index p 795 - Index of "is" UML 2.4.1 UML 2.5 Resolved closed
UML25-460 Location: Index UML 2.4.1 UML 2.5 Resolved closed
UML25-459 Location: Annex C Keywords P. 780 - Bizarre definition of statemachine UML 2.4.1 UML 2.5 Resolved closed
UML25-454 Location B.6 UMLStateShape statelist p 770 - StateList Limitations UML 2.4.1 UML 2.5 Resolved closed
UML25-462 Location: Index p 793 - emergent behavior UML 2.4.1 UML 2.5 Resolved closed
UML25-465 Location: Index Mis. - Missing terms in the Index UML 2.4.1 UML 2.5 Resolved closed
UML25-461 Type: Structural - Location Index p 790, 794, UML 2.4.1 UML 2.5 Resolved closed
UML25-394 Location: 15.5.1 - typo UML 2.4.1 UML 2.5 Resolved closed
UML25-393 Location: Figure 15.57 page 426 UML 2.4.1 UML 2.5 Resolved closed
UML25-399 Location: 17.2.3 Semantics Interaction Fragments p 607 UML 2.4.1 UML 2.5 Resolved closed
UML25-398 17.1.5 Interaction Diagram Variants p 607 UML 2.4.1 UML 2.5 Resolved closed
UML25-397 Location: p 484 - Exception store UML 2.4.1 UML 2.5 Resolved closed
UML25-396 Location: Figure 15-23 p.411 UML 2.4.1 UML 2.5 Resolved closed
UML25-391 Location: Figure 15-23 UML 2.4.1 UML 2.5 Resolved closed
UML25-390 Location: p. 357 StateMachine Redefinition UML 2.4.1 UML 2.5 Resolved closed
UML25-389 Location: p. 338 Transition execution sequence UML 2.4.1 UML 2.5 Resolved closed
UML25-388 Location: p. 338 Transition execution sequence UML 2.4.1 UML 2.5 Resolved closed
UML25-395 Location: Figure 15-63 UML 2.4.1 UML 2.5 Resolved closed
UML25-387 Location: p. 337 Conflicting Transitions UML 2.4.1 UML 2.5 Resolved closed
UML25-392 Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26 UML 2.4.1 UML 2.5 Resolved closed
UML25-386 Location: p. 337 Conflicting Transitions UML 2.4.1 UML 2.5 Resolved closed
UML25-317 What is “Intentionally Not specified”? UML 2.4.1 UML 2.5 Resolved closed
UML25-316 What is aggregation UML 2.4.1 UML 2.5 Resolved closed
UML25-311 inout parameters and effects UML 2.4.1 UML 2.5 Resolved closed
UML25-310 Effect Intent UML 2.4.1 UML 2.5 Resolved closed
UML25-308 Return Parameter order UML 2.4.1 UML 2.5 Resolved closed
UML25-307 Default value of readonly should be referenced UML 2.4.1 UML 2.5 Resolved closed
UML25-313 Parameter Sets UML 2.4.1 UML 2.5 Resolved closed
UML25-312 isException and direction and effect UML 2.4.1 UML 2.5 Resolved closed
UML25-320 Location: 9.5.3 p 122 In the common case UML 2.4.1 UML 2.5 Resolved closed
UML25-319 Location: 9.5.3 p 121 Why not all empty UML 2.4.1 UML 2.5 Resolved closed
UML25-314 Use isReadOnly default UML 2.4.1 UML 2.5 Resolved closed
UML25-315 Redefinition does not allow for overloading UML 2.4.1 UML 2.5 Resolved closed
UML25-318 What is “Intentionally Not specified”? UML 2.4.1 UML 2.5 Resolved closed
UML25-309 Return Parameter pronoun UML 2.4.1 UML 2.5 Resolved closed
UML25-223 Two categories is not enough UML 2.4.1 UML 2.5 Resolved closed
UML25-222 UML Semantics UML 2.4.1 UML 2.5 Resolved closed
UML25-224 Semantics Areas section not clear UML 2.4.1 UML 2.5 Resolved closed
UML25-413 Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Variants are not defined UML 2.4.1 UML 2.5 Resolved closed
UML25-412 Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Actors need not initiate UML 2.4.1 UML 2.5 Resolved closed
UML25-411 Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Are actors mandatory? UML 2.4.1 UML 2.5 Resolved closed
UML25-405 Location: Pg. 615, Figure 17.4.3: Semantics, Sub-clause: Messages UML 2.4.1 UML 2.5 Resolved closed
UML25-404 Pg. 613, Clause 17.3.4: Notation UML 2.4.1 UML 2.5 Resolved closed
UML25-403 Location: Pg. 612, Clause 17.2.5 - Minor rewording to Clause 17.2.5 UML 2.4.1 UML 2.5 Resolved closed
UML25-402 Location: Pg. 612, Figure 17.5 - Modify Figure 17.5 to enhance readability UML 2.4.1 UML 2.5 Resolved closed
UML25-410 Location: 18.1.1 Summary P. 685 - A Subject may only refer to a single system UML 2.4.1 UML 2.5 Resolved closed
UML25-409 General value lifeline Row p 647 UML 2.4.1 UML 2.5 Resolved closed
UML25-408 Location: Table 17.6 entire table p 646 UML 2.4.1 UML 2.5 Resolved closed
UML25-401 Pg. 611, Clause 17.2.5: Examples - : Insert “formal” in reference to gates in the “Examples” clause (17.2.5) UML 2.4.1 UML 2.5 Resolved closed
UML25-400 Location: 17.2.4 Notation ExecutionSpecification p608 - : Specification of color UML 2.4.1 UML 2.5 Resolved closed
UML25-407 Location: LostMessage Row p 639 UML 2.4.1 UML 2.5 Resolved closed
UML25-406 Pg. 617, Figure 17.4.3: Semantics, Sub-clause: Gates - Replace “formal” with “actual” in Clause 17.4.3 UML 2.4.1 UML 2.5 Resolved closed
UML25-264 Default value for LiteralString UML 2.4.1 UML 2.5 Resolved closed
UML25-263 Optional String Multiplicity UML 2.4.1 UML 2.5 Resolved closed
UML25-256 Excessive null checks UML 2.4.1 UML 2.5 Resolved closed
UML25-255 Single and set of aren't really parallel UML 2.4.1 UML 2.5 Resolved closed
UML25-252 Missing a UML 2.4.1 UML 2.5 Resolved closed
UML25-251 inconsistent spacing on diagram UML 2.4.1 UML 2.5 Resolved closed
UML25-260 TypedElement description could be expanded UML 2.4.1 UML 2.5 Resolved closed
UML25-259 It seems to me that a relationship requires a minimum of two relatedElements UML 2.4.1 UML 2.5 Resolved closed
UML25-254 Use of the diamond symbol (?)needs to be explained UML 2.4.1 UML 2.5 Resolved closed
UML25-253 Instantiate Dependency UML 2.4.1 UML 2.5 Resolved closed
UML25-261 Generalization Relationship to itself? UML 2.4.1 UML 2.5 Resolved closed
UML25-262 Negatively phrased sentence UML 2.4.1 UML 2.5 Resolved closed
UML25-258 Sentence difficult to read UML 2.4.1 UML 2.5 Resolved closed
UML25-257 allNamespace description doesn't match OCL UML 2.4.1 UML 2.5 Resolved closed
UML25-338 Location p 152 Generalization Attributes: IsSubstitutable UML 2.4.1 UML 2.5 Resolved closed
UML25-340 Location p 153 complete_and_disjoint: Abstract Implication UML 2.4.1 UML 2.5 Resolved closed
UML25-339 Location p 153 complete_and_disjoint: Complete vs covering? UML 2.4.1 UML 2.5 Resolved closed
UML25-334 Location: p 145 CallConcurrencyKind [Enumeration - blocks -- > locks UML 2.4.1 UML 2.5 Resolved closed
UML25-333 Location: p 145 (3X) Detail: simultaneously -- > concurrently UML 2.4.1 UML 2.5 Resolved closed
UML25-337 Location p 146 Classifier Description: isAbstract UML 2.4.1 UML 2.5 Resolved closed
UML25-336 Location p 145 Classifier Description: objects -> instances UML 2.4.1 UML 2.5 Resolved closed
UML25-343 Location p 162 two_parameter_sets: Why UML 2.4.1 UML 2.5 Resolved closed
UML25-342 Location p 157 isConsistentWith: missing rules UML 2.4.1 UML 2.5 Resolved closed
UML25-341 Location p 154 Association Ends: Instances of multiple classifiers UML 2.4.1 UML 2.5 Resolved closed
UML25-344 Location p 162 ParameterSet constraints input: Exceptions and parameterset UML 2.4.1 UML 2.5 Resolved closed
UML25-335 Location p 145 Classifier Description - objects -> instances UML 2.4.1 UML 2.5 Resolved closed
UML25-249 While-->And UML 2.4.1 UML 2.5 Resolved closed
UML25-248 Unclear description of multiplicities UML 2.4.1 UML 2.5 Resolved closed
UML25-243 Imports UML 2.4.1 UML 2.5 Resolved closed
UML25-242 ElementImport cannot be further imported UML 2.4.1 UML 2.5 Resolved closed
UML25-247 Confusing description of types UML 2.4.1 UML 2.5 Resolved closed
UML25-238 Note refers to an undiscussed concept UML 2.4.1 UML 2.5 Resolved closed
UML25-240 Packageable Elements and Imports UML 2.4.1 UML 2.5 Resolved closed
UML25-239 Missing word UML 2.4.1 UML 2.5 Resolved closed
UML25-246 Missing TypedElement - use of the term constrained seems to be circular UML 2.4.1 UML 2.5 Resolved closed
UML25-245 Missing TypedElement UML 2.4.1 UML 2.5 Resolved closed
UML25-250 Missing OCL UML 2.4.1 UML 2.5 Resolved closed
UML25-241 Packageable Elements and Imports (02) UML 2.4.1 UML 2.5 Resolved closed
UML25-244 Incorrect text describing diagram elements UML 2.4.1 UML 2.5 Resolved closed
UML25-358 Location 13.1 Summary p 305 - Use of the word “emergent” UML 2.4.1 UML 2.5 Resolved closed
UML25-357 Operations p 245 (2X) typo UML 2.4.1 UML 2.5 Resolved closed
UML25-355 Location Figure 11-23 s p.217 - Instance/roll names UML 2.4.1 UML 2.5 Resolved closed
UML25-354 Location Figure 11-22 s p.216 - Title doesn’t match contents UML 2.4.1 UML 2.5 Resolved closed
UML25-351 Location: Constraints p 193 - Missing constraint? UML 2.4.1 UML 2.5 Resolved closed
UML25-350 Location 10.4.4 Notations p.188 - Reception compartment UML 2.4.1 UML 2.5 Resolved closed
UML25-349 Location 10.3.3 Signals p.186 UML 2.4.1 UML 2.5 Resolved closed
UML25-348 10.2.4 Notation p 184. - Enumeration attributes and operations UML 2.4.1 UML 2.5 Resolved closed
UML25-346 Location: 10.2.3 Enumeration p. 184: New EnumerationLiterals UML 2.4.1 UML 2.5 Resolved closed
UML25-347 Location: 10.2.4 Notation p 184 UML 2.4.1 UML 2.5 Resolved closed
UML25-353 Location Figure 11-21 s p.216 - Instance/roll names UML 2.4.1 UML 2.5 Resolved closed
UML25-356 Location Figure 11-23 s p.217 - Instance/roll names (02) UML 2.4.1 UML 2.5 Resolved closed
UML25-352 Location: Figure 11-3 UML 2.4.1 UML 2.5 Resolved closed
UML25-281 Wrong Reference UML 2.4.1 UML 2.5 Resolved closed
UML25-280 missing headings UML 2.4.1 UML 2.5 Resolved closed
UML25-290 Min/Max UML 2.4.1 UML 2.5 Resolved closed
UML25-289 Two anonymous invariants UML 2.4.1 UML 2.5 Resolved closed
UML25-292 8.6 p 100 isCompatibleWith() ..save space UML 2.4.1 UML 2.5 Resolved closed
UML25-291 Save Space UML 2.4.1 UML 2.5 Resolved closed
UML25-288 result() error UML 2.4.1 UML 2.5 Resolved closed
UML25-287 French UML 2.4.1 UML 2.5 Resolved closed
UML25-284 Invariant name UML 2.4.1 UML 2.5 Resolved closed
UML25-283 Improve readability of constraint names UML 2.4.1 UML 2.5 Resolved closed
UML25-295 Association Descriptions not that useful UML 2.4.1 UML 2.5 Resolved closed
UML25-294 IsNull not Boolean UML 2.4.1 UML 2.5 Resolved closed
UML25-282 Duration Definition UML 2.4.1 UML 2.5 Resolved closed
UML25-286 Set--> List UML 2.4.1 UML 2.5 Resolved closed
UML25-285 Why is value optional UML 2.4.1 UML 2.5 Resolved closed
UML25-293 Turing Machine lurking paradox? UML 2.4.1 UML 2.5 Resolved closed
UML25-323 Location: 9.6.3 Operations p 127 Undefined ? UML 2.4.1 UML 2.5 Resolved closed
UML25-322 Location: 9.5.3 p 121 Can’t qualifiers be queries? UML 2.4.1 UML 2.5 Resolved closed
UML25-330 Location: 9.8.4 Notation p 141 UML 2.4.1 UML 2.5 Resolved closed
UML25-329 Location: 9.8.3 Semantics p 139 UML 2.4.1 UML 2.5 Resolved closed
UML25-326 Location: 9.6.4 Notation p 128 Is return a reserved parameter name? UML 2.4.1 UML 2.5 Resolved closed
UML25-325 Location: 9.6.4 Notation p 127 Simplify description of syntax UML 2.4.1 UML 2.5 Resolved closed
UML25-321 Location: 9.5.3 p 122 Qualifiers must be enumerated type UML 2.4.1 UML 2.5 Resolved closed
UML25-324 Location: 9.6.3 Operations p 127 UML 2.4.1 UML 2.5 Resolved closed
UML25-328 Location: 9.7.5 Examples p 135 Political Correctness UML 2.4.1 UML 2.5 Resolved closed
UML25-327 Location: 9.7.5 Examples p 134 Generalization Sets UML 2.4.1 UML 2.5 Resolved closed
UML25-331 Location: 9.8.4 Notation p 141 representing the roles vs representing the instances UML 2.4.1 UML 2.5 Resolved closed
UML25-332 Location: 9.9 Classifier Descriptions Association Ends p 144 Behavioral --> Behavior UML 2.4.1 UML 2.5 Resolved closed
UML25-237 Clarification of imports UML 2.4.1 UML 2.5 Resolved closed
UML25-236 Namespace Abstract Syntax incorrect UML 2.4.1 UML 2.5 Resolved closed
UML25-230 Add reference to association notation section UML 2.4.1 UML 2.5 Resolved closed
UML25-229 How does dot notation work UML 2.4.1 UML 2.5 Resolved closed
UML25-227 Extraneous Note UML 2.4.1 UML 2.5 Resolved closed
UML25-226 Sentence does not make sense UML 2.4.1 UML 2.5 Resolved closed
UML25-233 Owning Comments UML 2.4.1 UML 2.5 Resolved closed
UML25-232 Root Abstract Syntax missing adornments/metamodel incorrect UML 2.4.1 UML 2.5 Resolved closed
UML25-234 Owning Rules UML 2.4.1 UML 2.5 Resolved closed
UML25-231 Owning Comments UML 2.4.1 UML 2.5 Resolved closed
UML25-225 Figure 6.1 does not relate to rest of Specification UML 2.4.1 UML 2.5 Resolved closed
UML25-235 Can Comments own comments? UML 2.4.1 UML 2.5 Resolved closed
UML25-228 What type of slash? UML 2.4.1 UML 2.5 Resolved closed
UML25-367 Location: Page 330, 331, 333, 14.2.3, Page 347, 14.2.4, Page 375, 14.5 PseudostateKind UML 2.4.1 UML 2.5 Resolved closed
UML25-366 Location: Page 329 States - Stable UML 2.4.1 UML 2.5 Resolved closed
UML25-362 Location: Page 315 Association ends - Explain about having no nestedClassifier UML 2.4.1 UML 2.5 Resolved closed
UML25-361 Location: Page 313, 13.2.4 Notation relative UML 2.4.1 UML 2.5 Resolved closed
UML25-369 Location: Page 341, 14.2.4 - Example for graphical expression of behavior in states UML 2.4.1 UML 2.5 Resolved closed
UML25-365 Location: Page 328 Regions 14.2.3 - Text about regions without initial state UML 2.4.1 UML 2.5 Resolved closed
UML25-371 Location: Page 346, State List Notations UML 2.4.1 UML 2.5 Resolved closed
UML25-370 Location: Page 341, State - More examples needed UML 2.4.1 UML 2.5 Resolved closed
UML25-368 Location: Page 338, Transition selection algorithm - Maximal Set UML 2.4.1 UML 2.5 Resolved closed
UML25-364 Location: 14.2.1 Summary - Behavior StateMachines for UseCases UML 2.4.1 UML 2.5 Resolved closed
UML25-363 Location: 14.1 Summary p 326 UML 2.4.1 UML 2.5 Resolved closed
UML25-360 Location Behavior Parameters p 307 - Streaming and Multiplicity UML 2.4.1 UML 2.5 Resolved closed
UML25-359 Location Behavior Parameters p 307 - Optional with default value UML 2.4.1 UML 2.5 Resolved closed
UML25-304 Alterative Scopes? UML 2.4.1 UML 2.5 Resolved closed
UML25-303 Multiplicity of 0..0 UML 2.4.1 UML 2.5 Resolved closed
UML25-301 Location p.112 (9.3 Classifier Templates) UML 2.4.1 UML 2.5 Resolved closed
UML25-300 Incompatible with SysML UML 2.4.1 UML 2.5 Resolved closed
UML25-297 the parent of a Classifier is not its owner.” UML 2.4.1 UML 2.5 Resolved closed
UML25-302 Location: p.116 (9.4.3 Semantics) UML 2.4.1 UML 2.5 Resolved closed
UML25-298 What is inherited or not UML 2.4.1 UML 2.5 Resolved closed
UML25-299 Inherited members UML 2.4.1 UML 2.5 Resolved closed
UML25-306 Redefinable Static attributes UML 2.4.1 UML 2.5 Resolved closed
UML25-305 Examples of alternative scopes? UML 2.4.1 UML 2.5 Resolved closed
UML25-296 Objects? UML 2.4.1 UML 2.5 Resolved closed
UML25-378 Location: p. 329 State Configurations UML 2.4.1 UML 2.5 Resolved closed
UML25-377 Location: p. 328 Regions - Resolve intentional ambiguity UML 2.4.1 UML 2.5 Resolved closed
UML25-373 Location: Transition , bottom of page 352 UML 2.4.1 UML 2.5 Resolved closed
UML25-372 Location: Page 347, 14.2.4 UML 2.4.1 UML 2.5 Resolved closed
UML25-376 Location: p 378 State Description - What is hidden? UML 2.4.1 UML 2.5 Resolved closed
UML25-375 Location: p 373 outgoing_from_initial - Limitations on guards UML 2.4.1 UML 2.5 Resolved closed
UML25-374 Page 353, 14.2.4 - StateMachine symbols on graphical representations of Transitions UML 2.4.1 UML 2.5 Resolved closed
UML25-382 Location: p. 333 FinalState UML 2.4.1 UML 2.5 Resolved closed
UML25-381 Location: p. 331 Exiting a State - Clarification of Exiting a State UML 2.4.1 UML 2.5 Resolved closed
UML25-385 Location: p. 337 2nd ¶ UML 2.4.1 UML 2.5 Resolved closed
UML25-384 Location: p. 336 Compound transitions UML 2.4.1 UML 2.5 Resolved closed
UML25-383 Location: p. 333 Transitions - How do multiple triggers work? UML 2.4.1 UML 2.5 Resolved closed
UML25-379 Location: p. 330 Deferred Events - Value of Deferred Events UML 2.4.1 UML 2.5 Resolved closed
UML25-380 Location: p. 331 Explicit Entry - Clarification of Explicit Entry UML 2.4.1 UML 2.5 Resolved closed
UML25-268 Unlimited Natural UML 2.4.1 UML 2.5 Resolved closed
UML25-267 String concrete syntax is missing UML 2.4.1 UML 2.5 Resolved closed
UML25-270 BNF rules allow for a real 0 UML 2.4.1 UML 2.5 Resolved closed
UML25-269 Notation: Real UML 2.4.1 UML 2.5 Resolved closed
UML25-266 LiteralNull semantics UML 2.4.1 UML 2.5 Resolved closed
UML25-265 Default value for LiteralReal UML 2.4.1 UML 2.5 Resolved closed
UML25-279 Always non-negative UML 2.4.1 UML 2.5 Resolved closed
UML25-278 Duration UML 2.4.1 UML 2.5 Resolved closed
UML25-274 set - > list UML 2.4.1 UML 2.5 Resolved closed
UML25-273 Plural headers when class name is singular UML 2.4.1 UML 2.5 Resolved closed
UML25-276 body text strings UML 2.4.1 UML 2.5 Resolved closed
UML25-275 sentence unclear UML 2.4.1 UML 2.5 Resolved closed
UML25-271 Past vs Present UML 2.4.1 UML 2.5 Resolved closed
UML25-277 String expression notation missing UML 2.4.1 UML 2.5 Resolved closed
UML25-272 {ordered} at wrong end UML 2.4.1 UML 2.5 Resolved closed
UML25-219 Incarnation ? UML 2.4.1 UML 2.5 Resolved closed
UML25-218 Show how UML is a MOF metamodel UML 2.4.1 UML 2.5 Resolved closed
UML25-214 Conformance definitions ? UML 2.4.1 UML 2.5 Resolved closed
UML25-213 Impact of merging profiles isn't small UML 2.4.1 UML 2.5 Resolved closed
UML25-217 Keyword Usage UML 2.4.1 UML 2.5 Resolved closed
UML25-216 ISO version of UML 2? UML 2.4.1 UML 2.5 Resolved closed
UML25-220 Within the System UML 2.4.1 UML 2.5 Resolved closed
UML25-212 Capture Submitters, Supporters, etc UML 2.4.1 UML 2.5 Resolved closed
UML25-221 Modeling Individuals UML 2.4.1 UML 2.5 Resolved closed
UML25-215 DI Conformance implies Model Interchange Conformance UML 2.4.1 UML 2.5 Resolved closed
UML25-191 Clarification on the semantics of Multiplicities UML 2.4.1 UML 2.5 Resolved closed
UML25-190 Clarification on the semantics of UML UML 2.4.1 UML 2.5 Resolved closed
UML25-189 Conformance point UML 2.4.1 UML 2.5 Resolved closed
UML25-193 Clarification on the semantics of Properties UML 2.4.1 UML 2.5 Resolved closed
UML25-192 Clarification on the semantics of Parameters UML 2.4.1 UML 2.5 Resolved closed
UML25-197 Clarification on the semantics of Manifestation UML 2.4.1 UML 2.5 Resolved closed
UML25-196 Clarification on the aim of Collaborations UML 2.4.1 UML 2.5 Resolved closed
UML25-195 Clarification on the semantics of ports in Encapsulated Classifiers UML 2.4.1 UML 2.5 Resolved closed
UML25-194 Clarification on the semantics of Connectors within Structured Classifiers UML 2.4.1 UML 2.5 Resolved closed
UML25-198 Declassifying of Annex D UML 2.4.1 UML 2.5 Resolved closed
UML25-211 Missing Table of Figures, Table of Tables - Location: TOC p 10 UML 2.4.1 UML 2.5 Resolved closed
UML25-210 Minor vs Major revision UML 2.4.1 UML 2.5 Resolved closed
UML25-209 Section 11.5. - Clause 11: Structured Classifiers UML 2.4.1 UML 2.5 Resolved closed
UML241-12 UML type Real specification UML 2.4 UML 2.4.1 Resolved closed
UML241-11 Interface element - associations multiplicity not defined UML 2.4 UML 2.4.1 Resolved closed
UML241-9 Property::isID UML 2.4 UML 2.4.1 Resolved closed
UML241-6 Wrong package name on several Figures UML 2.4 UML 2.4.1 Resolved closed
UML241-10 Missing Namespace in Dependencies package definition? UML 2.4 UML 2.4.1 Resolved closed
UML241-3 typo on page 46 UML 2.4 UML 2.4.1 Resolved closed
UML241-22 Irritating occurrence of subsystem stereotype in use case example diagrams UML 2.4 UML 2.4.1 Resolved closed
UML241-21 UML 2.4: NamedElement.ownedRule could be ordered UML 2.4 UML 2.4.1 Resolved closed
UML241-19 property.opposite UML 2.4 UML 2.4.1 Resolved closed
UML241-18 ProfileApplication::appliedProfile as "importedProfile" instead of "appliedProfile" UML 2.4 UML 2.4.1 Resolved closed
UML241-25 ChangeEvent::changeExpression should be of type ValueSpecification UML 2.4 UML 2.4.1 Resolved closed
UML241-24 Validity duration of implicitly assigned parameters in SignalEvent/CallEvent UML 2.4 UML 2.4.1 Resolved closed
UML241-17 XMI in small caps UML 2.4 UML 2.4.1 Resolved closed
UML241-16 Core Package versus Construct Package UML 2.4 UML 2.4.1 Resolved closed
UML241-20 UML Appendix A : Figure A.3 Two Diagrams of Packages” UML 2.4 UML 2.4.1 Resolved closed
UML241-15 XML Metadata Interchange (XMI) - p9 UML 2.4 UML 2.4.1 Resolved closed
UML241-14 XML Metadata Interchange (XMI) UML 2.4 UML 2.4.1 Resolved closed
UML241-23 Implicit parameter assignment may cause name clashes UML 2.4 UML 2.4.1 Resolved closed
UML241-13 Number of Compliance Levels UML 2.4 UML 2.4.1 Resolved closed
UML241-2 Presentation options of statemachine transitions: Figure 15.45 is ambiguous or wrong UML 2.4 UML 2.4.1 Resolved closed
UML241-1 Can a Generalization really be in multiple GeneralizationSets? UML 2.4 UML 2.4.1 Resolved closed
UML241-5 No Rules for Element Names UML 2.4 UML 2.4.1 Resolved closed
UML241-4 Figure 15.32 UML 2.4 UML 2.4.1 Resolved closed
UML241-8 Figure 15.32 UML 2.4 UML 2.4.1 Resolved closed
UML241-7 Typo: "joint" should say "join" UML 2.4 UML 2.4.1 Resolved closed
UMLR-504 Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Constraint is overly restrictive UML 2.4.1 open
UMLR-502 Location: 18.1.4 Notation P. 688 - Can Use Cases have attributes and operations? UML 2.4.1 open
UMLR-496 Location: Figure A.5 P. 734 - Use Cases are not behavior diagrams UML 2.4.1 open
UMLR-497 Location: Appendix A, list of frame names, p 734 - List of Namespaces suitable for diagram headers is overly restrictive UML 2.4.1 open
UMLR-500 Location: 18.1.1 Summary p 685 - Bases of specialized stereotypes UML 2.4.1 open
UMLR-501 Location: 19.5 Classifier Descriptions Deployment Specification Attributes P. 711 - Why a multiplicity of [0..1] UML 2.4.1 open
UMLR-498 Location: 22.3 Standard Stereotypes «Metamodel» p. 731 - «Subsystem» should be allowed for more classifiers UML 2.4.1 open
UMLR-499 Location: 19.5 Node Association Ends Node P. 714 - Shared ownership of nodes UML 2.4.1 open
UMLR-506 Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Extensions must be a DAG UML 2.4.1 open
UMLR-495 Location: Figure B.3. 737 - A diagram is a PackageableElement UML 2.4.1 open
UMLR-568 Reword isComputable UML 2.4.1 open
UMLR-569 Location: 8.6 p 98 TimeObservation ...simplify UML 2.4.1 open
UMLR-576 Too many alls UML 2.4.1 open
UMLR-575 Intended to Produce UML 2.4.1 open
UMLR-577 Bad Description, observation has no value UML 2.4.1 open
UMLR-580 Like to overridden definition UML 2.4.1 open
UMLR-573 Why can’t the operand be a stringExpression UML 2.4.1 open
UMLR-578 Range Confusion UML 2.4.1 open
UMLR-570 Simplify (Location: 8.6 p 97 TimeExpression) UML 2.4.1 open
UMLR-574 Bad Description UML 2.4.1 open
UMLR-571 Simplify UML 2.4.1 open
UMLR-572 What incompatible about sub-expressions and operands UML 2.4.1 open
UMLR-432 Add condition : Constraint[0..1] to the include relationship UML 2.4.1 open
UMLR-595 Definition of invariant condition UML 2.4.1 open
UMLR-597 Section Unbalanced UML 2.4.1 open
UMLR-592 Need table correlating Literals with symbols (+,-,#,~) UML 2.4.1 open
UMLR-593 Inconsistent use of (s) UML 2.4.1 open
UMLR-601 Section 11.7 has no content or notation for template Collaborations Clause - 11: Structured Classifiers UML 2.4.1 open
UMLR-603 Section 11.3.4 isService clarification - Clause 11: Structured Classifiers UML 2.4.1 open
UMLR-596 Descendants rather than specializations UML 2.4.1 open
UMLR-602 Section 11.2.4 clarification - Clause 11: Structured Classifiers UML 2.4.1 open
UMLR-600 List attributes whose ordered property has change in UML 2.5 UML 2.4.1 open
UMLR-598 Bound Element Semantics overly specific UML 2.4.1 open
UMLR-599 UML 2.5 FTF issues for Clause 18: UseCases UML 2.4.1 open
UMLR-594 Template Notation example UML 2.4.1 open
UMLR-615 Clarification on the semantics of CommunicationPath UML 2.4.1 open
UMLR-614 isIntegral() UML 2.4.1 open
UMLR-613 Capitalization of dependency UML 2.4.1 open
UMLR-476 Node::nestedNode should subset Class::nestedClassifier, not Namespace::ownedMember. UML 2.4.1 open
UMLR-477 Meaning of State in ProtocolStateMachines UML 2.4.1 open
UMLR-479 Should “completion” event be an explicit event type? UML 2.4.1 open
UMLR-481 Not clear if “else” keyword is defined for State Machines UML 2.4.1 open
UMLR-482 State of the substates of the history state UML 2.4.1 open
UMLR-473 It is a pity that UML does not provide the ability for Messages to correspond directly to property accesses and updates UML 2.4.1 open
UMLR-474 Meaning of absent multiplicity notation UML 2.4.1 open
UMLR-478 Figure 14.39 – missing superclass UML 2.4.1 open
UMLR-517 Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification UML 2.4.1 open
UMLR-518 Location: Pg. 617, Figure 17.4.4: Notation, Sub-clause: Message UML 2.4.1 open
UMLR-508 18.1.3 Semantics Use Case and Actors Extends P. 687 - No Alternative Path UML 2.4.1 open
UMLR-509 18.1.3 Semantics Use Case and Actors Extends P. 687 - First ExtensionPoint UML 2.4.1 open
UMLR-513 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - What classifiers can be a subject? UML 2.4.1 open
UMLR-516 Location: 18. Global - No discussion of use case instances UML 2.4.1 open
UMLR-511 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiplicity at Use Case end UML 2.4.1 open
UMLR-510 18.1.3 Semantics Use Case and Actors Extends P. 687 - Show name of extension UML 2.4.1 open
UMLR-514 Location:Page #640, 17.8.2 Example Sequence Diagram UML 2.4.1 open
UMLR-512 Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiple subjects require the same actors UML 2.4.1 open
UMLR-507 18.1.3 Semantics Use Case and Actors Extends P. 687 - Single Location UML 2.4.1 open
UMLR-515 Location: weak sequencing p. 622 UML 2.4.1 open
UMLR-585 What is a DurationConstaint UML 2.4.1 open
UMLR-586 Time constant UML 2.4.1 open
UMLR-579 More detail on Express UML 2.4.1 open
UMLR-590 Expression examples unclear UML 2.4.1 open
UMLR-588 OCL not indexed UML 2.4.1 open
UMLR-591 Semantics Clarification UML 2.4.1 open
UMLR-587 Event UML 2.4.1 open
UMLR-581 incompatible multiplicities UML 2.4.1 open
UMLR-583 one -- > first UML 2.4.1 open
UMLR-589 Orphan Title UML 2.4.1 open
UMLR-521 Location: Pg. 613, Figure 17.6 - : Incorrect multiplicities in the metamodel in Figure 17.6 UML 2.4.1 open
UMLR-522 Location: p 611 UML 2.4.1 open
UMLR-524 Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification UML 2.4.1 open
UMLR-529 Location p413 Final Node - Rollback behavior UML 2.4.1 open
UMLR-532 Location p413 Final Node - Atomic behavior UML 2.4.1 open
UMLR-519 Location: 17.3.4 Notation Lifeline p 613 - Specification of color UML 2.4.1 open
UMLR-520 Location: Pg. 613, Figure 17.6 - Incorrect multiplicities in the metamodel in Figure 17.6 UML 2.4.1 open
UMLR-525 Interactions p 607 UML 2.4.1 open
UMLR-523 Location: 16.2.3 Semantics / Opaque Actions UML 2.4.1 open
UMLR-527 Location: Figure 15.67 page 436 UML 2.4.1 open
UMLR-526 Location: p 504 - Marshall Actions UML 2.4.1 open
UMLR-608 Issue for UML 2.5 FTF against Clause 9: Classifiers UML 2.4.1 open
UMLR-557 Location: Page 265, 12.2.3 Semantics - Unchanged URIs UML 2.4.1 open
UMLR-555 Location: 12.2.3 Semantics Package p 265 - Reference to unknown section heading UML 2.4.1 open
UMLR-566 Location: 9.6.4 Notation p 127 Missing Infix operation syntax / discussion UML 2.4.1 open
UMLR-567 ParameterSet Notation UML 2.4.1 open
UMLR-561 Location: constraints class_behavior p.190 UML 2.4.1 open
UMLR-562 Location 10.3.3 Receptions p.186 - exceptions for receptions? UML 2.4.1 open
UMLR-563 p 118: isException and other outputs UML 2.4.1 open
UMLR-560 Location: Constraints p 193 - All feturs must be public? UML 2.4.1 open
UMLR-564 Location p 162 ParameterSet associationends: Exceptions and parametersets UML 2.4.1 open
UMLR-558 Location: 12.1 Packages Summary p 264 UML 2.4.1 open
UMLR-559 Location: Figure 11-5 (ii) p 204 UML 2.4.1 open
UMLR-565 Query of alternative scopes? UML 2.4.1 open
UMLR-486 Problems with XMI IDs in the UML 2.5 UML.xmi file UML 2.4.1 open
UMLR-487 17 Semantics of interactions UML 2.4.1 open
UMLR-490 UML Interactions do not provide the ability for Messages to correspond directly to property accesses and updates UML 2.4.1 open
UMLR-493 Location: B.6 UML ProfileDiagrams . 768 - Profile Diagram Elements UML 2.4.1 open
UMLR-492 Location: B.6 UMLClass Diagram P. 757 - Class namespace diagrams? UML 2.4.1 open
UMLR-483 Overriding deferred events UML 2.4.1 open
UMLR-484 Stable state not needed UML 2.4.1 open
UMLR-491 Location: Annex C Keywords P. 778 - Inconsistent metaclass keywords UML 2.4.1 open
UMLR-485 Default entry if default history transition missing UML 2.4.1 open
UMLR-494 Location: B.2.2 P. 738 - What ISO document UML 2.4.1 open
UMLR-549 Location: Page 270/271, 12.2.3 Semantics - Model description confusing UML 2.4.1 open
UMLR-550 Location: Page 269, 12.2.3 Semantics - Association merge aggregation constraint is property rule UML 2.4.1 open
UMLR-545 Location: Page 286, 12.3.3 Semantics - Incorrect if statement UML 2.4.1 open
UMLR-544 Location: Page 285, 12.3.3 Semantics - Old behavior unnecessarily preserved UML 2.4.1 open
UMLR-552 Page 269, 12.2.3 Semantics - Property merge transformation conflicts with constrain UML 2.4.1 open
UMLR-553 Location: Page 267, 12.2.3 Semantics - Type and TypedElement confusion UML 2.4.1 open
UMLR-556 Location: Page 265, 12.2.3 Semantics PackageMerge - Long-winded package merge description UML 2.4.1 open
UMLR-546 Location: Page 281, 12.3.3 Semantics - Duplicated text UML 2.4.1 open
UMLR-554 Page 266, 12.2.3 Semantics - Un-matched resulting elements aren't always the same UML 2.4.1 open
UMLR-548 Location: Page 280, 12.3.3 Semantics - Note should be main text UML 2.4.1 open
UMLR-551 Location: Page 269, 12.2.3 Semantics - Property merge rule pointless UML 2.4.1 open
UMLR-547 Location: Page 280, 12.3.3 Semantics - Poorly indented XMI UML 2.4.1 open
UMLR-543 Location: Page 286, 12.3.3 Semantics - Nonsensical alternative to stereotype name UML 2.4.1 open
UMLR-531 Location: p 410 UML 2.4.1 open
UMLR-537 Location: Page 328, 14.2.3 - UseCase cannot be the context of a StateMachine UML 2.4.1 open
UMLR-536 Location: Signal Receipt symbol UML 2.4.1 open
UMLR-534 Location: Page 346, State List Notations - Why must state lists be effect free? UML 2.4.1 open
UMLR-538 Location: 13.3.5 Examples p 314 UML 2.4.1 open
UMLR-540 Location: Opaque and Function Behaviors p 308 UML 2.4.1 open
UMLR-533 Location: p. 336 Compound transitions - Run-to-completion Paradigm UML 2.4.1 open
UMLR-539 Location: Page 316 redefinedBehavior - Extends UML 2.4.1 open
UMLR-535 Location: Page 331 deep history entry - Default deep history entry UML 2.4.1 open
UMLR-541 Location: Figure 12-13 p.281 - Incorrect use of << for «. UML 2.4.1 open
UMLR-610 How to model a transition to history pseudostates in two orthogonal regions? UML 2.4.1 open
UMLR-612 Clarification on the semantics of inheritance between use cases UML 2.4.1 open
UMLR-264 OccurrenceSpecification should have at least an optional notation UML 2.4 open
UMLR-262 Message arguments for a Signal signature too restrictive UML 2.4 open
UMLR-261 Relation of message arguments to signature parameters ambiguous UML 2.4 open
UMLR-265 The included use case is always required for the including use case to execute correctly UML 2.4.1 open
UMLR-266 Abstraction::mapping should be of type ValueSpecification or OpaqueExpression UML 2.4 open
UMLR-263 Message arguments should not be contained in a message UML 2.4 open
UMLR-294 Cannot set an activity as the source or target of an information flow UML 2.4.1 open
UMLR-254 Use cases specifying the same subject cannot be associated: exception UML 2.4 open
UMLR-252 Metaclass stereotype notion (02) UML 2.4 open
UMLR-251 Metaclass stereotype notion UML 2.4 open
UMLR-250 Profile URI Attribute - Mingled URI Definition and Use in XMI UML 2.4 open
UMLR-249 Package URI Attribute Uses Obsolete RFC 2396 UML 2.4 open
UMLR-255 A deferrable trigger may have a guard UML 2.4 open
UMLR-311 Name of Package in Figure 7.3 should be "Core" rather than "Constructs" UML 2.4.1 open
UMLR-270 Interaction.action should subset ownedMember in lieu of ownedElement UML 2.4.1 open

Issues Descriptions

Can passive classes have ClassifierBehaviors?

  • Key: UMLR-480
  • Legacy Issue Number: 18160
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Category: Major

    In the StateMachine section “Event processing for state machines”, there is an explicit statement: “for passive classes it can be implemented using a monitor”, which suggests that passive classes implement the run-to-completion paradigm. This implies that passive classes can have classifier behaviors. Perhaps this capability should be removed, but, it may not be backward compatible and might invalidate numerous existing designs (e.g., Rhapsody models).

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Mon, 3 Feb 2020 16:26 GMT

Figure 12-15 (MOF Model Equivalent …) p.284 - MOF Model Equivalent navigation and ownership incorrect

  • Key: UMLR-542
  • Legacy Issue Number: 17963
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Figure 12-15 (MOF Model Equivalent to Extending "Interface" by the Home" Stereotype) shows navigation only from the stereotype to the metaclass, but the paragraph just below it says the ExtensionEnd (the one opposite the metaclass) is a navigableOwnedEnd. Extensions were made navigableOwnedEnds in 2.3.
    Before that the spec explicitly said Extensions were non-navigable because the association owned them. This wasn't true, so Pete filed issue 9891 (ExtensionEnd description refers to old use of navigability) and it was corrected by making them navigableOwnedEnds.
    Presumably the figure should show navigation in both directions and use the dot notation to show which end is owned.
    A constraint could be added to Extension that its ownedEnd is a navigableOwnedEnd.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Wed, 28 Jun 2017 17:23 GMT

What is a DurationInterval

  • Key: UMLR-582
  • Legacy Issue Number: 17847
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Identifies is better than points out.

    Subsequent description is confusing about one/two NamedElements.

    Suggest:

    It identifies either a NamedElement whose enter and exit events are observed, or a pair of NamedElements for each of which either an enter or exit event is observed.
    ...
    When there are two events, firstEvent[i] is true to select the enter, or false to select the exit, event for observation of the corresponding event. —

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Wed, 28 Jun 2017 17:17 GMT

What is a DurationInterval

  • Key: UMLR-584
  • Legacy Issue Number: 17846
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    What is the "range" between two durations. Is it a statistical property? is it max to max, min to min, ....?? Ah. I get it. This is a spectacularly confusing class name. Introducing an alternate editorial term compounds rather than mitigates the problem. Use "distance" in the descriptions, then users might grasp that it is not a time interval. In max/min refer to larger/smaller duration rather than range.

    Discussion
    Source: Edward Willink
    I'm stll very confused, if two duration are being compared in some way, such that the min and max of the range is being found, then the durations must either be duration constants, or offset from some observation. If the two durations do not use the same observation, then there should be no duration interval?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Wed, 28 Jun 2017 17:17 GMT

Location: Figure 15-43 ActivityFinalNode example - Balancing Decision / Merge

  • Key: UMLR-528
  • Legacy Issue Number: 18012
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Diagramming style should reflect good diagramming and programming practice, which is NOT to share merge diamonds. This is like two IF statements sharing the same ENDIF

    If there are two decisions there should be two merges (in the majority of cases)

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Wed, 28 Jun 2017 16:22 GMT

Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26

  • Key: UMLR-530
  • Legacy Issue Number: 18009
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Type Limitations on DecisionInputFlows

    It also does not seem logical necessary to restrict the decisionInputFlow to be an Objectflow. Though a ControlFlow has no value, it could be present or null, which could be tested to enable or disable the decision.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Wed, 28 Jun 2017 16:22 GMT

State machine semantics for transition between regions of an orthogonal state

  • Key: UMLR-354
  • Legacy Issue Number: 19593
  • Status: open  
  • Source: steelbreeze.net ( David Mesquita-Morris)
  • Summary:

    I am trying to understand the semantics of a transition between vertices in orthogonal regions of the same parent composite state.
    The specification is clear re. exiting the parent composite state, but not between sibling regions.
    This raises issues regarding entering already active regions and states.

  • Reported: UML 2.4.1 — Sun, 31 Aug 2014 04:00 GMT
  • Updated: Tue, 6 Dec 2016 19:32 GMT

Interaction parameters.

  • Key: UMLR-488
  • Legacy Issue Number: 18129
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Other related issue - Interaction parameters.

    When Interaction itself is set as a method of Operation with parameters, how these are represented in Sequence Diagram? Can Parameter be represented as a lifeline? (Parameter is ConnectableElement).

    How value returning is represented?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Sun, 8 May 2016 02:29 GMT

How should context be represented?

  • Key: UMLR-489
  • Legacy Issue Number: 18128
  • Status: open  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    We have similar issues to represent calls to self/context. How context should be represented? As lifeline with keyword "self" or "this"?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Sun, 8 May 2016 02:29 GMT

Location: 9.6.4 Notation p 128: Confusing indentation

  • Key: UML25-345
  • Legacy Issue Number: 17930
  • Status: closed  
  • Source: Dassault Systemes ( Mr. James L. Logan III)
  • Summary:

    The line

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

    {‘ <oper-property> [‘,’ <oper-property>]* ‘}

    ’]]"

    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.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:
  • Updated: Sun, 28 Feb 2016 17:14 GMT

Location: 18.1.5 Examples Figure 18-2. 689 - Explain about Navigation

  • Key: UMLR-617
  • Legacy Issue Number: 18073
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The example should be shown with navigation (arrows) on the associations, to indicate initiating (primary) and non-initiating (secondary) actors. This is legal and common notation
    This would partially address Issue 8855

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Mon, 9 Mar 2015 03:34 GMT

No unambiguous way in UML 2.4 to serialize StructuredActivityNode

  • Key: UML241-47
  • Legacy Issue Number: 16232
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    We just recently had discussion with Ed about an issue with Activity::node and Activity::group. Both are composite non-derived properties and it causes problems with all StructuredActivityNodes, which are ActivityNodes and ActivityGroups at the same time.
    MagicDraw or Eclipse implementation of UML does not allow to own the same element in two composites , even if owner element is the same.
    Does XMI support that?

    So, ExpansionRegion or any other StructuredActivityNode appears in Activity::group only.

    fUML spec/engine expects to find them in Activity::node , as all owned nodes should be there.

    Any suggestions? Don't you think we should fix that somehow?

  • Reported: UML 2.4 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    No Data Available

  • Updated: Sun, 8 Mar 2015 15:04 GMT

InformationFlow cannot have an Activity as source or target

  • Key: UML25-682
  • Legacy Issue Number: 18743
  • Status: closed  
  • Source: Alstom Transport ( Wagner Schalch Mendes)
  • Summary:

    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?

  • Reported: UML 2.4.1 — Wed, 29 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5b1
  • Disposition Summary:

    duplicate, issue closed

  • Updated: Sat, 7 Mar 2015 04:44 GMT

Location p 162 ParameterSet associationends: Exceptions and parametersets

  • Key: UML25-681
  • Legacy Issue Number: 17928
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5b1
  • Disposition Summary:

    duplicate of 17927, withdrawn and closed

  • Updated: Sat, 7 Mar 2015 04:44 GMT

an instance spec should be a legitimate value of a property typed by a classifier

  • Key: UML25-671
  • Legacy Issue Number: 17565
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    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

  • Reported: UML 2.4.1 — Mon, 27 Aug 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

A comment is a specialization of Element

  • Key: UML25-668
  • Legacy Issue Number: 17530
  • Status: closed  
  • Source: me.com ( Carlos Prado)
  • Summary:

    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

  • Reported: UML 2.4.1 — Thu, 26 Jul 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Surplus classifier field serialized in Superstructure.xmi

  • Key: UML25-667
  • Legacy Issue Number: 17507
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Tomas Juknevicius)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Thu, 19 Jul 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Attribute is represented by Property

  • Key: UML25-670
  • Legacy Issue Number: 17550
  • Status: closed  
  • Source: gmail.com ( Hongwei Ma)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Sat, 11 Aug 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Operation "isConsistentWith" is not overridden for any RedefinableElement

  • Key: UML25-669
  • Legacy Issue Number: 17547
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Thu, 9 Aug 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Question About Arrows In Communication Diagramms

  • Key: UML25-664
  • Legacy Issue Number: 17398
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: UML 2.4.1 — Tue, 29 May 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Constraint [1] uses undefined attribute "ownedAttribute

  • Key: UML25-663
  • Legacy Issue Number: 17366
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

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

  • Reported: UML 2.4.1 — Mon, 14 May 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Inconsistency: CentralBufferNode (ch .12.3.16) and fig. 12.15

  • Key: UML25-662
  • Legacy Issue Number: 17333
  • Status: closed  
  • Source: Steria Mummert Consulting AG ( Torsten Binias)
  • Summary:

    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".

  • Reported: UML 2.4.1 — Tue, 24 Apr 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

missing words in section 14.1

  • Key: UML25-665
  • Legacy Issue Number: 17461
  • Status: closed  
  • Source: gmail.com ( Nicolas Bros)
  • Summary:

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

  • Reported: UML 2.4.1 — Thu, 28 Jun 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

DurationObservation#event should be ordered

  • Key: UML25-666
  • Legacy Issue Number: 17466
  • Status: closed  
  • Source: gmail.com ( Nicolas Bros)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Thu, 5 Jul 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

LifeLine instead of Lifeline

  • Key: UML25-661
  • Legacy Issue Number: 17328
  • Status: closed  
  • Source: 1s.fr ( YuGiOhJCJ)
  • Summary:

    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).

  • Reported: UML 2.4.1 — Mon, 23 Apr 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML 2.3: Transitions outgoing junction vertexes should be allowed to have triggers

  • Key: UML25-630
  • Legacy Issue Number: 16581
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    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.”

  • Reported: UML 2.4.1 — Tue, 4 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Behavior should be derived from Classifier, not Class

  • Key: UML25-660
  • Legacy Issue Number: 17289
  • Status: closed  
  • Source: rvirzi.com ( Raymond Virzi)
  • Summary:

    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?

  • Reported: UML 2.4.1 — Sun, 1 Apr 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Package merge on Class metatype causes semantic issues - particularly with state machine context

  • Key: UML25-659
  • Legacy Issue Number: 17283
  • Status: closed  
  • Source: rvirzi.com ( Raymond Virzi)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Thu, 29 Mar 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Error in UML diagrams?

  • Key: UML25-648
  • Legacy Issue Number: 16724
  • Status: closed  
  • Source: University of Vienna/Austrian Academy of Sciences ( Georg Lönger)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Fri, 25 Nov 2011 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Suggestions for editorial changes

  • Key: UML25-647
  • Legacy Issue Number: 16723
  • Status: closed  
  • Source: University of Vienna/Austrian Academy of Sciences ( Georg Lönger)
  • Summary:

    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.
  • Reported: UML 2.4.1 — Fri, 25 Nov 2011 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

how to instantiate associations between stereotypes

  • Key: UML25-654
  • Legacy Issue Number: 17160
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    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

  • Reported: UML 2.4.1 — Thu, 23 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Core package caption wrong

  • Key: UML25-653
  • Legacy Issue Number: 17131
  • Status: closed  
  • Source: gmail.com ( Jair Humberto)
  • Summary:

    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

  • Reported: UML 2.4.1 — Thu, 16 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add an example for the lifeline head shape

  • Key: UML25-658
  • Legacy Issue Number: 17268
  • Status: closed  
  • Source: 1s.fr ( YuGiOhJCJ)
  • Summary:

    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).

  • Reported: UML 2.4.1 — Thu, 22 Mar 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 11068

  • Updated: Fri, 6 Mar 2015 20:59 GMT

color of the notation is specified

  • Key: UML25-657
  • Legacy Issue Number: 17266
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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”

  • Reported: UML 2.4.1 — Tue, 20 Mar 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

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

  • Key: UML25-656
  • Legacy Issue Number: 17202
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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 ‘/’.

  • Reported: UML 2.4.1 — Tue, 28 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Opposite ends of derived unions should be derived unions

  • Key: UML25-655
  • Legacy Issue Number: 17172
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Fri, 24 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Use of term "locus of control"

  • Key: UML25-651
  • Legacy Issue Number: 16946
  • Status: closed  
  • Source: Technion, Israel Institute of Technology ( Arieh Bibliowicz)
  • Summary:

    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".

  • Reported: UML 2.4.1 — Mon, 9 Jan 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

V2.4.1 from 11-08-05 on page 14 in Figure 7.3

  • Key: UML25-650
  • Legacy Issue Number: 16875
  • Status: closed  
  • Source: softenvironment.ch ( Peter Hirzel)
  • Summary:

    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”?

  • Reported: UML 2.4.1 — Wed, 2 Nov 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

default is wrong

  • Key: UML25-646
  • Legacy Issue Number: 16656
  • Status: closed  
  • Source: gmail.com ( Ooki Kawai)
  • Summary:

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

    {incomplete, disjoint}

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

    {incomplete, overlapping}

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

  • Reported: UML 2.4.1 — Wed, 9 Nov 2011 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

V2.4.1 from 11-08-05 on page 14 in Figure 7.3

  • Key: UML25-645
  • Legacy Issue Number: 16651
  • Status: closed  
  • Source: softenvironment.ch ( Peter Hirzel)
  • Summary:

    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”?

  • Reported: UML 2.4.1 — Wed, 2 Nov 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Reference in index to item that does not exist in contents

  • Key: UML25-649
  • Legacy Issue Number: 16725
  • Status: closed  
  • Source: Technion, Israel Institute of Technology ( Arieh Bibliowicz)
  • Summary:

    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

  • Reported: UML 2.4.1 — Sun, 27 Nov 2011 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

incorrect upper value of coveredBy of Lifeline

  • Key: UML25-652
  • Legacy Issue Number: 17127
  • Status: closed  
  • Source: web.de ( Matthias Schoettle)
  • Summary:

    "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.

  • Reported: UML 2.4.1 — Fri, 10 Feb 2012 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ChangeEvent association mismatch

  • Key: UML25-632
  • Legacy Issue Number: 16590
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

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

  • Reported: UML 2.4.1 — Tue, 11 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

EnumerationLiterals in the XMI

  • Key: UML25-631
  • Legacy Issue Number: 16584
  • Status: closed  
  • Source: Adaptive ( Mr. Pete Rivett)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Thu, 6 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

"A_realization_abstraction_component" is useless

  • Key: UML25-635
  • Legacy Issue Number: 16635
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

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

  • Reported: UML 2.4.1 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Subpart I and II are missing in Bookmarks

  • Key: UML25-634
  • Legacy Issue Number: 16634
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

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

  • Reported: UML 2.4.1 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

default value of ClassifierTemplateParameter#allowSubstitutable is "..."

  • Key: UML25-644
  • Legacy Issue Number: 16650
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

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

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 15.2 does not include TransitionKind

  • Key: UML25-643
  • Legacy Issue Number: 16647
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    enumeration TransitionKind should appear in Figure 15.2.

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

role "interval" appears "interva"

  • Key: UML25-640
  • Legacy Issue Number: 16644
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

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

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..."

  • Key: UML25-639
  • Legacy Issue Number: 16643
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

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

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

misspelling: io-oargument

  • Key: UML25-642
  • Legacy Issue Number: 16646
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

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

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..."

  • Key: UML25-641
  • Legacy Issue Number: 16645
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

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

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

RedefinableElement (from Kernel) is preferable

  • Key: UML25-636
  • Legacy Issue Number: 16638
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML Superstructure Specification

  • Key: UML25-633
  • Legacy Issue Number: 16596
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

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

  • Reported: UML 2.4.1 — Fri, 14 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

poor figure resolution and a misspelling: fal...( false )

  • Key: UML25-637
  • Legacy Issue Number: 16639
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

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

  • Reported: UML 2.4.1 — Thu, 27 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

{ordered} is rather far from +bodyOutput

  • Key: UML25-638
  • Legacy Issue Number: 16642
  • Status: closed  
  • Source: NEC ( Tateki Sano)
  • Summary:

    In Figure 12.22, there is "

    {ordered}" near role "+clause". I think {ordered}

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

  • Reported: UML 2.4.1 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Conflict in use of unlimited natural

  • Key: UML25-491
  • Legacy Issue Number: 18442
  • Status: closed  
  • Source: Institute for Defense Analyses ( Steven Wartik)
  • Summary:

    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

  • Reported: UML 2.4.1 — Mon, 11 Feb 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18096

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Or Pre-conditions appears limiting

  • Key: UML25-414
  • Legacy Issue Number: 18049
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Clarification meaning of not part of the subject

  • Key: UML25-417
  • Legacy Issue Number: 18053
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Point to Figures to help explain subject vs owner

  • Key: UML25-416
  • Legacy Issue Number: 18051
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Initiating ? Interacting with

  • Key: UML25-415
  • Legacy Issue Number: 18050
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - Omitted conditions are true

  • Key: UML25-420
  • Legacy Issue Number: 18058
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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…”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - Easy

  • Key: UML25-419
  • Legacy Issue Number: 18057
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Additional behavior vs Additional use case

  • Key: UML25-418
  • Legacy Issue Number: 18055
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.4 Notation P. 688 - Point to diagram

  • Key: UML25-422
  • Legacy Issue Number: 18063
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - Clarify role of owner

  • Key: UML25-421
  • Legacy Issue Number: 18061
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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)”.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    accept the proposal

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Behavior is not allowed to be source or target of an InformationFlow

  • Key: UML25-512
  • Legacy Issue Number: 18690
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Tim Weilkiens)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Tue, 30 Apr 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.5 Examples Figure 18-9. 690 - Description does not match figure 18-9

  • Key: UML25-432
  • Legacy Issue Number: 18074
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Optional compartment naming is specified in 9.2.4.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.5 Examples Figure 18-2. 689 - Explain about multiplicity

  • Key: UML25-431
  • Legacy Issue Number: 18072
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the proposal. This also resolves issue 8854

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.4 Notation P. 688 - Point to diagram (03)

  • Key: UML25-424
  • Legacy Issue Number: 18065
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.4 Notation P. 688 - Point to diagram (02)

  • Key: UML25-423
  • Legacy Issue Number: 18064
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.4 Notation P. 688 - Point to diagram (08)

  • Key: UML25-429
  • Legacy Issue Number: 18070
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.4 Notation P. 688 - Point to diagram (07)

  • Key: UML25-428
  • Legacy Issue Number: 18069
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.4 Notation P. 688 - Point to diagram (06)

  • Key: UML25-427
  • Legacy Issue Number: 18068
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.4 Notation P. 688 - Point to diagram (05)

  • Key: UML25-426
  • Legacy Issue Number: 18067
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.5 Examples Figure 18-2. 689 - Explain about «Subsystem»

  • Key: UML25-430
  • Legacy Issue Number: 18071
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - At least one actor

  • Key: UML25-436
  • Legacy Issue Number: 18080
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18045

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.2 Classifier Descriptions Use Case Constraints. 697 - At least one actor

  • Key: UML25-435
  • Legacy Issue Number: 18079
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18045

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.4 Notation P. 688 - Point to diagram (04)

  • Key: UML25-425
  • Legacy Issue Number: 18066
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    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”

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.5 Examples Figure 18-10. 691 - Duplicate Diagram

  • Key: UML25-433
  • Legacy Issue Number: 18075
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Figure 18-10 duplicates Figure 18-2.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.2 Classifier Descriptions Include Constraints. 696 - Includes must be a DAG

  • Key: UML25-434
  • Legacy Issue Number: 18078
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 11: feature inheritance should be orthogonal to the topology of well-formed connections in a structured classifi

  • Key: UML25-470
  • Legacy Issue Number: 18171
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    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.

  • Reported: UML 2.4.1 — Thu, 11 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18697

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ConnectableElement-end" has @isOrdered='true'

  • Key: UML25-469
  • Legacy Issue Number: 18140
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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 ?

  • Reported: UML 2.4.1 — Fri, 5 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML2.5: clarification about the semantics of redefinition

  • Key: UML25-468
  • Legacy Issue Number: 18132
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    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))

    • The OCL constraint does not take into account the structured classifier's inherited roles.
    • The English constraint description is ambiguous whether inherited roles are to be included or not.

    2) The structured classifier clause does not adequately explain the semantics of redefining parts and connectors.

    For structured classifiers with inherited parts and/or connectors and redefined parts and/or connectors, there are two views of a given structured classifier:
    The abstract syntax view which retains the abstract syntax distinction between a redefining element and a redefined element.
    The semantics view where all occurrences of a redefined element are replaced by its redefining element.

    Ed's message below explains the distinction between these two views.

    3) More generally, the distinction between the abstract syntax view & the semantics view needs to be addressed for all kinds of redefineable elements; particularly those where the semantics of redefinition can have a significant impact on UML structure and behavior diagrams, including but not limited to:
    Class diagrams
    State machine diagrams
    Activity diagrams
    Interaction diagrams
    Etc

  • Reported: UML 2.4.1 — Tue, 2 Oct 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Part 1 of the issue was handled by resolving 18697. Parts 2 and 3 were handled by resolving 18650.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Lifeline has no type.

  • Key: UML25-467
  • Legacy Issue Number: 18127
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    Lifeline has no type. Type comes from ConnectableElement it represents.

    That means, we must have "fake" property created for every call to static operation (one per class).

    Should it be property of Interaction? Or should it be property of context Classifier? This is an issue.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 7621

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Table B.1 UML Keywords p 778 - Use of # in Semantics col

  • Key: UML25-466
  • Legacy Issue Number: 18124
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Expressions such as visibility <> #public are not clear (I suppose this is OCL) and should be explained. Also the of isRelative = true (w/o the #) appears inconsistent

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    We can tidy up the semantics column in the table in Annex C with the following fixes:
    1. Replace enumeration literals denoted with hash signs by properly qualified names - so #public becomes
    VisibilityKind::public (this resolves 7426).
    2. Remove the qualification from property names - the qualification is obvious from the metamodel
    element column.
    3. Replace BehavioredClassifer::self.oclIsKindOf(StateMachine) by StateMachine (this resolves 18117).
    4. Replace the semantics for apply by ProfileApplication (this resolves 18417)
    5. Make a number of other changes to improve consistency and correctness.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: B.4.4 State Shapes P. 752 - State List Limitations

  • Key: UML25-451
  • Legacy Issue Number: 18106
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    State lists are not limited to no triggers
    See Figure 14-13 and Figure 14-14.

    They are limited to no effects, though I don't see why

    Also this does not cover Figure 14-13, which has the transition F going back to the original state. This can't be modeled as transition to a junction pseudostate. Either transition F is not legal for a state list, or this paragraph is overly restrictive.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Remove the text saying state list have no triggers. The effect limitation is defined by the state machine
    chapter and only restated in Annex B. However, there are other errors in the description of the underlying
    model, so the text should refer to the state machine chapter to reduce redundancy.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: B.2.4 P. 739 - confusing model and diagram

  • Key: UML25-450
  • Legacy Issue Number: 18105
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Is there a model in the diagram?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18104

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Table 21-1 PrimitiveType semantics Real P. 726 - IEEE 754

  • Key: UML25-441
  • Legacy Issue Number: 18091
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Should we be point to IEEE 754 the well-known standard (754-1985 or 754-2008) or
    the newer ISO/IEC/IEEE 60559:2011 (with identical content to IEEE 754).
    I would imagine that getting our spec through the ISO process would be easier if we point to the ISO standards

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The point about smoothing ISO acceptance is well taken. Text changed to reference the more recent standard
    with a note that it is identical to IEEE 754 so that experienced readers will recognize that the transition make
    no substantive change.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 21.1 Summary P. 726 - Missing header

  • Key: UML25-440
  • Legacy Issue Number: 18090
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The diagram of the model should be in a separate section called "21.2 Model", cf 22.2.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Figure 18-3 Example Extend p.689 - Circle on comment "anchor" not standard

  • Key: UML25-438
  • Legacy Issue Number: 18084
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    This notation, using the circle at the end of the line is not indicated elsewhere. As it is, it appears to be only used in extension conditions?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Fix it. The same problem occurs in 18.11. The problem is caused by the Pavel Hruby stencil.
    This also resolves issues 9017 and 9362.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.1 Summary p 685 - emergent behavior

  • Key: UML25-437
  • Legacy Issue Number: 18083
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the spec, emergent is a special term with its own definition (not exactly the term as used outside the specification)

    The different uses of the term should be made conforming.

    1) emergent behavior as in 13.1
    vs
    2) emergent behavior as in 13.2.3 (2x), 13.4, or 18.1.1
    vs
    3) Emergent Behavior as in 17.1.4

    It should certainly be in the index.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17965

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Table 21-1 String P. 726

  • Key: UML25-445
  • Legacy Issue Number: 18095
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    'computational language expression' and 'OCL expression' are almost the same. 'name' is not mentioned.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The similarity of “computational language expression” and “OCL expression” is harmless here, and a computational
    language expression might be many thing dissimilar to and an OCL expression. For example, a COBOL language
    fragment would qualify as a computational language expression but certainly would not qualify as anything even close
    to an OCL expression. The reference to ‘name’ is unclear, and thereby, ignored.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Table 21-1 P. 726 - Title of table not great

  • Key: UML25-444
  • Legacy Issue Number: 18094
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Again not semantics. Suggest "PrimitiveType Domains".
    [If it defined semantics, it would define how many Boolean instances there may be.]

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Ok, we can fix this one harmlessly

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 21.2 Semantics P. 726 - Subsection title

  • Key: UML25-443
  • Legacy Issue Number: 18093
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    This is an unfortunate title for a subsection that defines no semantics. Perhaps unavoidable for auto-generated consistency.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The existing title seems reasonable enough here, even if the contents are not precisely semantics.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Table 21-1 PrimitiveType semantics Real P. 726 - Real Number representation

  • Key: UML25-442
  • Legacy Issue Number: 18092
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current Text: Typically an implementation will represent Real numbers using a
    Suggested Text: Typically an implementation will internally represent Real numbers using a
    We already have a standard for Real Literals

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Suggested change made

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Figure 21-3

  • Key: UML25-448
  • Legacy Issue Number: 18098
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Class boxes in close proximity should generally have the same height, width, and font size

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Figure 21-3 contains a single class box.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Table 21-1 P. 726 - Row ordering

  • Key: UML25-447
  • Legacy Issue Number: 18097
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    What is the row ordering rationale? Suggest alphabetical order, else increasing domain size order.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The table is only 5 items long. No one will be confused by the existing ordering and lookup is easy since the entire
    table occurs on a single page.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Table 21-1 Unlimited Natural P. 726 - Infinity

  • Key: UML25-446
  • Legacy Issue Number: 18096
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The infinity value was called 'infinity' in UML 2.3 and 2.4. It is called 'unlimited' in OCL. It is called 'unlimited' in 8.2.4. Introducing the new term 'unbounded' seems undesirable, particularly in view of the familiarity and appropriateness of the mathematical concept of 'infinity'. [OCL should change to 'infinity'. UML Integer should grow to include +/- infinity to eliminate the inconsistency wrt Real/UnlimitedNatural.]
    Suggest replace 'unbounded' by 'infinity'

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue was discussed at length by the FTF. It was concluded to leave things as they are in the specification.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Figure 20-4 and accompanying text P. 719 - InformationItem can represent multiple types?

  • Key: UML25-439
  • Legacy Issue Number: 18089
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The way you've documented this, it's unclear whether a informationItem can represent both other informationItems and concrete Classifiers.
    Current text: InformationItems can represent other InformationItems or concrete Classifiers.
    Suggested Text: InformationItems can represent other InformationItems and concrete Classifiers.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Reword as suggested

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: B.2.3 P. 738 - confusing model and diagram

  • Key: UML25-449
  • Legacy Issue Number: 18104
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Is there a model in the diagram?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    If this refers to the phrase “model in Figure” referring to the metamodels figures, we could change it to “model shown
    in Figure”, but no one will be confused by the current wording.
    This resolves also 18105.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Annex C Keywords p 777 - Capitalization of «trace»

  • Key: UML25-456
  • Legacy Issue Number: 18113
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Throughout the spec, «trace», is indicated to be standard profile stereotype. However in the list of standard profile stereotypes, it is given as «Trace». It is also given as «Trace» in the table of Keywords here in Annex C.
    What is the correct capitalization?
    The document needs to be consistent

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18454

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Annex C Keywords P. 777 - Previously unmentioned constraints given in Keywords Annex

  • Key: UML25-455
  • Legacy Issue Number: 18112
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The first paragraph gives a number of constraints on model element names, in particular stereotypes. I don't believe this is mentioned in either the NamedElement description or the Stereotype description. I don't think this is a constraint that should be left to an annex, if indeed it should exist: the EJB profile example in figure 12-19 has an Entity stereotype that extends Component as does StandardProfile.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The main problem here is that the “standard stereotypes” are identified as keywords. This gives them
    an undeserved primacy. They should have exactly the same privileges as any user-defined stereotypes:
    which means they should be removed from Annex C altogether. The constraint on stereotype names is
    already defined by name_not_clash in Clause 12, the notation for stereotypes is defined in Clause 12, and
    the standard stereotypes themselves are defined in Clause 22. They don’t belong in Annex C at all.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: B.6 UMLILabel Constraints. P 766 - Use Case Oval.

  • Key: UML25-453
  • Legacy Issue Number: 18109
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    How are use case ovals (and their titles) handled? As too model elements?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There are two diagram elements because labels are separate from the diagram elements they label, see Annex B.2.4
    (Labels) in the Beta 1.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: B.6 Classifier Description UMLInheritedStateBorderKind [Enumeration] Literals p 763

  • Key: UML25-452
  • Legacy Issue Number: 18108
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Title: Specification of color
    Description: This is inconsistent with the idea that UML does not prescribe color for notations.
    Proposed Resolution: give a literal of Shaded or Hatched

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The Beta 1 has an enumeration that does not include colors. This portion of the model was changed in 18650, but still
    does not include colors.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Table B.1 UML Keywords p 778 - Keywords should be in index

  • Key: UML25-458
  • Legacy Issue Number: 18116
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Every keyword should be in the index. Actually none of them are indexed to this location. Some keywords don’t appears in the index at all.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18118

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Annex C Keywords p 777 - Capitalization of «create»

  • Key: UML25-457
  • Legacy Issue Number: 18114
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Throughout the spec, «create», is someimes spelled with an initial cap and sometimes not, indicated to be standard profile stereotype. However in the list of standard profile stereotypes, it is given as «Create». It is also given as both «Create» and «create» in the table of Keywords here in Annex C.
    What is the correct capitalization?
    The document needs to be consistent

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18454

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Index p. 796 among others - Index items with only one page

  • Key: UML25-464
  • Legacy Issue Number: 18122
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    I think there are few items that should appear only once in the index.

    For example, look at isTabbed. it appears in the index with a page # of 769 which is where the formal classifier description appears. However, isTabbed also appears on page 751 where the field is described.

    as another example, look at isSynchronous which is indexed from page 527 the formal areas, but isSynchronous is defined on page 479.

    It is also used on page 672

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18118

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Index p 795 - Index of "is"

  • Key: UML25-463
  • Legacy Issue Number: 18121
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Why would "is" be in the index. "Is" is not a UML specific term.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18118

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Index

  • Key: UML25-460
  • Legacy Issue Number: 18118
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Neil Capey)
  • Summary:

    Entries don't hyperlink back to the main document (this is a show stopper for me).

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The SMSC has determined that OMG specifications should not contain an index

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Annex C Keywords P. 780 - Bizarre definition of statemachine

  • Key: UML25-459
  • Legacy Issue Number: 18117
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The keyword statemachine has semantics "BehavioredClassifer::self.oclIsKindOf(StateMachine)". Surely the semantics should just be "StateMachine" with a separate keyword for ProtocolStateMachine.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18124

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location B.6 UMLStateShape statelist p 770 - StateList Limitations

  • Key: UML25-454
  • Legacy Issue Number: 18111
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    State lists are not limited to no triggers
    See Figure 14-13 and Figure 14-14.

    They are limited to no effects, though I don't see why

    Also this does not cover Figure 14-13, which has the transition F going back to the original state. This can't be modeled as transition to a junction pseudostate. Either transition F is not legal for a state list, or this paragraph is overly restrictive.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18106

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Index p 793 - emergent behavior

  • Key: UML25-462
  • Legacy Issue Number: 18120
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the spec, emergent is a special term with its own definition (not exactly the term as used outside the specification)

    The different uses of the term should be made conforming.

    1) emergent behavior as in 13.1
    vs
    2) emergent behavior as in 13.2.3 (2x), 13.4, or 18.1.1
    vs
    3) Emergent Behavior as in 17.1.4

    It should certainly be in the index.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17965

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Index Mis. - Missing terms in the Index

  • Key: UML25-465
  • Legacy Issue Number: 18123
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    'alphabet' missing
    'Boolean' missing
    'Character Set' missing
    'false' missing
    'floating point' missing
    'Integer' missing
    'infinity' missing
    'OCL' missing
    'OCL expression' missing
    'primitive' missing
    'PrimitiveType' reference to Section 21 missing
    'PrimitiveTypes' missing
    'Real' missing
    'String' missing
    'true' missing
    'unbounded' missing
    'Unicode' missing
    'UnlimitedNatural' missing

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18118

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Type: Structural - Location Index p 790, 794,

  • Key: UML25-461
  • Legacy Issue Number: 18119
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( Neil Capey)
  • Summary:

    Short index entries: alt, in, and is are not formatted corrected.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18118

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 15.5.1 - typo

  • Key: UML25-394
  • Legacy Issue Number: 18014
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Detail; the word used is not a word, "produceas", perhaps what is wanted is "as"

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Figure 15.57 page 426

  • Key: UML25-393
  • Legacy Issue Number: 18013
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Detail:
    Explain how the exception works with the other out parameter.
    Should Accepted Computers also be streaming?
    If not, under what circumstances are the AcceptedComputers released?
    Without an exception, how would this stop?
    Does the AcceptedComputers only release when rejectedcomputers is raised and handled; otherwise when would it be released?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This example is problematic a couple of ways. First, the fact that the input parameter is streaming would,
    indeed, seem to indicate that the outputs should be streaming. However, it is not allowed for a parameter to
    be both isStream and isException (constraint Parameter::stream_and_exception). Second, the description of
    example implies that computers are sorted into rejected and accepted. However, in Subclause 15.2.3 it states
    “An output posted to an exception Parameter precludes outputs from being posted to other output Parameters
    of a Behavior.” So having any rejected computers would preclude having any accepted computers.
    The intent of the examples in Subclause 15.4.5 are simply to illustrate the use of ActivityParameterNodes,
    including for streaming and exception Parameters. However, the examples should do this in a way that
    makes sense.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 17.2.3 Semantics Interaction Fragments p 607

  • Key: UML25-399
  • Legacy Issue Number: 18023
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Title: Reference to “InteractionOperator” should instead say “InteractionOperand”
    Description:
    current text
    An InteractionFragment may either be contained directly in an enclosing Interaction, or may be contained within an InteractionOperator of a CombinedFragment,

    Discussion:
    In that sentence, “InteractionOperator” should be changed to “InteractionOperand.” The InteractionOperand metaclass has an association end “fragment : InteractionFragment.” An interaction operator, on the other hand, is simply an attribute of a combined fragment; it has no association with an interaction fragment.

    Proposed Resolution:
    Change “InteractionOperator” to “InteractionOperand” in that sentence.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In that sentence, “InteractionOperator” should be changed to “InteractionOperand.” The InteractionOperand
    metaclass has an association end “fragment : InteractionFragment.” An interaction operator, on the other
    hand, is simply an attribute of a combined fragment; it has no association with an interaction fragment.
    Change “InteractionOperator” to “InteractionOperand” in that sentence.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

17.1.5 Interaction Diagram Variants p 607

  • Key: UML25-398
  • Legacy Issue Number: 18021
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    What is the rationale for making Timing Diagrams optional for tool compliance?

    Description:
    This clause states, “Conformant UML 2.5 tools are not required to implement Timing Diagrams.” UML 2.5 takes the bold step—which I favor—of eliminating the formal compliance levels, and then carves out caveats in the fine print. What is the rationale for making Timing Diagrams part of the UML spec., but then stating that they’re optional for tool compliance?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Most existing implementations do not implement timing diagrams, so this recognizes established practice.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p 484 - Exception store

  • Key: UML25-397
  • Legacy Issue Number: 18019
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    1) Makes sense to have the notation for an exception store to be a triangle
    2) The left most action on this diagram is an exceptionhandler.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is on Figure 16.19 in Subclause 16.3.4, under “Pin Annotations”. The triangle notation here is on a Pin
    corresponding to a Parameter with isException = true, not to a “store” for a raised exception. Therefore, the leftmost
    action is not an exception handler and the arrow is just a normal ObjectFlow.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Figure 15-23 p.411

  • Key: UML25-396
  • Legacy Issue Number: 18017
  • Status: closed  
  • Source: Alion Science and Technology ( Jim Logan)
  • Summary:

    Figure 15-23 shows streaming activity edges--are those control flows or object flows? I don't think control flows can stream, and these activity edges don't look like object flows to me.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Figure 15-23

  • Key: UML25-391
  • Legacy Issue Number: 18007
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Use

    {stream}

    not [stream]

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 357 StateMachine Redefinition

  • Key: UML25-390
  • Legacy Issue Number: 18005
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    StateMachine Redefinition Notation
    As far as I remember, this is a new specification in UML 2.5. The semantics of redefining state machine is clear. I find it rather confusing is the notation. When you redefine a generalized state machine, you typically do not want to redraw the whole state machine. The proposed notation means that the whole state machine must be re-drawn with the added modeling elements.

    Also, this notation supports only the addition to the generalized state machine, but not the deletion or modification of the generalized state machine

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 338 Transition execution sequence

  • Key: UML25-389
  • Legacy Issue Number: 18004
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Transition execution sequence
    In this sequence, missing is the transition action. When does the action associated with a transition execute?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18003

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 338 Transition execution sequence

  • Key: UML25-388
  • Legacy Issue Number: 18003
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Transition execution sequence
    In this sequence, missing is the transition action. When does the action associated with a transition execute?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add the missing item in the list that describes the transition execution sequence.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Figure 15-63

  • Key: UML25-395
  • Legacy Issue Number: 18015
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Detail:
    Unclear why this Alternative ExceptionHandler notation requires pins on both ends, when the standard notation only has a pin on one side. Perhaps pins should always be there, or never be there.

    The description just has the zig-zag adornment on a straight line and does not mention the pins

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The diagram is incorrect.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 337 Conflicting Transitions

  • Key: UML25-387
  • Legacy Issue Number: 18002
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Clarification of conflicting transitions
    This requires clarification. So, does this mean that conflicting transitions are not allowed? Sometimes conflicting transitions can only be identified at run time, for example, in the case of guarded transitions.

    The following paragraph clarifies some of the ambiguity, but not all of it. Still, the case when two transitions are at the same nesting level is still ambiguous.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 9840

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Page 413, 15.3.2 Abstract Syntax Control Nodes Figure 15-26

  • Key: UML25-392
  • Legacy Issue Number: 18008
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Multiplicity Limitations on DecisionInputFlows

    It does not seem logically necessary that a particular ObjectFlow can only connect to [0..1] DecisionNodes. Why can't more be connected?
    For example, the same ObjectFlow could be used in multiple swimlanes.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 337 Conflicting Transitions

  • Key: UML25-386
  • Legacy Issue Number: 18001
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Explain how conflicts arise
    I suggest to add text to explain that this happens in the case of higher transition exiting a composite state machine or a state that has regions

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

What is “Intentionally Not specified”?

  • Key: UML25-317
  • Legacy Issue Number: 17898
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The precise lifecycle semantics of composite aggregation is intentionally not specified.” (and two following sentences)

    [AC] Is it explained somewhere in the spec what is the meaning of the “intentionally not specified” expression? Not by bad intentions, I suppose, but the reader may wonder why.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This topic is introduced in clause 2, Conformance. Clarify the text to include the phrase “intentionally not
    specified”.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

What is aggregation

  • Key: UML25-316
  • Legacy Issue Number: 17897
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Composite aggregation is a strong form of aggregation that requires a part (see 11.2.3) instance be included in at most one composite instance at a time.”

    [AC] It could be also useful to explain in general terms what an aggregation (whether shared or composite) is.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Explain aggregation better

  • Updated: Fri, 6 Mar 2015 20:59 GMT

inout parameters and effects

  • Key: UML25-311
  • Legacy Issue Number: 17891
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Problem: 9.023
    Severity: minor
    Type: clarification
    Location: 9.4.3 p 118
    Title: inout parameters and effects
    Description:
    Current Text:
    Only in and inout Parameters may have a delete effect. Only out, inout, and return Parameters may have a create effect.

    1) What is passed out for a deleted inout Parameter
    2) What happens to the input if a create effect is applied to an inout Parameter

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue arises from a mistaken impression that an inout parameter requires the same value to go in and
    out. Correct the text to avoid giving this impression.
    This also resolves 18759.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Effect Intent

  • Key: UML25-310
  • Legacy Issue Number: 17890
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The effect property may be used to declare additional indications of the effect on values passed in or out of a Parameter. It is a declaration of the modeler's intent, and does not have execution semantics: the modeler must ensure that the Parameter has the stated effect.”
    [AC] The implementation, not the modeler, must ensure the effect.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17584

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Return Parameter order

  • Key: UML25-308
  • Legacy Issue Number: 17888
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “A single Parameter may be distinguished as a return Parameter.“

    [AC] This sentence should be placed after the following one, and made clearer. I guess its meaning is “Only one Parameter may be marked as return

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Yes, it needs rewording and moving. This also resolves 17889.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Default value of readonly should be referenced

  • Key: UML25-307
  • Legacy Issue Number: 17887
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “If a StructuralFeature is marked with isReadOnly true, then it may not be updated once it has been assigned an initial value. Conversely, when isReadOnly is false, the value may be modified at any time.”

    [AC] I would say that when isReadOnly is not marked (i.e. is false, that is the default, see page 163) then the values can be modified.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Parameter Sets

  • Key: UML25-313
  • Legacy Issue Number: 17893
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    AC] The last two paragraphs in the 9.4.3 section are about ParameterSets. They are really unclear to me. I guess ParameterSets are intended to be only defined and used when an alternative exist, but an example would be in my opinion very useful.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There is further explanation and examples in 16.3. Add a forward reference to it.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

isException and direction and effect

  • Key: UML25-312
  • Legacy Issue Number: 17892
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current text: The isException property applies to output Parameters

    1) Does this mean that isException can apply to inout parameters?
    2) Should isException always have effect=create?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    1) No - this is excluded by Parameter::not_exception
    2) No. Firstly, effects are optional. Secondly, there seems no more reason to put constraints on the effect of an
    exception parameter than on any other out parameter.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.5.3 p 122 In the common case

  • Key: UML25-320
  • Legacy Issue Number: 17901
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    Suggest: In the specific case

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Simplify the explanation to remove statements about what is commonly done.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.5.3 p 121 Why not all empty

  • Key: UML25-319
  • Legacy Issue Number: 17900
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    If only one instance has all values with the isID true to be empty, what’s the problem.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    I’m not sure there is a problem, and because the spec intentionally leaves this implementation-independent,
    it seems an unnecessary restriction - maybe there is some technology for which one instance might validly
    have an empty ID.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Use isReadOnly default

  • Key: UML25-314
  • Legacy Issue Number: 17895
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “A read only StructuralFeature is shown using

    {readOnly} as part of the notation for the StructuralFeature. This annotation may be suppressed, in which case it is not possible to determine its value from the diagram. Alternatively a confirming tool may only allow suppression of the {readOnly}

    annotation when isReadOnly=false. In this case it is possible to assume this value in all cases where

    {readOnly}

    is not shown.”

    [AC] In the metamodel, isReadOnly=false is the default. If nothing is shown, the default should be assumed, I suppose

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The original text is quite clear about what it means if nothing is shown. Still, in an effort to address whatever
    the issue is, make it clear that false is the default, and fix the typo for “conforming”.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Redefinition does not allow for overloading

  • Key: UML25-315
  • Legacy Issue Number: 17896
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Feature redefinitions may either be explicitly notated with the use of a

    {redefines <x>}

    property string on the Feature or implicitly by having a Feature with the same name as another Feature in one of the owning Classifier’s more general Classifiers. In both cases, the redefined Feature shall conform to the compatibility constraint on the redefinitions.

    By allowing reuse of the name to cause redefinition, you prevent overloading. A class should be allowed to more than one operation with the same name with different argument lists.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    We should be more precise and require a compatible signature as well as the same name

  • Updated: Fri, 6 Mar 2015 20:59 GMT

What is “Intentionally Not specified”?

  • Key: UML25-318
  • Legacy Issue Number: 17899
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “A Property may be marked, via the property isID, as being (part of) the identifier (if any) for Classifiers of which it is a member. The interpretation of this is left open but this could be mapped to implementations such as primary keys for relational database tables or ID attributes in XML. If multiple Properties are marked (possibly...”

    [AC] I would specify “are marked as isID (possibly…”

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Note that the title of this issue is wrong, and really belongs to 17898. This issue is editorial.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Return Parameter pronoun

  • Key: UML25-309
  • Legacy Issue Number: 17889
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Its type is ParameterDirectionKind”.

    [AC] The subject of this sentence should be the Direction property, but the pronoun comes after another sentence, whose subject is differ

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17888

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Two categories is not enough

  • Key: UML25-223
  • Legacy Issue Number: 17767
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Using only 2 semantic categories forces Use Cases into the Behavioral semantics category, which is not appropriate by the definition. An additional category of Intentional, Goal, or Requirement Semantics is needed to cover the Use cases. This is supported by the Use Cases clause not being in the behavior section of the document.

    Making this change will probably required changes to the diagram of diagrams in Appendix A and Figure 6.1 below. However as these are only explanatory (not normative) they should not impact users, except to make it more understandable.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17768

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML Semantics

  • Key: UML25-222
  • Legacy Issue Number: 17766
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The UML semantics are defined in the UML spec. This is confusing.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    A distinction is being made in 6.3.2 between the MOF semantics that apply to the interpretation of the UML
    abstract syntax model by a tool that conforms to that and the semantics of UML models themselves. But
    perhaps this could be better expressed in the first paragraph

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Semantics Areas section not clear

  • Key: UML25-224
  • Legacy Issue Number: 17768
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Figure 6.1 gives some semantic areas and the following paragraphs are intended to describe them. I don't think this is done terribly clearly. In particular the specific terms given in the diagram don't all appear in the text as is (Structural Foundations, Inter/Intra-Object Behavior Base); it's not clear what the middle area actually is as the diagram doesn't name it; and the structure of the paragraphs doesn't match the areas.

    The middle paragraph, "The base behavioral...", is particularly unclear - I don't think the second clause of the first sentence actually makes sense. It also includes a 'Note' that isn't really a note at all since it gives a fundamental property of the behavioral semantics.

    Proposed Resolution:

    Add titles to the diagram to identify the areas, perhaps on the right hand side:
    Higher-level formalisms
    Base behavioral semantics
    Structural semantics

    Make each paragraph correspond exactly to an area in the diagram. This largely means that the middle paragraph should be rewritten to include the actions text and object communication information. (Why not just call the *-Object Behavior Base, "Object Communication"?)

    Split the 'Note' into a separate final paragraph that isn't described as a note, just more detailed information about the nature of UML behaviors.".

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Figure 6.1 was carried over from the UML 2.4.1 specification. It should have been replaced with a figure
    more appropriate to the new text.
    This also resolves issue 17767.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Variants are not defined

  • Key: UML25-413
  • Legacy Issue Number: 18047
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Each UseCase specifies some behavior, possibly including variants, that the subject can perform in collaboration with one or more Actors”.

    [AC] I think the clause “possibly including variants” could and should be avoided, because: a) “variant” is not a term defined in the specification, and could be interpreted differently by different readers
    b) it does not lead to a better explanation of what a behavior specification is.

    However, the clause “possibly including variants” was also included in the 11-08-06 version

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed. “Possibly including variants” is not the language of a normative specification. The variation capabilities
    (include, extend) are specified elsewhere

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Actors need not initiate

  • Key: UML25-412
  • Legacy Issue Number: 18046
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Each UseCase specifies a unit of useful functionality that the subject provides to its users (i.e., a specific way of interacting with the subject). This functionality, which is initiated by an Actor, must always be completed for the UseCase to complete.”

    [AC] I think the clause “which is initiated by an Actor” is wrong, according to the use case theory formulated by Jacobson, where each use case must provide value to an actor, but not necessarily be initiated by an actor, because there are also time-triggered use cases.

    What's more, this clause does not correspond to any constraint in the metamodel. So, even if it was also in the 11-08-06 version, I suggest to remove it

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 685 - Are actors mandatory?

  • Key: UML25-411
  • Legacy Issue Number: 18045
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text: “A UseCase is the specification of a set of behaviors performed by a subject, which yields an observable result that is of value for one or more Actors”
    Other than this and the next paragraph, there is no indication that an actor is mandatory, e.g., no OCL, no relationship on the diagram. Consider updating the Figure 18.1 UseCases to show a relationship between the actors and usecases to make a use case require an actor.

    In addition, this is contradicted by p 686, which says: “UseCases may have associated Actors,”, which seems to indicate that actors are not mandatory.

    So
    • Make the text consistent between 685 and 686
    • Consider updated Figure 18-1 to show at least one actor
    • Consider adding OCL to force at least one actor.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Changing the multiplicity or adding a constraint would be inappropriate because it could break existing
    models, so change the wording.
    This also resolves issues 18079 and 18080

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Pg. 615, Figure 17.4.3: Semantics, Sub-clause: Messages

  • Key: UML25-405
  • Legacy Issue Number: 18034
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    his clause states, “A lost Message is a Message where the sending event occurrence is known, but there is no receiving event occurrence. We interpret this to be because the Message never reached its destination.”
    The semantics described in the second sentence seem unnecessarily strict. Additionally, this interpretation for a lost Message is inconsistent with the interpretation of a found Message described in the next paragraph: “We interpret this to be because the origin of the [found] Message is outside the scope of the description.” The semantics of a lost Message should be similar.

    Proposed Resolution:

    Change the second sentence in the excerpt to read: “We interpret this to be because the destination of the [lost] Message is outside the scope of the description.”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change the second sentence in the excerpt to read: “We interpret this to be because the destination of the
    [lost] Message is outside the scope of the description.”.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Pg. 613, Clause 17.3.4: Notation

  • Key: UML25-404
  • Legacy Issue Number: 18032
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Title: Incomplete grammar for “<lifelineident>” in Clause 17.3.4
    Summary: This clause specifies the following grammar for “<lifelineident>”:

    <lifelineident> ::= ([<connectable-element-name>[‘[‘<selector>‘]’]] [: <class_name>][decomposition]) | ‘self’

    “<class_name>”, however, is too restrictive for the type. A lifeline may represent an instance of an Actor, not just an instance of a Class. In fact, the metamodel, as written, allows a lifeline to represent an instance of any type of BehavioredClassifier. Here are the relationships:

    A lifeline represents 0..1 instances of ConnectableElement.
    ConnectableElement is a type of TypedElement.
    TypedElement has an association with 0..1 instances of Type.
    BehavioredClassifier is a type of Classifier, which is a type of Type.
    BehavioredClassifier has 4 specializations: Class, Actor, UseCase, and Collaboration.

    Therefore, any of these 4 subtypes may serve as the type of the connectable element that a lifeline represents. But only 2 of these make sense in the context of a lifeline: Class and Actor. So there are really 2 problems that need to be resolved. Recommendations provided below

    Proposed Resolution:
    1) The grammar for “<lifelineident>” needs to be expanded to allow for an actor to serve as the type of the connectable element that a lifeline represents, and
    2) A constraint needs to be introduced to allow only two of the four subtypes of BehavioredClassifier to serve as the type of the connectable element that a lifeline represents.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18748

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Pg. 612, Clause 17.2.5 - Minor rewording to Clause 17.2.5

  • Key: UML25-403
  • Legacy Issue Number: 18029
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    This clause states, “The :User sends a message Code and its duration is measured.” I don’t believe it’s meaningful to refer to a message’s duration; neither the Duration metaclass nor the DurationObservation metaclass have an association with the Message metaclass. Rather, the DurationObservation metaclass is associated with 1..2 NamedElements that are the event occurrences on either end of the observation. In the case of a Message, those event occurrences are the “send” and the “receive.” I recommend rewording the excerpted sentence as shown below.

    Proposed Resolution:
    Recommend rewording the sentence as follows: “The :User sends a message Code and the duration between its send and receive occurrences is measured.”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Reword the sentence as follows: “The :User sends a message Code and the duration between its send and
    receive occurrences is measured.”.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Pg. 612, Figure 17.5 - Modify Figure 17.5 to enhance readability

  • Key: UML25-402
  • Legacy Issue Number: 18027
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    The placement of the labels “CardOut

    {0..13}” and “OK” is ambiguous. A reader may confuse which message they are associated with. Also, the non-UML arrow associated with the “TimeObservation” label (outside of the diagram frame) is unnecessarily cluttering the diagram.

    Proposed Resolution: Move the “CardOut {0..13}

    ” and “OK” labels to eliminate the ambiguity. Move the “TimeObservation” label to the right side of the figure to de-clutter the diagram.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Do not agree that the caption placements in Figure 17.5 are ambiguous, especially since a similar caption placement
    is used in Figure 17.3.
    Also, the TimeObservation red arrow pointer is acceptable as it is in Figure 17.5.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 18.1.1 Summary P. 685 - A Subject may only refer to a single system

  • Key: UML25-410
  • Legacy Issue Number: 18044
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “A UseCase’s subject represents the system or systems under consideration to which the UseCase applies.”

    [AC] This addition wasn't in the previous UML version, 11-08-06, where the description was “The subject is the system under consideration to which the use cases apply.”

    I consider the plural “or systems” ambiguous, because it lets the reader think that the subject may refer to more than a single system.
    If we want to say that the subject may be a very complex one, such as a system of systems (and this may be indeed useful in my opinion) we should state this point explicitly.

    So I suggest to go back to the previous formulation, or to state more explicitly that the subject may refer to an arbitrarily complex system

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Reword as suggested.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

General value lifeline Row p 647

  • Key: UML25-409
  • Legacy Issue Number: 18042
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    picture is missing

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Include figure from UML 2.4.1 table

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Table 17.6 entire table p 646

  • Key: UML25-408
  • Legacy Issue Number: 18041
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Detail: Cell boundaries often stepped on by diagrams in 2nd column, partial elements in some cells.

    Example: Frame row page 646

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agree to resize the figures to fit within the cell boundaries of the table

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Pg. 611, Clause 17.2.5: Examples - : Insert “formal” in reference to gates in the “Examples” clause (17.2.5)

  • Key: UML25-401
  • Legacy Issue Number: 18026
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    This clause states, “Finally a fourth message is sent from the ACSystem to the environment through a gate with implicit name out_Unlock.” I recommend inserting the word “formal” in front of “gate” to help readers reinforce the connection to what they’re seeing on the diagram in Figure 17.3.

    Proposed Resolution: Insert “formal” in front of “gate” in that sentence.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Insert “formal” in front of “gate” in that sentence

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 17.2.4 Notation ExecutionSpecification p608 - : Specification of color

  • Key: UML25-400
  • Legacy Issue Number: 18025
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Description: This clause states, “ExecutionSpecifications are represented as thin rectangles (grey or white) on the lifeline.” However, this is inconsistent with the idea that UML does not prescribe color for notations

    Proposed Resolution: In place of references to color, we should stick with the convention of using the terms “hollow” to mean the same color as the diagram background and “solid” to mean the same color as the boundary of the node or the path notation. In the case of overlapping notations (e.g. ExecutionSpecifications), perhaps the spec. can prescribe patterns (e.g. cross-hatch) instead of color.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Close no change, clause 6 defines black grey or white.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: LostMessage Row p 639

  • Key: UML25-407
  • Legacy Issue Number: 18039
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    “the Receiver is either not known, out of scope, or does not happen”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Should clarify along with resolution to 18034

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Pg. 617, Figure 17.4.3: Semantics, Sub-clause: Gates - Replace “formal” with “actual” in Clause 17.4.3

  • Key: UML25-406
  • Legacy Issue Number: 18035
  • Status: closed  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    This clause states, “Gates are matched by name, with a formal Gate matched with a formal Gate having the same name, and with an inner CombinedFragment Gate matched with an outer CombinedFragment Gate having the same name.” The second occurrence of the word “formal” should be replaced with “actual” to be consistent with the idea expressed about CombinedFragment gates in the second part of the sentence, “…inner…matched with an outer…”.

    Proposed Resolution: Replace the second occurrence of the word “formal” with “actual”.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Replace the second occurrence of the word “formal” with “actual”.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Default value for LiteralString

  • Key: UML25-264
  • Legacy Issue Number: 17817
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Why does LiteralString have no default value? suggest the Empty string. Discussion:
    If the answer to this relates to problem 8.001, then a detailed explanation is required in the spec.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The real question is why some LiteralSpecifications have a default value, more than why LiteralString does not. The
    only reason that certain LiteralSpecifications still have default values in UML 2.5 is for backward compatibility with
    the UML 2.4.1. In particular, removing default values for LiteralInteger and LiteralUnlimitedNatural would have a
    significant effect on how multiplicity bound are serialized in user models.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Optional String Multiplicity

  • Key: UML25-263
  • Legacy Issue Number: 17816
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Why is the multiplicity for String include 0, but the multiplicities for the other literals do not? LiteralString should be as optional as LiteralBoolean

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    LiteralString::value has a multiplicity of 0..1 in UML 2.5 for no other reason than to maintain backward compatibility
    with the UML 2.4.1 metamodel, which was a goal for UML 2.5. A LiteralString with no value essentially represents
    a string of “no characters” and so is equivalent to a LiteralString whose value is the empty string.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Excessive null checks

  • Key: UML25-256
  • Legacy Issue Number: 17808
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    There are lots of checks for whether lowerBound() and upperBound() are null in various operations. However when would either of those operations return null? And if either of them did, wouldn't it just be invalid?

    Source: dave.hawkins@oracle.com

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 13992

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Single and set of aren't really parallel

  • Key: UML25-255
  • Legacy Issue Number: 17806
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Original:
    that a single or a set of model Elements requires

    Proposed Resolution:
    that a single model Element or a set of model Elements requires

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the suggestion. (This text appears in the description of the Dependency class.)

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing a

  • Key: UML25-252
  • Legacy Issue Number: 17802
  • Status: closed  
  • Source: Oracle ( Dominique Poudret)
  • Summary:

    "attached to set" should read "attached to a set"

    Proposed Resolution:

    Add the missing "a".

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The phrase “attached to set” does not seem to appear anywhere in the UML 2.5 beta document. Perhaps the issue was
    based on review of an earlier version.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

inconsistent spacing on diagram

  • Key: UML25-251
  • Legacy Issue Number: 17801
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    First attribute
    purchase : Purchase [*]….
    Second attribute
    account: Account [0..5]

    Inconsistent space between name and “:” distracts from message of diagram
    Source: Michael Jesse Chonoles

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

TypedElement description could be expanded

  • Key: UML25-260
  • Legacy Issue Number: 17812
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description of TypedElement should say something about it representing values, which the Type description implies.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The description of the TypedElement metaclass is sufficient to describe it syntactically. The semantics of TypedElement
    as a representation and its relationship to Type is covered in 7.5.3 (as revised by the resolution to Issue 17797).
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

It seems to me that a relationship requires a minimum of two relatedElements

  • Key: UML25-259
  • Legacy Issue Number: 17811
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It seems to me that a relationship requires a minimum of two relatedElements

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Use of the diamond symbol (?)needs to be explained

  • Key: UML25-254
  • Legacy Issue Number: 17805
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Place in the material explaining the format of the spec.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It already is explained in 6.4.1:
    “If the association end is a composition, this is indicated by a small black diamond adjacent to the name of the end.”
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Instantiate Dependency

  • Key: UML25-253
  • Legacy Issue Number: 17804
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Shouldn't the Car class depend on the CarFactory class? (as the text states) It doesn't seem like the instance of CarFactory depends on instance of Car which the figure suggest

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 11489

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Generalization Relationship to itself?

  • Key: UML25-261
  • Legacy Issue Number: 17813
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Generalization Relationship:
    A subclass of the owning package,
    or a superclass of the owning package or
    Does the owning package have a generalization relationship to itself?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The location referenced in the issue is to the list of literals for VisibilityKind. However, it is not clear what the issue
    is really asking. The only use of the term “generalization relationship” is in the definition of “protected” visibility,
    which says “A NamedElement with protected visibility is visible to Elements that have a generalization relationship
    to the Namespace that owns it.” This means that the Namespace owning the element must be the general Element in
    the generalization relationship (generalization is “to” the general element). However, Generalization is only defined
    for Classifiers, not Packages, so there is no “owning package” here.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Negatively phrased sentence

  • Key: UML25-262
  • Legacy Issue Number: 17814
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Is there some way of saying this clearly?

    Outside the nearest enclosing Package, a NamedElement marked as having package visibility is not visible. Only NamedElements that are not owned by Packages can be marked as having package visibility

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This quoted text leaves out the first sentence of the description of VisibilityKind::package, which is “A NamedElement
    with package visibility is visible to all Elements within the nearest enclosing Package (given that other owning
    Elements have proper visibility).” This is a positive sentence and the primary definition. Given what the semantics of
    this really is, it is not apparent how to say it more clearly.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sentence difficult to read

  • Key: UML25-258
  • Legacy Issue Number: 17810
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current Text
    The query allOwningPackages() returns all the Packages that in which this NamedElement is directly or indirectly contained, without any intervening Namespace that is not a Package.

    Rewrite using simple sentences

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed that the description could be improved

  • Updated: Fri, 6 Mar 2015 20:59 GMT

allNamespace description doesn't match OCL

  • Key: UML25-257
  • Legacy Issue Number: 17809
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The allNamespaces operation is described as "working outwards." However the OCL uses the prepend operation, which produces a sequence that works inwards.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location p 152 Generalization Attributes: IsSubstitutable

  • Key: UML25-338
  • Legacy Issue Number: 17920
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “isSubstitutable : Boolean [0..1] = true Indicates whether the specific Classifier can be used wherever the general Classifier can be used. If true, the execution traces of the specific Classifier shall be a superset of the execution traces of the general Classifier. If false, there is no such constraint on execution traces. If unset, the modeler has not stated whether there is such a constraint or not.”

    [AC] I have always assumed that substitutability is a fundamental characteristic of generalizations, not an option. I may be wrong, of course, but I would like to see in the spec a discussion of this topic. If it is in the spec, I have not found it.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In the beta spec, isSubstitutable is not mentioned in the main semantics clause and should be.
    Generalization, in object-oriented design, implies substitutability in some context. It is not always the case
    that generalization implies substitutability in every possible context. The isSubstitutable property is intended
    to indicate those cases

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location p 153 complete_and_disjoint: Abstract Implication

  • Key: UML25-340
  • Legacy Issue Number: 17922
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    I'm not sure this is correct. i see the logic of saying this, but I can imagine circumstances where the generalization would be complete and disjoint, but the generalization class would be useful to instantiate as a temporary until I determine which one of the subclasses it is.

    Forcing it to be abstract is a coding style limitation, which should not be required

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Actually this constraint was not there in UML 2.4.1 so should not have been introduced, independently of
    coding style discussions.
    In the related examples in clause 9, the superclass is in fact abstract; remove the implication that this is a
    consequence of the generalization set.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location p 153 complete_and_disjoint: Complete vs covering?

  • Key: UML25-339
  • Legacy Issue Number: 17921
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Location p 153 complete_and_disjoint: Complete vs covering?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is a complaint about the fact the complete and covering are synonyms. But they are clearly defined as synonyms
    in 9.7.3 and the notation uses the word complete while the metamodel uses the word covering. We don’t want to
    change either metamodel or notation.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p 145 CallConcurrencyKind [Enumeration - blocks -- > locks

  • Key: UML25-334
  • Legacy Issue Number: 17916
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “guardedMultiple invocations of a BehavioralFeature may occur simultaneously to one instance, but only one is allowed to commence. The others are blocked until the performance of the currently executing BehavioralFeature is complete. It is the responsibility of the system designer to ensure that deadlocks do not occur due to simultaneous blocks.”
    Typo: should be locks.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17915

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p 145 (3X) Detail: simultaneously -- > concurrently

  • Key: UML25-333
  • Legacy Issue Number: 17915
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    These words mean something different. Concurrently would include overlapping calls, simultaneously means at the same instant.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Rephrase to use the word “overlapping” rather than “simultaneous”. Also make the metamodel documentation
    consistent.
    This also resolves 17916.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location p 146 Classifier Description: isAbstract

  • Key: UML25-337
  • Legacy Issue Number: 17919
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “isAbstract : Boolean [1..1] = false
    If true, the Classifier does not provide a complete declaration and cannot be instantiated.”

    [AC] I would remove “does not provide a complete declaration and”, because the completeness of declaration is not the point of abstraction.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed. The semantics of isAbstract are spelled out fully in the main semantics and this should be a summary
    of that

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location p 145 Classifier Description: objects -> instances

  • Key: UML25-336
  • Legacy Issue Number: 17918
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “A Classifier represents a classification of objects according to their Features. Classifiers are related by Generalizations.”

    [AC] Classifiers are also related by other relationships

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This sentence adds no value and simply serves to confuse

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location p 162 two_parameter_sets: Why

  • Key: UML25-343
  • Legacy Issue Number: 17925
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It should be possible to have two parametersset that are the same, but taking different paths in the activity diagram

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Parameter sets can’t have edges linked to them, so it wouldn’t be possible to distinguish paths based on parameter sets.
    A fork is needed after each parameter.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location p 157 isConsistentWith: missing rules

  • Key: UML25-342
  • Legacy Issue Number: 17924
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Even though an operation it has the same # of parameters and the type is the same, does not really make the types match.
    For example, changing effect or unique--> nonUnique would change the “effective” type though not in a way that UML recognizes

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 15499

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location p 154 Association Ends: Instances of multiple classifiers

  • Key: UML25-341
  • Legacy Issue Number: 17923
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    If there can be more than one classifier, there could be more than one structuralfeature with the same name. How are these handled, or notated. They may have different types.
    Could also have two operations with the same name.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This refers to the notation for InstanceSpecification. Qualified names can be used to disambiguate

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location p 162 ParameterSet constraints input: Exceptions and parameterset

  • Key: UML25-344
  • Legacy Issue Number: 17926
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It appears that as Exceptions are not streaming, they must be part of a output ParameterSet. Practically, they may be part of all of the output ParameterSets.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    That’s right. The same exception parameter can be in multiple parameter sets, or in its own parameter set.
    This could be construed as asking for the “input” constraint on ParameterSet to allow exception parameters to be
    non-streaming when outside parameter sets. It’s clearer to require the exception parameter to have its own parameter
    set, to emphasize the exclusion from others, even though it is technically redundant.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location p 145 Classifier Description - objects -> instances

  • Key: UML25-335
  • Legacy Issue Number: 17917
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Objects are not defined in the spec, while instances are

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Subclause 6.3 will define objects, instances and values in alignment with the terminology used by fUML.
    Clause 9 needs to follow this terminology correctly.
    This also resolves 17875

  • Updated: Fri, 6 Mar 2015 20:59 GMT

While-->And

  • Key: UML25-249
  • Legacy Issue Number: 17799
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Too much emphasis on contrast

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is a general stylistic issue that should be up to the author. Where “while” is used, the contrast is intended.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Unclear description of multiplicities

  • Key: UML25-248
  • Legacy Issue Number: 17798
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The first paragraph talks about "cardinalities", but it isn't really clear to which set this cardinality refers. I think the first two paragraphs need to be reworded to talk about a collection of values before talking about cardinalities.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Imports

  • Key: UML25-243
  • Legacy Issue Number: 17793
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    The meaning of access should be described above under the import section

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    As specified in 7.4.4, the notation “«access»” is simply used to denote a private import. The distinction between public
    and private imports is already discussed in 7.4.3.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ElementImport cannot be further imported

  • Key: UML25-242
  • Legacy Issue Number: 17790
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    An imported Element that is publicly visible can be further imported...using either ElementImports..."

    While this is true for PackageImports, it isn't for ElementImports. The ElementImport directly references the PackageableElement so other ElementImports are irrelevant

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Confusing description of types

  • Key: UML25-247
  • Legacy Issue Number: 17797
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description of types isn't terribly clear. There are several uses of "this" and "represents" that aren't clear. The third sentence, "Values..." uses "element" and seems to be repeating the second sentence.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed.
    This also resolves Issues 17796 and 17812

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Note refers to an undiscussed concept

  • Key: UML25-238
  • Legacy Issue Number: 17786
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The sentence "Note that the set..." talks about unqualified names, but there isn't any discussion of what those actually are so the note seems rather out of place.

    Proposed Resolution:

    Change sentence to simply describe the use of unqualified names rather than being a confusing note.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Packageable Elements and Imports

  • Key: UML25-240
  • Legacy Issue Number: 17788
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Why not separate this into two sections. One on packageable elements and the other on imports. They are distinct concepts and belong in distinct subclauses. Under the packageable element subclause, note that elements that are not packageable are generally owned by a type/classifier, such as behavioral and structural features.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The only reason that PackageableElement is introduced in Subclause 7.4.3 is because it is used in ElementImport and
    PackageImport. Any further discussion on the semantics of PackageableElement should appropriately be in Clause 12
    on Package, not in Clause 7.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing word

  • Key: UML25-239
  • Legacy Issue Number: 17787
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "In a template ..., a NamedElement may have an associated ? whose..."

    Is this supposed to be StringExpression?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17601

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing TypedElement - use of the term constrained seems to be circular

  • Key: UML25-246
  • Legacy Issue Number: 17796
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    use of the term constrained seems to be circular. Perhaps delete 'constrained to be'.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17797

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing TypedElement

  • Key: UML25-245
  • Legacy Issue Number: 17795
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Should this figure include a reference from MultiplicityElement to TypedElement, since MultiplicityElement constrains the numbers of values of the TypedElement

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Presumably the reference is to Figure 7.10, the abstract syntax of types and multiplicity elements. The answer to the
    question is “no”. ConnectorEnd is a MultiplicityElement that is not a TypedElement. In other cases, element metaclass
    specializes bothMultiplicityElement and TypedElement, so no association fromMultiplicityElement to TypedElement
    is needed. The element simply is both a MultiplicityElement and a TypedElement.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing OCL

  • Key: UML25-250
  • Legacy Issue Number: 17800
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    No OCL for the rules for calculating the lower value of a multiplicity as given in text in 7.5.4 Notation / Multiplicity Element

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The rules for determining the multiplicity lower bound given in 7.5.4 are not constraints on the metamodel, so they
    have no OCL. Rather, they are rules for mapping the textual concrete syntax for multiplicity to the abstract syntax.
    Thus, the notation “*” does not mean that the multiplicity lowerValue is not given in the abstract syntax, but that the
    lowerValue is explicitly “0” and the upperValue is explicitly “*”. Similarly, a notation such as “2” means that the
    lowerValue and upperValue are both explicitly “2”. (Note that the case of “1” is special since, in the abstract syntax,
    the default for both upper and lower bound is “1”, so neither have to be given explicitly in this case.)
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Packageable Elements and Imports (02)

  • Key: UML25-241
  • Legacy Issue Number: 17789
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    an a package, being a packageable element, be a TemplateParameter? This needs to be explained.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Yes, a Package being a PackageableElement can be the parameteredElement of a TemplateParameter. The semantics
    are as described in general for Templates and TemplateParameters. There are no further semantics to explain.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Incorrect text describing diagram elements

  • Key: UML25-244
  • Legacy Issue Number: 17794
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    "the<RresourceKind>
    "theFacilitySpecification
    theQualificaion
    are all not in the diagram

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18273

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location 13.1 Summary p 305 - Use of the word “emergent”

  • Key: UML25-358
  • Legacy Issue Number: 17965
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    in the spec, emergent is a special term with its own definition (not exactly the term as used outside the specification)

    The different format of the term should be made conforming.

    1) emergent behavior as in 13.1
    vs
    2) emergent behavior as in 13.2.3 (2x), 13.4, or 18.1.1
    vs
    3) Emergent Behavior as in 17.1.4

    It should certainly be in the index.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The uses of “emergent behavior” in 13.2.3, 13.4 and 18.1.1 are consistent with its definition in 13.1. And
    there is no index as such in which the term could be concluded.
    The only remaining issue is 17.1.4, which uses “Emergent Behavior”, as well as a number of other terms, in
    a capitalized form. These seem to be left over references to the “Execution model” that is supposedly to be
    found in Clause 13, but which is no longer there in the UML 2.5 specification. Subclause 17.1.4 is really no
    longer applicable

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Operations p 245 (2X) typo

  • Key: UML25-357
  • Legacy Issue Number: 17946
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Comppnent – > Component

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location Figure 11-23 s p.217 - Instance/roll names

  • Key: UML25-355
  • Legacy Issue Number: 17944
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There is no name for the wheel placing the role of rightFront. However there is a name for the rightRear wheel. The text describing the diagram implies that all the the right wheel instances are unnamed.

    In addition, the tire playing the role of the leftRear and the rightRear have the same name L2, which is wrong.

    Also the constructor is not connected to the instance. See 11.010

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Replace the figure. This also resolves 17945

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location Figure 11-22 s p.216 - Title doesn’t match contents

  • Key: UML25-354
  • Legacy Issue Number: 17943
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current text:
    Figure 11-22 InstanceSpecification describes the return value of an Operation

    The diagram doesn’t show this, it show a dependence on an instance, but not that this the return value of a particular operation.

    The relevant text, 11.4.4 Notation on page 213 says
    A usage dependency may relate an InstanceSpecification to a constructor for a Class,

    The diagram doesn’t connect the instance to the constructor, just to the class.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Replace the figure and change the caption

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Constraints p 193 - Missing constraint?

  • Key: UML25-351
  • Legacy Issue Number: 17938
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    ownedReception + ownedOperation >0

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is suggesting that an interface with no operations or receptions should be disallowed. But such an empty
    interface might be a suitable root for an inheritance hierarchy. There is insufficient justification to introduce such a
    constraint.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location 10.4.4 Notations p.188 - Reception compartment

  • Key: UML25-350
  • Legacy Issue Number: 17936
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Where does the unmentioned reception compartment go?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In fact the notation for Interfaces is the default notation for Classifiers, as described fully in 9.2.4. Rather
    than partially replicating the description, use a reference to the complete specification

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location 10.3.3 Signals p.186

  • Key: UML25-349
  • Legacy Issue Number: 17934
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    I’m not sure “object” is the best word.

    1) Object is methodology based. Prefer using instances
    2) Can the reception of a signal be a static scoped behavior?, therefore being a class not an object

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The word “object” is used pervasively throughout the spec. The point about static is covered by:
    “Where semantics are not explicitly specified for static Features, those semantics are undefined.”
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

10.2.4 Notation p 184. - Enumeration attributes and operations

  • Key: UML25-348
  • Legacy Issue Number: 17933
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current text:
    The attributes and operations compartments may be suppressed, and typically are suppressed and empty.

    What could be in the attributes compartment?

    Could you have operations on an enumeration, such as predecessor, successor ?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 8274

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 10.2.3 Enumeration p. 184: New EnumerationLiterals

  • Key: UML25-346
  • Legacy Issue Number: 17931
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    An Enumeration that specializes another may define new EnumerationLiterals; in such a case the set of applicable literals comprises inherited literals plus locally-defined ones.

    “New” could mean completely new, or it could be redefined, that is, changing the value for an existing literal. Please be clear, specifying which types of changes are allowed

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    EnumerationLiteral is not a subclass of RedefinableElement, so we don’t believe there was ever an intention
    to redefine literals

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 10.2.4 Notation p 184

  • Key: UML25-347
  • Legacy Issue Number: 17932
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    What is the Name of literal compartment?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    We don’t believe that earlier versions of UML explicitly gave this compartment a name, but because we
    have said that a conforming tool may support compartment naming, we ought to give it one. “literals” is the
    obvious choice.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location Figure 11-21 s p.216 - Instance/roll names

  • Key: UML25-353
  • Legacy Issue Number: 17942
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There is no name for the wheel placing the role of rightFront. However there is a name for the rightRear wheel. The text describing the diagram implies that all the the right wheel instances are unnamed.

    In addition, the tire playing the role of the leftRear and the rightRear have the same name L2, which is wrong.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Replace the figure.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location Figure 11-23 s p.217 - Instance/roll names (02)

  • Key: UML25-356
  • Legacy Issue Number: 17945
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There is no name for the wheel placing the role of rightFront. However there is a name for the rightRear wheel. The text describing the diagram implies that all the the right wheel instances are unnamed.

    In addition, the tire playing the role of the leftRear and the rightRear have the same name L2, which is wrong.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17944

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Figure 11-3

  • Key: UML25-352
  • Legacy Issue Number: 17940
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Figure and title must be on same page

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Wrong Reference

  • Key: UML25-281
  • Legacy Issue Number: 17841
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The notation in Figure 17.5 for timing annotation on sequence diagram does not match the almost identical diagram of Figure 8.5

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Figure 8.5 should match Figure 17.5. Figure 17.5 is the more correct of the two. However, Figure 17.5
    highlights the terms ’duration’ and ’now’ in bold style. This may people mislead to the assumption that
    these terms are kind of predefined keywords, which is not the case. So that could be improved, two.
    This also resolves Issue 10974.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

missing headings

  • Key: UML25-280
  • Legacy Issue Number: 17840
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Missing headings for DurationInterval, TimeInterval, DurationConstraint, TimeConstraint.
    These must be distinct to fully populate the PDF Bookmarks.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Titles under the Semantics parts in the UML 2.5 specification are not intended to necessarily be class names but,
    rather, to label semantic areas being discussed. Actual class names are bookmarked under the Classifier Descriptions
    subclauses.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Min/Max

  • Key: UML25-290
  • Legacy Issue Number: 17867
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    More consistent to use 'temporal distance' rather than range.

    max ... refers to the later time.

    min ... refers to the earlier time.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The basic semantics of Interval are specified in terms of a “range”, and the semantics of the subclasses of Interval are
    also described using the same terms. This seems most consistent, and also avoids confusion with the use of “temporal
    distance” in the discussion of the semantics of Duration.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Two anonymous invariants

  • Key: UML25-289
  • Legacy Issue Number: 17861
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Two anonymous invariants violates distinguishability.
    Simpler
    inv BehaviorHasResult: behavior <> null impliesbehavior.ownedParameter->size() = 1 and behavior.ownedParameter->forAll(direction=ParameterDirectionKind::return)

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The referenced constraints are not anonymous in the current version of the specification (they are named “one_return_result_parameter”
    and “only_return_result_parameters”. These constraints could, perhaps, be combined more simply into one
    Disposition: Closed - No Change
    Report

  • Updated: Fri, 6 Mar 2015 20:59 GMT

8.6 p 100 isCompatibleWith() ..save space

  • Key: UML25-292
  • Legacy Issue Number: 17870
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Change
    The query isCompatibleWith() determines if this Parameterable element is compatible with the specified parameterable element. By default parameterable element P is compatible with parameterable element Q if the kind of P is the same or a subtype as the kind of Q. In addition, for a ValueSpecification, the type must be conformant with the type of the specified ParameterableElement (which must have a type, since it must be a kind of ValueSpecification).

    to

    The query isCompatibleWith() determines if the self ParameterableElement is compatible with the specified ParameterableElement. A ValueSpecification extends the default that the ParameterableElement P is compatible with ParameterableElement Q if the kind of P is the same or a subtype as the kind of Q. Additionally, the type of self must be conformant with the type of the specified ParameterableElement (which must have a type, as it must be a kind of ValueSpecification).

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 12250

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Save Space

  • Key: UML25-291
  • Legacy Issue Number: 17869
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Consider saving space by listing Diagrams, Generalizations, Specializations on the same line as their title.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The FTF did not agree that this change would be an improvement.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

result() error

  • Key: UML25-288
  • Legacy Issue Number: 17860
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Surely invoking result on a non-behavior is invalid?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The OpaqueExpression::result operation specifies the derivation of the OpaqueExpression::result attribute. There is no
    concept in UML of an attribute having a derived value that is an “error”. The result attribute is optional (multiplicitly
    0..1) and it simply has no value if the OpaqueExpression does not have a behavior, as given by the result operation.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

French

  • Key: UML25-287
  • Legacy Issue Number: 17857
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    I guess you mean something "OCL", but you could mean "French"

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    “French” is perfectly legal to use as a value of OpaqueExpression::language. It is allowable to use natural language in
    the body of an OpaqueExpression and it is encouraged to explicitly record the language used. (This is most commonly
    “English” but could certainly be “French”.)
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Invariant name

  • Key: UML25-284
  • Legacy Issue Number: 17844
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The invariant is unnamed in the OCL snippet, but named in the editorial text.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The constraint has the name “no_expr_requires_observation”, presented in the same way as the name of all other
    constraints in the document.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Improve readability of constraint names

  • Key: UML25-283
  • Legacy Issue Number: 17843
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    IMHO NoExprRequiresObservation is more readable than no_expr_requires_observation which is important since the text may well appear in tool error messages.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    As admitted in the issue itself, this is a matter of opinion. The use of lowercase underscores in the UML metamodel
    is established and consistent, and it does not seem worth it to change it across the entire metamodel on a matter of
    opinion.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Association Descriptions not that useful

  • Key: UML25-295
  • Legacy Issue Number: 17874
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Association Descriptions not that useful

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is an opinion which the document editor does not share.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

IsNull not Boolean

  • Key: UML25-294
  • Legacy Issue Number: 17873
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    IsNull not Boolean

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Presumably this issue is about the isNull operation of ValueSpecification. The definition of the operation is “The query
    isNull() returns true when it can be computed that the value is null.” The implication is that isNull returns true only if
    “it can be computed that the value is null”. In other cases, it always returns false. So the return multiplicity is correct.
    In any case, in practice this operation is overridden by subclasses of ValueSpecification in specific cases in which it
    can be computed (e.g., LiteralNull::isNull returns true).
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Duration Definition

  • Key: UML25-282
  • Legacy Issue Number: 17842
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    "the temporal distance between two time instants "

    is not necessarily true. The value may be derived by an arbitrary computation over the set of observations. Could be three standard deviations.

    Suggest "a temporal distance as a DurationObservation or as a computation over a set of observations

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The suggested change leaves Duration defined in terms of “temporal distance”, but essentially leaves “temporal distance”
    undefined. To have a meaning, a “distance” must be between two things. However it is computed, a Duration
    is always, in the end, by definition, a “distance between two time instants”, the beginning and the end of the Duration.
    Note that this statement in no way requires that the observations used to compute the Duration be limited to just giving
    the beginning and end time instants – the observations are just used in some way to determine those instants and define
    the Duration.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Set--> List

  • Key: UML25-286
  • Legacy Issue Number: 17856
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Location: 8.6 p 94 OpaqueExpression Description

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It would probably be best to say “collection” instead of “set”.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Why is value optional

  • Key: UML25-285
  • Legacy Issue Number: 17853
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Why is value optional

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17816

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Turing Machine lurking paradox?

  • Key: UML25-293
  • Legacy Issue Number: 17871
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Turing Machine lurking paradox?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 12250

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.6.3 Operations p 127 Undefined ?

  • Key: UML25-323
  • Legacy Issue Number: 17904
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    this sounds peculiar.
    Intentionally undefined by the modeler, or by the authors of the specification.
    In think this should say
    The behavior of an invocation of an Operation when a precondition is not satisfied is not defined in UML

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.5.3 p 121 Can’t qualifiers be queries?

  • Key: UML25-322
  • Legacy Issue Number: 17903
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Qualifiers should be able to be queries that return an enumerated type that otherwise meets the criteria for qualifiers. This would allow for different mapping to the set at the other end, that might be situationally determined.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Qualifiers are represented by properties, which might be derived. Derived properties are essentially queries.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.8.4 Notation p 141

  • Key: UML25-330
  • Legacy Issue Number: 17912
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “If the InstanceSpecification is shown using an enclosing shape (such as a rectangle) that contains the name, the ValueSpecification is shown within the enclosing shape.”

    [AC] How would otherwise be possible to show an InstanceSpecification?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It might be a line, representing a link.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.8.3 Semantics p 139

  • Key: UML25-329
  • Legacy Issue Number: 17911
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    and if one classifier is abstract and one is not (and they are not realized by generalization)

    It would seem that if any of the classifiers are abstract, the instancespec only partially describes the instance? This need explanation

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The current text is just confusing. It already explains later on that they may be partial

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.6.4 Notation p 128 Is return a reserved parameter name?

  • Key: UML25-326
  • Legacy Issue Number: 17908
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The return result of the Operation may be expressed as a return parameter, or as the type of the Operation. For example:

    toString(return : String)

    means the same thing as

    toString() : String

    Why is this true. The 1st example, could be interpreted as an operation with a parameter named “return”.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This paragraph is inconsistent with the BNF, ambiguous, misleading, and unnecessary. Delete it.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.6.4 Notation p 127 Simplify description of syntax

  • Key: UML25-325
  • Legacy Issue Number: 17906
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    AC] This section on the syntax of operations is complex in itself, but also too hard to read. Maybe a little more structure could improve its readability. E.g. separate the template operation syntax from the previous part.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18801

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.5.3 p 122 Qualifiers must be enumerated type

  • Key: UML25-321
  • Legacy Issue Number: 17902
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    I believe qualifiers must be constrained to be an enumerated type. For example, can an qualifier be a real number?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Qualifiers can be any type that a property can have. If the type has an infinite range, then the lower bound of
    the qualifier must be 0. This is explained by the note in 9.5.3. However, this note contains the phrase “such
    as enumerated values or integer ranges” - since there is no way in UML to define a type that represents an
    integer range, that phrase needs to be modified to exclude this possibility, which will make Enumerations
    stand out as important.
    Note that we might consider a constraint that a lower bound of one implies an enumerated type, but this
    would unnecessarily exclude the possibilities of typing a qualifier with a PrimitiveType with a fixed set of
    values, or a DataType all of whose parts are finite

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.6.3 Operations p 127

  • Key: UML25-324
  • Legacy Issue Number: 17905
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The bodyCondition for an Operation constrains the return result. The bodyCondition differs from postconditions in that the bodyCondition may be overridden when an Operation is redefined, whereas postconditions may only be added during redefinition.”

    [AC] The concept of bodyCondition is not explained, and I fear it is less known that the concepts of precondition and postconditions, that are explained. On page 158, it is said that only query operations may have a bodyCondition. An explanation would be useful.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It is explained in the sense that it says “The bodyCondition for an Operation constrains the return result.”
    Improve the wording to explain that the bodyCondition specifies the calculation of the result value which
    should satisfy the postconditions

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.7.5 Examples p 135 Political Correctness

  • Key: UML25-328
  • Legacy Issue Number: 17910
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    When you say that the generalization by Gender into woman and man is complete and disjoint you are making a politically sensitive statement. You need a caveat, perhaps as a footnote, acknowledging that you are only using this for sample syntax purposes and not claiming facts about the world.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed about the political sensitivity. This should actually be a blanket disclaimer for the entire specification.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.7.5 Examples p 134 Generalization Sets

  • Key: UML25-327
  • Legacy Issue Number: 17909
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    [AC] Figures 9.23 and 9.24 are, in my opinion, misleading. It seems, based on these examples, that either the generalization set name is shown, or the relative constraints (e.g.

    {incomplete, disjoint}

    ), while both could be shown. Same problem in previous figures, from 9.17 to 9.20

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There is a law of diminishing returns on this particular section of the specification. Rather than investing
    effort on more diagrams, fix this by explicitly stating that any combination of these labels may be shown.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.8.4 Notation p 141 representing the roles vs representing the instances

  • Key: UML25-331
  • Legacy Issue Number: 17913
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    a bit confusing. It says:
    may contain nested rectangles representing the instances playing its roles

    Do you mean
    may contain nested rectangles representing the roles the instance is playing? Please clarify nearby

    Give an example with the roles

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In an instance specification for a structured classifier, the nested rectangles do represent instances playing its roles.
    There are several examples in clause 11, and clause 9 refers the reader to them with a hyperlink. Moving the structured
    examples to clause 9 would make the forward reference problem worse, not better. The current specification text is
    accurate as it stands.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 9.9 Classifier Descriptions Association Ends p 144 Behavioral --> Behavior

  • Key: UML25-332
  • Legacy Issue Number: 17914
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    Correct Typo (done). Also I have doubts about the upper multiplicity.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The typo was corrected before the beta document. The upper multiplicity of BehavioralFeature::method is explained
    in 13.2.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Clarification of imports

  • Key: UML25-237
  • Legacy Issue Number: 17785
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Type: Clarification of imports
    The following are not obvious:
    1) Can a non-package namespace, such as a class, have a package
    import relationship to a package? From the metamodel yes

    2) Can a namespace, of any type, do a element import of a package?
    From the metamodel yes

    3) Can a package do an element import of a attribute?
    From the metamodel yes

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It is not clear why these things are claimed to be “not obvious”. As shown in Figure 7.5 and described in the text of
    subclause 7.4.3, any Namespace (including a Class) can have a PackageImport of any Package and any Namespace
    can have an ElementImport of a Package. In the former case, the the members of the Package are imported, while, in
    the latter case, only the Package is imported.
    A Package cannot import an attribute, however, since attributes are Properties, which are not PackageableElements.
    Per Figure 7.5 and subclause 7.4.3, only PackageableElements may be imported.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Namespace Abstract Syntax incorrect

  • Key: UML25-236
  • Legacy Issue Number: 17784
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    memberNamespace should be readOnly and union. This appears to be wrong in the metamodel.

    Proposed Resolution:

    Update metamodel.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The union annotation is added by the resolution 17172. Having memberNamespace annotated as readOnly is unnecessary
    for a non-navigable, association-owned end.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Add reference to association notation section

  • Key: UML25-230
  • Legacy Issue Number: 17775
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    Suggest adding a reference to the section where association end notations are discussed. When I got to figure 7.1, I realized that no one had yet told me what a ball or a colored diamond on an association end meant. I don't think we can assume that readers will necessarily have enough past history with UML to know all of this stuff without the spec being explicit.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17774

  • Updated: Fri, 6 Mar 2015 20:59 GMT

How does dot notation work

  • Key: UML25-229
  • Legacy Issue Number: 17774
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Does the Dot indicate the owning side or the non-owning side? Some clarification is needed here.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Extraneous Note

  • Key: UML25-227
  • Legacy Issue Number: 17771
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Note starting
    Note that this framework only deals with event-driven,…

    This note interrupts the explanation of the diagram and side-tracks it, and is essentially irrelevant to the main topic.

    Proposed Resolution:
    Split the 'Note' into a separate final paragraph that isn't described as a note, just more detailed information about the nature of UML behaviors.".

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17768

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Sentence does not make sense

  • Key: UML25-226
  • Legacy Issue Number: 17770
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Sentence beginning paragraph
    The base behavioral semantics of UML builds on this structural foundation, addressing both the basic framework of the execution of behaviors and such execution may result….

    The use of both in this sentence prepare the reader for two semi-parallel items. The sentence does not have such.

    Proposed Resolution:
    Redo sentence to discuss the behavioral section of the diagram Figure 6.1

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17768

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Owning Comments

  • Key: UML25-233
  • Legacy Issue Number: 17779
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    If every Element in a model must be owned by some other Element of that model, with the exception of the top-level Packages of the model, then all Comments, as Elements, must be owned. The Root diagram has ownership for comments being optional, owningElement [0..1]

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17776

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Root Abstract Syntax missing adornments/metamodel incorrect

  • Key: UML25-232
  • Legacy Issue Number: 17777
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The ends "relationship", "directedRelationship" (x2) should all be

    {readOnly, union}

    . This appears to be wrong in the metamodel.

    Proposed Resolution:

    Update metamodel.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The union annotation is added by the resolution 17172. Having the ends annotated as readOnly is unnecessary, since
    they are non-navigable, association-owned ends.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Owning Rules

  • Key: UML25-234
  • Legacy Issue Number: 17780
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There should be a constraint that all Elements are owned, except the top element.
    Also, the text refers to models and packages, yet these are not defined yet. Perhaps there should be forward reference to model, and the reference to package should be deleted.
    Source: Sandy Friedenthal
    Discussion:
    Are root packages required to be "models"?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There is already a constraint that all elements must be owned, Element::has_owner (except of Packages, for
    which the underlying mustBeOwned() operation is overridden.
    The word “model” is used in 7.2.3 in a colloquial sense, not as a reference to the specific Model construct.
    It is not the case that root Packages are required to be Models.
    It is agreed, however, that it would be useful to include a forward reference to the Packages clause.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Owning Comments

  • Key: UML25-231
  • Legacy Issue Number: 17776
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    All comments should be owned.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The owningElement property opposite Element::ownedComment is optional. But the Element::has_owner constraint
    enforces the fact that all Comments (as kinds of Elements) must be owned. Having ownedElement for a Comment be
    optional simply allows for the possibility of a case in which a Comment (or some subclass of Comment) may have
    some specialized ownership other than the generic owningElement/ownedComment association (even though there is
    currently no such case in the UML metamodel).
    This also closes duplicate Issue 17779.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Figure 6.1 does not relate to rest of Specification

  • Key: UML25-225
  • Legacy Issue Number: 17769
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Many of the items given in the diagram don't all appear in the text as is (Structural Foundations, Inter/Intra-Object Behavior Base);

    Proposed Resolution:
    Redo diagram using items from the specification or explicitly correlate the items to areas within the spec.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17768

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Can Comments own comments?

  • Key: UML25-235
  • Legacy Issue Number: 17781
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Does this mean that Comments can own Comments? It looks like Comments can annotate Comments, which is not a problem. Can Comments own anything else?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Yes, Comments can own Comments. They cannot own anything else.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

What type of slash?

  • Key: UML25-228
  • Legacy Issue Number: 17773
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    This is a good place to show if it’s a forwards or backwards slash

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Page 330, 331, 333, 14.2.3, Page 347, 14.2.4, Page 375, 14.5 PseudostateKind

  • Key: UML25-367
  • Legacy Issue Number: 17978
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    Title: History State described multiple times
    Summary The History State is described here:
    State history (p. 330)
    Entering a state (p. 331)
    PseudostateKind (p. 333)
    History State Notation (p. 347)
    PseudoStateKind classifier description (p 357).

    Though it is OK to have descriptions in the various predefined sections, it seems that in this case I need to read all places to fully understand the history state.
    On other occasions the wording is slightly different (e.g., containing state-owning state), so that the reader wonders, whether there is a different meaning.
    On page 333 the description of deepHistory is incomplete: It doesn’t describe the default history state. This is described at other places, but not describing it here misleads the reader to think, that only shallowHistory has this feature.

    Proposed Res Reduce the number of places. Focus the description on the purpose of the section, hyperlink to other parts of the description where necessary.

    Source: axel.scheithauer@oose.de

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed: the redundancy is both a maintenance problem and can be confusing due to minor discrepancies
    between the texts. Since the duplicate text in question describes the semantics of the pseudostates, it should
    be retained in the Semantics section (14.2.3) of the StateMachines chapter and removed from the Classifier
    Descriptions section (14.5). It would be convenient to add some kind of hyperlink from the Classifier
    Descriptions entry to the corresponding Semantics entry, but, since the descriptions text is auto-generated
    from the metamodel, this would be rather difficult to achieve technically. However, it is expected that
    readers interested in the semantics of the individual literals will naturally assume that they should refer to
    the Semantics section

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Page 329 States - Stable

  • Key: UML25-366
  • Legacy Issue Number: 17977
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    s the configuration stable if there is a pending deferred event that should be processed?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add clarifying sentence in the section defining what constitutes a stable state.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Page 315 Association ends - Explain about having no nestedClassifier

  • Key: UML25-362
  • Legacy Issue Number: 17971
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    How can it be? What are the consequences. Is this something to be avoided.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is not entirely clear, but it seems to be asking why there is no nestedClassifier property for Behavior.
    However, Behavior is a subclass of Class and it inherits nestedClassifier from Class.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Page 313, 13.2.4 Notation relative

  • Key: UML25-361
  • Legacy Issue Number: 17969
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Title: Relative to what?
    The concept of relative TimeEvent does not make sense unless a base Event is identified. This should be reflected in the metamodel diagrams and definitions. This is often a problem with timers in activity diagrams.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Note: The correct Notation subclause reference is 13.3.4, not 13.2.4.
    In Subclause 13.3.3, under Time Events, it states “Relative TimeEvents shall always be used in the context of a Trigger,
    and the starting point is the time at which the Trigger becomes active.”
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Page 341, 14.2.4 - Example for graphical expression of behavior in states

  • Key: UML25-369
  • Legacy Issue Number: 17981
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The spec says
    “Alternatively, in place of a textual behavior expression the various Behaviors associated with a State or internal Transition can be expressed using the appropriate graphical representation (e.g., an activity diagram)”.
    How would that be shown? As an embedded Activity Diagram in a compartment with the name of the triggers in the left upper corner?

    Proposed Res Add an example or give more details.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Rather than come up with some difficult-to-implement nested diagram solution to this, it seems simplest to
    clarify that the behavior in such cases would be specified in a separate diagram. Add a clarifying statement to the text.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Page 328 Regions 14.2.3 - Text about regions without initial state

  • Key: UML25-365
  • Legacy Issue Number: 17976
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    “No one approach is defined for the case when there is no initial Pseudostate exists within the Region.”
    Proposed Res “What it means if none is defined, is left to the modeler.”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Axel: The main reason for raising issue was, that I think, this is not correct English:
    “No one approach is defined for the case when there is no initial Pseudostate exists within the Region.”
    Bran: Actually, the English is at least formally correct. In fact, the same formulation is used elsewhere in
    the spec (section 13.2.3). However, since it has proven confusing to at least one reader, that wording should
    be changed throughout the spec.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Page 346, State List Notations

  • Key: UML25-371
  • Legacy Issue Number: 17983
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Do State Lists exchange via diagram exchange?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18566

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Page 341, State - More examples needed

  • Key: UML25-370
  • Legacy Issue Number: 17982
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    There are some common combination notation examples that should be demonstrated and explained. That is, internal activities Behaviors compartments and decomposition compartments.
    1) A composite state that also has a compartment for the do/activity, and possibly entry/ and exit/actions
    2) A composition state with a hidden decomposition, with compartments as above.
    3) A composite state, with regions, that also has a compartment for the do/activity, and possibly entry/ and exit/actions, crossing the regions, and compartments that are region-specific.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add one more figure with an example that provides a combination of regions and compartments with an
    explanatory caption

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Page 338, Transition selection algorithm - Maximal Set

  • Key: UML25-368
  • Legacy Issue Number: 17980
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The phrase “maximal set” increases the confusion here. It appears to possibly mean that the possible sets of transitions are evaluated and the maximal set is chosen. The algorithm that is describing indicates a local decision making approach that just chooses the next transition.
    The whole concept of the “set” seems misleading in the light of immediate decisions.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify that multiple Transitions can fire simultaneously for a given event occurrence; remove the confusing
    term “maximal”

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 14.2.1 Summary - Behavior StateMachines for UseCases

  • Key: UML25-364
  • Legacy Issue Number: 17974
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Can we make this possible, explicitly?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The text already mentions that a behavioral state machine can be used for any owned behavior of a BehavioredClassifier.
    It seems inappropriate to single out use cases and not mention all the others. Besides, figure 18.12 explicitly
    shows an example of a state machine associated with a use case.
    Disposition: Closed - No Change
    Report

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: 14.1 Summary p 326

  • Key: UML25-363
  • Legacy Issue Number: 17973
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Can we point to a useful Harel book?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location Behavior Parameters p 307 - Streaming and Multiplicity

  • Key: UML25-360
  • Legacy Issue Number: 17967
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    If there is a minimum multiplicity on a streaming parameter, is it
    1) The min # must be there to start
    2) The minimum # must arrive before it finishes.
    3) If a streaming parameter has a default how does that work?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The semantics of multiplicity on a streaming parameter is described as part of the semantics of CallAction.
    There are no special semantics defined for the defaultValue of a streaming parameter.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location Behavior Parameters p 307 - Optional with default value

  • Key: UML25-359
  • Legacy Issue Number: 17966
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    what happens when an in parameter is optional and has a defaultvalue?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The defaultValue is still evaluated. This could be clarified

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Alterative Scopes?

  • Key: UML25-304
  • Legacy Issue Number: 17883
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    Title: Alterative Scopes?
    current text: “Inherited static StructuralFeatures shall have one of two alternative semantics, within a given execution scope:
    1. The value of the StructuralFeature is always the same for any inheriting Classifier as its value for the owning Classifier.
    2. The StructuralFeature has a separate and independent value for its owning Classifier and for each Classifier that inherits it.”

    [AC] This is not clear to me. Which one of the semantics apply in a certain execution scope?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The question doesn’t really make sense: indicating that the wording does need clarification.
    This also resolves issue 17884.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Multiplicity of 0..0

  • Key: UML25-303
  • Legacy Issue Number: 17882
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Location: p 117 Not handled / discussed

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17881

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location p.112 (9.3 Classifier Templates)

  • Key: UML25-301
  • Legacy Issue Number: 17880
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    [AC] Since this section is (in my opinion) an advanced topic, and a feature of the UML not always used by most practitioners, I would rather move it after the sections about features, properties, and operations

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    We decided as a basic principle to mimimize forward references, and the current organization achieves that quite well.
    Moving this section later would introduce more forward references from Property and Operation.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Incompatible with SysML

  • Key: UML25-300
  • Legacy Issue Number: 17879
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    This is not compatible with SysML, which I believe calls them "constraints" --> Location: 9.2.4 p 110.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    UML 2.4.1 did not specify what the compartment heading was for constraints — it simply said that such a
    compartment is possible

  • Updated: Fri, 6 Mar 2015 20:59 GMT

the parent of a Classifier is not its owner.”

  • Key: UML25-297
  • Legacy Issue Number: 17876
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Note: the parent of a Classifier is not its owner.”

    [AC] This note is not completely clear, in my opinion, maybe because it relates two unrelated concepts (generalization and ownership) without sufficient explanation in the context of this description.

    Furthermore, I could interpret the note in different ways:

    • the parent of a Classifier is not necessarily its owner
    • the parent of a Classifier may not be its owne
      Proposed Resolution:

    Update metamodel.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It is indeed somewhat unclear. Rephrase

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p.116 (9.4.3 Semantics)

  • Key: UML25-302
  • Legacy Issue Number: 17881
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “For each instance of a Classifier there is a value or collection of values for each direct or inherited non-static attribute of the
    Classifier”

    [AC] Again, an attribute may have a value or collection of values in any instance. It has not necessarily one, unless constrained by its multiplicity. In the following sentences is discussed the upper multiplicity, but never the lower one.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Expand the explanation to handle lower bounds

  • Updated: Fri, 6 Mar 2015 20:59 GMT

What is inherited or not

  • Key: UML25-298
  • Legacy Issue Number: 17877
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “When a Classifier is generalized, certain members of its generalizations are inherited, that is they behave as though they were defined in the inheriting Classifier itself.”.

    [AC] This sentence suggests that some members are inherited, some are not. In the following sentence it is explained, as examples, that attributes and operations are inherited. But which are members that are NOT inherited? Are there examples, or, better, rules?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There is a later paragraph in the cited section that says:
    The set of members that are inherited is called the inheritedMembers. Unless specified differently for a particular kind
    of Classifier, the inheritedMembers are members that do not have private visibility.
    This is clear.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Inherited members

  • Key: UML25-299
  • Legacy Issue Number: 17878
  • Status: closed  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “For example, an inherited member that is an attribute has a value or collection of values in any instance of the inheriting Classifier, and an inherited member that is an Operation may be invoked on an instance of the inheriting Classifier.”.

    [AC] An attribute may have a value or collection of values in any instance. It has not necessarily one, unless constrained by its multiplicity.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    A minor point, and pedantically “a collection of values” includes the possibility of no values. Reword

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Redefinable Static attributes

  • Key: UML25-306
  • Legacy Issue Number: 17886
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Are static structuralfeatures redefinavble? Are they redefinable only ounder scope 2?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There are no constraints that say they are not redefinable, so they are. What that means is covered by the sentence:
    Where semantics are not explicitly specified for static Features, those semantics are undefined.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Examples of alternative scopes?

  • Key: UML25-305
  • Legacy Issue Number: 17884
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Can you say more about these options. I don't know but, for example, is #1 Ada and #2 Objective C.
    Some explanatory comment might help.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17883

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Objects?

  • Key: UML25-296
  • Legacy Issue Number: 17875
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It should probably be instances not objects, based on 9.2.3

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17917

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 329 State Configurations

  • Key: UML25-378
  • Legacy Issue Number: 17992
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Title: What state are you in when the entry action is being executed?
    As I remember, this is new in this version (UML 2.5). This line implies that a state is not active until the entry action has been executed and completed (or the entry method has returned). This is also how Umple (try.umple.org) implements state machines. The issue with this choice is that if you query the state machine while the entry action is being executed, the return value will be outdated. This is a concern even if the entry action takes insignificant amount of time.
    For example, what if the entry action code queries the state machine? In that case, the query will return the source state (and not the current state). Here is the example using Umple

    stateMachine {
    State1

    { event1 -> State2; }

    State2 {
    entry /

    {defaultEntryActionMethod();}


    }
    }

    private void defaultEntryActionMathod() {
    if (currentState == State1)

    {.. .. ..}
    if (currentState == State2)
    {.. .. ..}

    }

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This requires a clarification. The revised text below is based on the view that a state machine is always “in”
    some state configuration, even while undergoing a transition. That is, the state machine is “in” a particular
    state as soon as it reaches that state through an incoming transition. This in turn means that any behaviors
    that are associated with that transition have been completed.
    This resolution also resolves issues 17994 and 17995.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 328 Regions - Resolve intentional ambiguity

  • Key: UML25-377
  • Legacy Issue Number: 17991
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    This is an area of intentional ambiguity. Why not just make a choice regarding a region with no start state? I would suggest that UML should allow a region without a start state and go with the second choice "the region remains inactive while the containing state is active."

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The reason this was defined as a variation point is to support the different semantics that were realized in various
    existing state machine realizations (at least those that were of concern when UML 2.0 was being defined). Selecting
    only one variant as the only valid one would be, in effect, a change in the semantics of UML, which would have an
    impact on existing models.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Transition , bottom of page 352

  • Key: UML25-373
  • Legacy Issue Number: 17986
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    What's a Data node? Not defined in the spec?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify the distinction between the two notations and remove the sentence referring to Data node.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: Page 347, 14.2.4

  • Key: UML25-372
  • Legacy Issue Number: 17985
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    Title: state list examples with alternative notation without state lists
    Summary The text on state lists is difficult to understand without a graphical representation of the examples.

    Proposed Res Add corresponding diagram without state list to Figure 14-13

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change diagram 14.13 to include an example for case (b)
    Remove current diagram 14.14, because it adds no new information (it only gives an example for the situation
    shown in 14.13 but with meaningful statenames.
    Add a new diagram 14.14 to show the equivalent statemachine without state lists. Remove Text about history
    states and the corresponding transition in diagram 14.13.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p 378 State Description - What is hidden?

  • Key: UML25-376
  • Legacy Issue Number: 17990
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The concept of hidden in this paragraph is unclear. Certainly any state, including those of behavior StateMachines can be visible to the users. Please add "usually" before the word "hidden" in the 2nd sentence of this paragraph and offer or refer to explanation

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    add clarification

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p 373 outgoing_from_initial - Limitations on guards

  • Key: UML25-375
  • Legacy Issue Number: 17989
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The limitation on not having a guard seems not justified, if we can constrain that the set of guards are covering.
    Please explain or fix.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The reason for not allowing a trigger on an initial transition is because that transition is triggered by the creation
    and/or start behavior action of the state machine’s context object. That is, it is not triggered in the same way as other
    transitions, by the arrival of amessage-based event occurrence. Putting a guard on this transition would allow for the
    possibility that the transition would not be taken if the guard is false, leaving the state machine in an indeterminate
    half-created state. (At that point, nothing further could be done with such a state machine, except to destroy it.) The
    intent of this constraint, therefore, is to ensure that the initial transition is always taken.
    Of course, the ability to branch following creation of the state machine is easily achieved by terminating the initial
    transition on a choice point Pseudostate that has outgoing guarded transitions.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Page 353, 14.2.4 - StateMachine symbols on graphical representations of Transitions

  • Key: UML25-374
  • Legacy Issue Number: 17988
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The spec says that a choice point symbol on a graphical representation of a transition is not part of any Activity. That’s exactly what I expected, since a choice point is not allowed in an Activity. Then it says, that the symbol maps to a choice Pseudostate and uses the same notation. In other words, the choice point symbol maps to a choice point and uses the choice point symbol. Hm.
    What is the difference between a choice point symbol on a transition with textual representation and on a transition with a graphical representation? The same is unclear with state, initial state, merge, and final state symbols. The symbols are the same and mean the same as in normal transitions. The example in figure 14-30 supports this view.

    Proposed Res Explain in more detail. If possible add the corresponding Activity Diagram.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The cited statement is taken out of context, which provides a setting for this seeming tautology. The context here is
    the special graphical notation for transitions, which is distinct from the rest of the state machine notation. Hence, the
    choice point symbol could, for example, be mapped to a conditional statement instead of a pseudostate. By saying
    explicitly that it maps to a choice point pseudostate clarifies this point. The same goes for all the other symbols.
    Hence, it is not as trivial as it sounds.
    In the text that introduces this notation there is a clear statement that this is a unique notation applicable only to
    Transitions (“As an alternative, in cases where the effect Behavior can be described as a control-flow based sequence
    of Actions, there is a graphical representation for Transitions and compound transitions which is similar to the notation
    used for Activities.”). There is also a Note, introduced as part of the resolution to issue 17986, that clearly warns that
    the notation is not an the same as the notation for Activities. It is not clear that any further statementswill help. Adding
    an activity diagram example here would likely only lead to confusion.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 333 FinalState

  • Key: UML25-382
  • Legacy Issue Number: 17996
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Difference between FinalState and state w/o outgoing transition.
    I see no difference between FinalState and any other state without any outgoing transition. I suggest (similar to what we did with Umple) is to delete the object when the FinalState is reached. In the case of regions, all regions must reach a final state before the object is deleted.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    These are actually two separate issues: whether a final state is the same as a state without outgoing transitions and the
    semantics of final states.
    There is a difference between final states and the terminate pseudostate. This is intentional, since final state has a
    local effect within a region whereas terminate has a global effect (in the sense that it terminates the context object).
    Terminate was introduced to allow modelers to explicitly specify when they want to context object to be terminated.
    Adding an implicit version of that capability (i.e., when all regions reached a final state) seems only to add complexity.
    Furthermore, note that the state machine may be invoked through a submachine state, which would most probably
    mean that, in those cases, the implicit termination would likely be inappropriate.
    Those who wish to add such semantics are always free to do so through a profile.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 331 Exiting a State - Clarification of Exiting a State

  • Key: UML25-381
  • Legacy Issue Number: 17995
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    This can be clarified. When does the state machine configuration get updated?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 337 2nd ¶

  • Key: UML25-385
  • Legacy Issue Number: 18000
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    Title: More Non-Determinism
    Similar to my comment earlier on this type of non-determinism

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 336 Compound transitions

  • Key: UML25-384
  • Legacy Issue Number: 17998
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    More than one transitions guarded to be true?
    A known under-specification. For tool developers, it is better to make a choice here. In Umple (since it is a textual notation) we give precedence to the transition that was defined earlier in the sequential text.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The possibility of multiple true guards can never be practically excluded in practice (e.g., guards may involve variables).
    As for how to deal with that situation, UML leaves that up to the tool implementers. There does not seemto be
    a compelling case to define a formal rule, especially since that might cause backward compatibility problems in some
    models (i.e., some tools may have chosen a different way of defining precedence).
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 333 Transitions - How do multiple triggers work?

  • Key: UML25-383
  • Legacy Issue Number: 17997
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    This seems new to me. Does this mean that a Transition can be triggered by more than one event? if so, then what is the priority between them. For example, what if two triggering events for the same transition are fired at the same time? Which event becomes consumed by that transition? What if one of the events is a deferredEvent?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add a clarification statement to avoid confusion

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 330 Deferred Events - Value of Deferred Events

  • Key: UML25-379
  • Legacy Issue Number: 17993
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    I think this is also new specification in UML 2.5. If so, it should be added to the summary of new specifications at the beginning of the document.

    This is a feature with some value. The question is the following. Does this feature brings more value than the complexity it adds to the specification and the tools that supports UML? My view is that such a feature adds more avoidable complexity to the tools. At the same time, the same behavior can be achieved using the already existing UML features. I would vote against this feature in favor of keeping the specifications less complex

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The submitter is mistaken. Deferred events have always been a part of UML state machines.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Location: p. 331 Explicit Entry - Clarification of Explicit Entry

  • Key: UML25-380
  • Legacy Issue Number: 17994
  • Status: closed  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    I would like to note that when entering a composite state, the current configuration of the state machine will not be updated until all entry actions are called, executed, and completed.

    It makes more semantics sense to update the parent state machine right after its entry action is called, and recursively thereafter for all nesting levels.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Unlimited Natural

  • Key: UML25-268
  • Legacy Issue Number: 17822
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    'unlimited' is called 'infinity' in UML 2.4, 'unlimited' in OCL, 'unbounded' in Section 21.The comment that 'unlimited' is not 'infinity' does not make any sense to me. If it is unlimited then any value from 0 all the way to infinity is permissible, so the upper bound is indeed infinity.

    Suggest the mathematically consistent 'infinity' and remove the note.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed that this should be made consistent. Notwithstanding the use of “unbounded” in Section 21, the
    current specification text generally uses the term “unlimited” for “*”, which is also consistent with the name
    of the type UnlimitedNatural. The reason to distinguish this from “infinity” is that “*” is only used to
    represent an “unlimited range”, never as a value resulting from an infinite computation (in the sense that,
    say, +/- infinity are values in certain floating point computation systems).
    This resolution also resolves issue 18442. The proposed resolution to 17798 already removes references to
    “infinite” and uses the term “unlimited” in relation to the discussion of the upper bound of a multiplicity in
    Subclause 7.5.3.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

String concrete syntax is missing

  • Key: UML25-267
  • Legacy Issue Number: 17821
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Specifying a Concrete Syntax requires just that. It must provide a solution to expressing all characters in a predictable fashion. So given the constraint of "..." encapsulation, how are internal " represented? How are Unicode and newlines expressed? Suggest reusing the OCL 2.3 clarification of backslashes. The concrete syntax comprises a sequence of zero or more characters or escape sequences surrounded by single quote characters. The [B] form with adjacent strings allows a long string literal to be split into fragments or to be written across multiple lines.[A] StringLiteralExpCS ::= #x27 StringChar* #x27
    [B] StringLiteralExpCS[1] ::= StringLiteralExpCS[2] WhiteSpaceChar* #x27 StringChar* #x27

    where

    StringChar ::= Char | EscapeSequence

    WhiteSpaceChar ::= #x09 | #x0a | #x0c | #x0d | #x20

    Char ::= x20-#x26 | x28-#x5B | x5D-#xD7FF | xE000-#xFFFD | x10000-#x10FFFF

    EscapeSequence ::= '\' 'b' – #x08: backspace BS

    '\' 't' – #x09: horizontal tab HT
    '\' 'n' – #x0a: linefeed LF
    '\' 'f' – #x0c: form feed FF
    '\' 'r' – #x0d: carriage return CR
    '\' '"' – #x22: double quote "
    '\' ''' – #x27: single quote '
    '\' '\' – #x5c: backslash \
    '\' 'x' Hex Hex – #x00 to #xFF
    '\' 'u' Hex Hex Hex Hex – #x0000 to #xFFFF

    Hex ::= [0-9] | [A-F] | [a-f]

    A minor change could share the syntax definition and define the body as above prohibiting un-escaped usage of the character used as the surrounding quotes.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue statement presumes that characters in a string are encoded as Unicode. However, as a modeling language,
    UML does not presume any specific character set (it is specifically stated in 8.2.4 that “The character set used is
    unspecified.”) Therefore it is not possible to provide specific, standard notation for specific characters, particularly
    unprintable control characters.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

BNF rules allow for a real 0

  • Key: UML25-270
  • Legacy Issue Number: 17824
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    BNF rules allow for a real “0”

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    That is true. After all, “0” is a real number. In fact, the BNF allows any natural-literal to be used as a real-literal.
    The textual syntax for real-literals is provided for the purpose of displaying LiteralReals in a model, and there is no
    requirement that it be unambiguously parsable as a means of entry of literals by a tool.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Notation: Real

  • Key: UML25-269
  • Legacy Issue Number: 17823
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The wording for Real allows '000.9' and '.9' as valid numbers. Permitting redundant leading zeroes is undesirable given the usage of leading zero as octal in some languages. Permitting the omission of a leading zero is also undesirable. The equivalent wording in OCL 2.3 is better but not perfect. "A real literal consists of an integer part, a fractional part and an exponent part. The exponent part consists of either the letter 'e' or 'E', followed optionally by a '' or '-' letter followed by an exponent integer part. Each integer part consists of a sequence of at least one of the decimal digit characters. The fractional part consists of the letter '.' followed by a sequence of at least one of the decimal digit characters. Either the fraction part or the exponent part may be missing but not both."UML and OCL should have compatible definitions.

    What is the concrete syntax for +/- infinity?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Both “000.9” and “+.9” are numerically correct representations of Reals. As a modeling language, it seems that UML
    should allow the same flexibility in literal notation as typical mathematical convention would allow. If a modeler wants
    to write “.9”, it doesn’t seem necessary for UML tools to be required to prevent this. There is no syntax for +/- infinity,
    since these are not values included in the mathematical range of real numbers. Certain floating point implementations
    may include such values, but the concept of Real in UML has intentionally been kept independent of implementation
    standards and, instead, kept as close to the mathematical conception of real numbers as possible (similarly to how
    Integer has previously been handled in UML).
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

LiteralNull semantics

  • Key: UML25-266
  • Legacy Issue Number: 17820
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    This makes no sense to me. The absence of a value is modeled by the absence of a value, particularly given that UML provides no CollectionTypes to model the multiplicity of values.If the upper bound is one, then LiteralNull could possibly be an alternative to a Literal'NotNull', but it isn't an empty set. If the upper bound is greater than one, how are any of the values really represented in UML?If LiteralNull is to be an optional value, it should derive from LiteralBoolean, LiteralReal. etc.

    Suggest delete LiteralNull or redefine it solely for use as the '0' of a [0..1] multiplicity.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 9700

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Default value for LiteralReal

  • Key: UML25-265
  • Legacy Issue Number: 17818
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Why does LiteralReal have no default value?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The only reason that certain LiteralSpecifications still have default values in UML 2.5 is for backward compatibility
    with the UML 2.4.1. When LiteralReal was added in UML 2.5, it was decided not to compound the problem by giving
    LiteralReal a default value. (In addition, no UML tooling yet supported LiteralReal, since it was new, which made
    including a default real value in the UML metamodel difficult.)
    (See also the resolution to Issue 17817.)
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Always non-negative

  • Key: UML25-279
  • Legacy Issue Number: 17839
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Duration is always non-negative value, so re-write text
    “A Duration is a non-negative value, often an integer expression ….

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Subclause 8.4.4 is on notation, so a statement on what whether a Duration is, in general, non-negative is not really
    appropriate there. Indeed, under 8.4.3 Semantics, it says that “UML does not define any specific type or units” that
    a Duration value may have, so whether a Duration is “non-negative” is not actually generally meaningful. The text
    in 8.4.4 is simply saying that a Duration is, notationally, “often a non-negative integer expression”, and, in this case,
    “non-negative” is meaningful, since it specifically modifies the phrase “integer expression”.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Duration

  • Key: UML25-278
  • Legacy Issue Number: 17838
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    What does it mean to have both an expr and an observation?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    According to 8.4.3, under Duration, “The expr may reference the observations associated with the Duration but no
    standard notation is defined for such references.” There are no further standard semantics defined for how observations
    are used in the evaluation of the expr of a Duration.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

set - > list

  • Key: UML25-274
  • Legacy Issue Number: 17830
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    concatenating a set of substrings. concatenating a list of substrings

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed that “list” should be used instead of “set”.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Plural headers when class name is singular

  • Key: UML25-273
  • Legacy Issue Number: 17827
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Title is plural, class name is singular. Should be singular to give clear PDF bookmarks

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Titles under the Semantics parts in the UML 2.5 specification are not intended to necessarily be class names but,
    rather, to label semantic areas being discussed. Actual class names are bookmarked under the Classifier Descriptions
    subclauses.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

body text strings

  • Key: UML25-276
  • Legacy Issue Number: 17832
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    may have a body that consists of a sequence of text Strings should be may have a sequence of body text Strings

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The current wording is technically correct, and it is consistent with similar wording used in the discussion of Opaque-
    Behaviors and OpaqueActions.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

sentence unclear

  • Key: UML25-275
  • Legacy Issue Number: 17831
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    one or subExpressions of it may should be or one of its subExpressions may

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Actually, what was intended was “one or more subExpressions”.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Past vs Present

  • Key: UML25-271
  • Legacy Issue Number: 17825
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    specify computed values is a past tense potentially implying an already computed value. Suggest either specify computable values or specify computation of values

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The use of “computed” as an adjective in the phrase “computed values” does not necessarily imply “past
    tense”, but simply means “values that are computed” or “values resulting from a computation”. Perhaps the
    latter more explicit phraseology would be clearer, however.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

String expression notation missing

  • Key: UML25-277
  • Legacy Issue Number: 17834
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    This is unclear. Several examples are needed

    missing string expression notation

    What is it? "aaa" + "bbb" ???

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    StringExpressions are used only as nameExpressions of NamedElements in UML. The notation for nameExpressions,
    such as it is, is discussed in Subclause 7.4.4. There is already a cross-reference for this at the end of the description of
    the notation of Expressions in 8.3.4.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

{ordered} at wrong end

  • Key: UML25-272
  • Legacy Issue Number: 17826
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary: {ordered}

    on wrong end of StringExpression.subExpression

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 7882

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Incarnation ?

  • Key: UML25-219
  • Legacy Issue Number: 17763
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Delete "within an incarnation" This is confusing

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Agreed that the use of “incarnation” is confusing and unnecessary here. However, the intent is still that the
    individuals being discussed are “within” the system, so this should not be deleted.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Show how UML is a MOF metamodel

  • Key: UML25-218
  • Legacy Issue Number: 17761
  • Status: closed  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    We often say something like "UML is a MOF metamodel" or similar. It would be useful, I think, to show somewhere, perhaps in this subsection, exactly how that happens. For example, UML Classifier is an instance of MOF Classifier (right?), but nowhere do we actually SHOW how this happens. I think it would be instructive to show the general audience explicitly how this happens.
    Proposed Resolution: Add described text.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This material belongs in clause 6.2. Insert some text explaining that the abstract syntax of UML is defined
    by a UML model, replacing the paragraph that belonged to 2.4.1.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Conformance definitions ?

  • Key: UML25-214
  • Legacy Issue Number: 17756
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text: “
    A detailed definition of ways in which UML tools can be made conformant with this specification.

    As there is no separate conformance level, it appears that there is only one “way” to be conformant. Perhaps the whole sentence should be scratched.

    Clause 2 covers types of conformance not ways of conformance. so perhaps there is just a mismatch of terminology

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The bullet point is redundant because the very next section is all about conformance. Delete it.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Impact of merging profiles isn't small

  • Key: UML25-213
  • Legacy Issue Number: 17755
  • Status: closed  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    While the L3 profile only contained 3 stereotypes, that doesn't make this change small and by implication trivial. My expectation was that it should be trivial for tools to migrate 2.4.1 models to 2.5. However if both L2 and L3 profiles are applied to a package, this isn't the case and it isn't clear how any associated data should be merged. I understand the motivation for combining the profiles, but I don't think this should happen in 2.5.

    There is no mention of this migration issue in Annex E, which suggests that merely changing the version numbers is sufficient.

    Proposed Resolution:

    Continue to have separate profiles in 2.5 and consider merging them with full migration information in future UML version.
    Source: dave.hawkins@oracle.com

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue correctly notes that Annex E omits a mention of this change. Fix this omission.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Keyword Usage

  • Key: UML25-217
  • Legacy Issue Number: 17759
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In the referenced document title, the terms OPTIONAL, REQUIRED, RECOMMENDED, and NOT RECOMMENDED are also defined. Our documents also use some of these terms. Is the usage of these terms conformal to RFC 2119?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Refer instead to the ISO rules

  • Updated: Fri, 6 Mar 2015 20:59 GMT

ISO version of UML 2?

  • Key: UML25-216
  • Legacy Issue Number: 17758
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Though it might be ok to mention that we are not based on the 19502:2005 technology, recently ISO/IEC have accepted UML 2.4.1, and that is more important to be mentioned. I don’t remember the correct document #.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    It seems rather pointless and unnecessary to mention any of this, particularly because the ISO docs are
    semantically the same as the OMG docs

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Within the System

  • Key: UML25-220
  • Legacy Issue Number: 17764
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Change 'within a system' to 'to one or more objects'. This will be consistent with the references to objects in the other two bullets in this section. Also, the event may have a consequence outside the system.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The proposed change does not really address the final point of the issue, since “objects” in this context are
    already “within the system”. Also, the occurrence may have a consequence for an execution, not just an
    object (objects are being distinguished from executions at this point).

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Capture Submitters, Supporters, etc

  • Key: UML25-212
  • Legacy Issue Number: 17754
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    If section 0 is going away at some time, don't we still need to capture the submitters, supporters, and friends.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    We already have all the authors, supporters and reviewers. All that we are missing is the submitting companies.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Modeling Individuals

  • Key: UML25-221
  • Legacy Issue Number: 17765
  • Status: closed  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Why is instance specification not included?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Value specifications are mentioned as a means to model objects, but it would make more sense to use
    instance specifications here instead, since that is the most common why to explicitly model objects in UML.
    (An instance specification is not itself a value specification, though an instance value, which is a kind of
    value specification, can reference an instance specification and an instance specification can have its value
    specified by a value specification.)

  • Updated: Fri, 6 Mar 2015 20:59 GMT

DI Conformance implies Model Interchange Conformance

  • Key: UML25-215
  • Legacy Issue Number: 17757
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Doesn’t DI conformance imply MI conformance?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Clarification on the semantics of Multiplicities

  • Key: UML25-191
  • Legacy Issue Number: 17583
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of Multiplicities
    Where: section 7.5.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    Multiplicitie: both ValueSpecification should be of the same type and of a type which has a total ordering defined on it and upper should be superior to lower.

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Actually, given the definitions of the operations lowerBound and upperBound, lowerValue should have type
    Integer and upperValue should have type UnlimitedNatural. More precisely, if lowerValue is not null, then
    lowerValue.integerValue() should not be null, and if upperValue is not null, then upperValue.unlimitedNaturalValue()
    should not be null. (There is already a constraint that upperBound() >= lowerBound()).

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Clarification on the semantics of UML

  • Key: UML25-190
  • Legacy Issue Number: 17582
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of UML
    Where: section 6.3.1
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    It is not clear form the text:

    • What is the 'state' of an object/individual?
    • Are events and behavior 'objects'? Ie are they described by classifiers?
      Are classifiers also objects? Ie can a classifier describe another classifier?
  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The state of an object is the set of values associated with the properties of the classifier of the object.
    Event occurrences are not objects, but behavior executions actually are objects in UML behavioral semantics,
    because Behavior is a subclass of Class. However, it is clearer for the conceptual discussion of 6.3.1 to
    consider executions separately from objects.
    Classifiers may sometimes be considered individuals in their own right (e.g., see the discussion of static
    structural features in 9.4.3).

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Conformance point

  • Key: UML25-189
  • Legacy Issue Number: 17581
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Conformance point
    Where: section 2
    Nature of Issue: Revision
    Severity of Issue: Significant
    Full Description of the Issue:

    • Dependencies among conformance points are not stated in all the case. Particularly, when they are no dependency, this need to be pointed out.
    • I don't understand the last paragraph which seems nevertheless to open a door to the most permissive conformance point ever read: does that say that if a vendor don't want to do everything s/he just have to state so and this is good? As a UML tool users, I cannot imagine this.
    • "Where the UML specification provides options for a conforming tool, these are explicitly stated in the specification": such options should also be gathered in this section for clearness.
    • What is the status of the section 6 wrt conformance and particularly 6.3 about UML semantics? At least, add a reference to 6.3 in the "Semantic conformance" bullet and in section 6 specify which chapter is informative and which is normative
  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    On point 1, introduce a statement that conformance points are independent unless otherwise stated.
    On point 2, this paragraph is something of a hangover from an idea about “feature support statements” in
    UML 2.4. It doesn’t add significant value, so delete it.
    On point 3, the FTF discussed this and decided that a complete solution to this proposal is intractable, and a
    partial solution (e.g. by searching through the text looking for “conforming”) is not worth doing.
    On point 4, introduce text in the semantic conformance point to state that 6.3 is normative

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Clarification on the semantics of Properties

  • Key: UML25-193
  • Legacy Issue Number: 17585
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of Properties
    Where: section 9.5.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:

    • AgregationKind: "if a composite instance is deleted, all of its parts are normally deleted" what does mean 'normally'? Which other case could arise?
    • Does the definition of "composite" imply that an element can't be part of two composite instances in the same time? If yes, it should be stated so.
  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The word “normally” simply introduces confusion and should go.
    Some rephrasing is required to clarify that all composed instances are called parts, and also to use appropriate
    wording to clarify that the composition semantics only apply where the instances are objects.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Clarification on the semantics of Parameters

  • Key: UML25-192
  • Legacy Issue Number: 17584
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of Parameters
    Where: section 9.4.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    the 'effect' on a Parameter is not multiple but couldn't a parameter be read and updated or created?

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Yes, it could, and making effect multiple might be a desirable enhancement, but could affect interoperability.
    Instead,clarify that a single effect does not exclude other effects from occurring. Also clarify that effect does
    not apply to primitive types, because they cannot be created or deleted. Update the definitions in the table
    to be non-circular.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Clarification on the semantics of Manifestation

  • Key: UML25-197
  • Legacy Issue Number: 17590
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of Manifestation
    Where: section 19.3.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    The semantics of Manifestation is not defined in 19.3.3.

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The last paragraph of 19.3.3 defines the semantics of Manifestation as follows: “An Artifact may embody, or manifest,
    a number of model elements. The Artifact owns the Manifestations, each representing the utilization of some
    PackageableElement. Profiles may extend the Manifestation relationship to indicate particular forms of embodiment.
    For example, «tool generated» and «custom code» might be two Manifestations for different Classes embodied in an
    Artifact.” This seems sufficiently clear.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Clarification on the aim of Collaborations

  • Key: UML25-196
  • Legacy Issue Number: 17588
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the aim of Collaborations
    Where: section 11.7
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    "It (purpose of Collaborations) is intended as a means for capturing standard design patterns": could you please elaborate on this because this is not trivial. An example would also be welcomed.

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The Observer design pattern (http://en.wikipedia.org/wiki/Observer_pattern) is the first in the Examples
    section, so there is already an example. But the quoted sentence may still be somewhat confusing, because
    Collaborations can be used to describe other things than standard design patterns, and standard design patterns
    can be described using other things than Collaborations (e.g. templates). Since it doesn’t add clarity,
    let’s remove it.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Clarification on the semantics of ports in Encapsulated Classifiers

  • Key: UML25-195
  • Legacy Issue Number: 17587
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of ports in Encapsulated Classifiers
    Where: section 11.3.2
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    Please specify clearly that the ConnectableElements connected by a same Connector must belong to the same StructuredClassifier: this made some issues in the past (UML4DDS).

    • The concept of 'side' of a port is not explained enough, depending if it is a port or a port on a part.
    • "if there is a Connector attached to only one side of a Port, any requests arriving this Port will be lost" does it also stand for port which are not 'on a part'? Because in that case, the Port is an external boundary and a Connector may only be inside the Encapsulated Classifiers, may it not?
  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The first part of the issue is the same as 17586, and requires no changes because the constraint Connector::
    roles covers it.
    The second and third parts of this issue refer to the sentence “If there is a Connector attached to only one
    side of a Port, any requests arriving at this Port will be lost.” It is quite right to say that at this point in the text
    the concept of “side” of a Port is not well defined. But further, if there is a Connector attached to only one
    side of a Port, then it may well be the case that the model is simply silent about what happens to requests:
    there is no reason to say that they shall be lost. Indeed, most of the examples in this clause have Connectors
    only attached to one side of a Port. Hence the sentence should be deleted, as it adds only confusion.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Clarification on the semantics of Connectors within Structured Classifiers

  • Key: UML25-194
  • Legacy Issue Number: 17586
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of Connectors within Structured Classifiers
    Where: section 11.2.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    Please specify clearly that the ConnectableElements connected by a same Connector must belong to the same StructuredClassifier: this made some issues in the past (UML4DDS).

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This is already clearly specified by the Connector::roles constraint. There is a live discussion about whether this
    constraint is too tight (it should probably permit connecting to inherited roles), but that is a different issue.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Declassifying of Annex D

  • Key: UML25-198
  • Legacy Issue Number: 17592
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Declassifying of Annex D
    Where: Annex D
    Nature of Issue: Revision
    Severity of Issue: Minor
    Full Description of the Issue:
    This annex is too poor (only sequence diagrams are dealt with) to be called 'normative'.

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    We decided to address the issue by retitling the Annex and deleting the first paragraph that implies the
    approach can be more widely applied to behavioral diagrams.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Missing Table of Figures, Table of Tables - Location: TOC p 10

  • Key: UML25-211
  • Legacy Issue Number: 17753
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:
  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Generate a table of figures and table of tables

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Minor vs Major revision

  • Key: UML25-210
  • Legacy Issue Number: 17752
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current text:
    “Version 2.5 is a minor revision to the UML 2.4.1 specification. It supersedes formal/2011-08-06”

    However, in 6.1 Specification Simplification, we have the following text.
    This specification has been extensively re-written from its previous version to make it easier to read by removing redundancy and increasing clarity. In particular, the following major changes have been made since UML 2.4.1:

    Notice that it identifies major changes

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Formally-speaking according to the Policies and Procedures it is a minor revision. However some clarification
    is in order.

  • Updated: Fri, 6 Mar 2015 20:59 GMT

Section 11.5. - Clause 11: Structured Classifiers

  • Key: UML25-209
  • Legacy Issue Number: 17749
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Section 11.5.4 says “Generalizations between Associations can be shown using a generalization arrow between the Association symbols”. What about shared target style and generalization sets? Is a conforming tool required to do these for association generalizations?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Make these explicitly optional

  • Updated: Fri, 6 Mar 2015 20:59 GMT

UML type Real specification

  • Key: UML241-12
  • Legacy Issue Number: 16301
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    Version 2.4 intruduces a new UML primitive type - Real.

    This information has not been mentioned on page 127 - 7.3.44.

    The package name (I suppose Kernel) has not been defined for LiteralReal - chapter 7.3.29 (page 95); table of contents (page II).

  • Reported: UML 2.4 — Wed, 1 Jun 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Interface element - associations multiplicity not defined

  • Key: UML241-11
  • Legacy Issue Number: 16268
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    On page 36, Figure 7.16 shows the content of Interface package. Interface element has associations to four other elements with multiplicity of *. Multiplicity information is not defined on page 89, where the association names for Interface element has been defined.

  • Reported: UML 2.4 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Property::isID

  • Key: UML241-9
  • Legacy Issue Number: 16210
  • Status: closed  
  • Source: NASA ( Dr. Maged Elaasar)
  • Summary:

    Is there a semantic difference between markign an associationEnd with isID=true and putting an upper bound of "1" on its opposite end (i.e., a value of this end is related to a maximum of 1 value on the other end)?

    If there is no semantic difference, is Property::isID only useful for attributes that are not association ends (like primitive attributes that are typically not ends)?

  • Reported: UML 2.4 — Mon, 2 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Assume a classifier A has a property that is an association end typed by B, and assume its opposite end has the
    multiplicity 1..1.
    Even if this implies that, at any time, only one instance of A can be associated with a given instance of B, nothing
    stops this association from changing over time. Thus, a given instance of B cannot be used “a priori” for identifying
    an instance of A. So there is no redundancy with the semantics of Property::isID as suggested by the issue.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong package name on several Figures

  • Key: UML241-6
  • Legacy Issue Number: 16120
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Several Figures has wrong package name shown. In all cases package name should be "Core" instead of "Constructs":

    • Figure 7.3 - The Core packages
    • Part II, Figure 2 - The Core package contains the packages PrimitiveTypes, Abstractions, Basic, and Constructs...
    • Figure 9.1 - The Core package is owned by the InfrastructureLibrary pack...
    • Figure 10.1 - The Core package is owned by the InfrastructureLibrary package...
    • Figure 11.1 -The Core package is owned by the InfrastructureLibrary package...

    Also, the package name should be shown on the tab.

  • Reported: UML 2.4 — Tue, 19 Apr 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Missing Namespace in Dependencies package definition?

  • Key: UML241-10
  • Legacy Issue Number: 16267
  • Status: closed  
  • Source: - ( Marijan Matic)
  • Summary:

    On page 35, Figure 7.15 the Namespace element is described as Namespace from Dependencies package, but (on page 103) Namespace element is defined from Kernel package only.

  • Reported: UML 2.4 — Thu, 26 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

typo on page 46

  • Key: UML241-3
  • Legacy Issue Number: 16110
  • Status: closed  
  • Source: Anonymous
  • Summary:

    look at Page 46, there is a typo in the word "metaatribute" in the sentence:
    ...
    "AssociationEnd was a metaclass in prior UML, now demoted to a member of
    Association. The metaatribute targetScope"

  • Reported: UML 2.4 — Wed, 6 Apr 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Irritating occurrence of subsystem stereotype in use case example diagrams

  • Key: UML241-22
  • Legacy Issue Number: 16494
  • Status: closed  
  • Source: in.tum.de ( Florian Schneider)
  • Summary:

    Referenced UML Superstructure Version: 2.4 beta2

    Issue:

    In chapter 16 on use cases, a <<subsystem>> stereotype is applied to the subject (or system boundary) in three figures:

    • Figure 16.5 - Example of the use cases and actors for an ATM system (p. 614)
    • Figure 16.8 - Example of a use case for withdrawal and transfer of funds (p. 616)
    • Figure 16.11 - Use cases owned by a package (p. 621)

    According to Table B.1 - UML Keywords (p. 712), that specific stereotype is only applicable to Component. The subject of a use case is of type Classifier.

    So the named diagrams are not syntactically wrong but slightly irritating to the reader because there is no indication that in these examples, the use case subject is actually a more specific type of a classifier, namely a component. The diagrams could lead to misinterpretations like "it is allowed to use the subsystem stereotype for any use case subject".

    The textual description for Figure 16.5 does not clarify but only states "For example, the use cases shown in Figure 16.5 on page 614 apply to the “ATMsystem” classifier"
    Regarding Figure 16.8 the accompanying text makes no clarification.
    Figure 16.11 is even more confusing as it seems to be the case that the component being subject to the use cases is part of a package. Also the package name "ATMtopPkg" does not seem to be a good name for a package.

    Recommendation:

    1) Add textual description to explain the origin of the <<subsystem>> stereotype on the three diagrams
    or
    remove subsystem stereotype as UML examples should not include constructs of any profile (even if it is one of the standard profiles)

    2) Rename "ATMtopPkg" in Figure 16.11 (e.g. to ATMNetwork)

  • Reported: UML 2.4 — Wed, 17 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Merged with 18071

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML 2.4: NamedElement.ownedRule could be ordered

  • Key: UML241-21
  • Legacy Issue Number: 16493
  • Status: closed  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Graphically, Constraints appear independently so the unordered
    characteristric of NamedElement.ownRule seems sensible. However in a textual
    rendering ordering is appropriate.

    For instance, Constraints may sensibly be layered so that simple Constraints
    come first and act as guards against redundant evaluation of later
    Constraints.

    For instance, when auto-generating a specification such as the OCL
    specification, a specific ordering is required in the generated output.

    Please change to

    {ordered}

    .

  • Reported: UML 2.4 — Mon, 15 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    The ownedRule property is actually on Namespace, not NamedElement.
    In general, it is not appropriate to add constraints to the abstract syntax in order to capture presentation issues, like the
    textual rendering of an order. Further, the UML semantics provide no requirement that ownedRules be evaluated in
    any particular order, so, as far as UML is concerned, there is no underlying meaning to such ordering.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

property.opposite

  • Key: UML241-19
  • Legacy Issue Number: 16412
  • Status: closed  
  • Source: Dassault Systemes ( Mr. Nerijus Jankevicius)
  • Summary:

    It seems there is an issue with derived Property.opposite.

    Spec says:

    / opposite : Property [0..1] In the case where the property is one navigable end of a binary association with both ends navigable, this gives the other end.

    By description, it should keep reference to opposite navigable end, but OCL works only when navigable end is owned by class.
    It does not work when navigable end is owned by association:

    Constraint #1:
    [1] If this property is owned by a class associated with a binary association, and the other end of the association is also owned by a class, then opposite gives the other end.
    opposite = if owningAssociation->isEmpty() and association.memberEnd->size() = 2 then let otherEnd = (association.memberEnd - self)>any() in if otherEnd.owningAssociation>isEmpty() then otherEnd else Set{} endif else Set {} endif

    Any comments?
    Which one is correct? Property description or constraint text?

  • Reported: UML 2.4 — Mon, 1 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ProfileApplication::appliedProfile as "importedProfile" instead of "appliedProfile"

  • Key: UML241-18
  • Legacy Issue Number: 16400
  • Status: closed  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    I noticed that all normative UML2.x infrastructure and superstructure documents have the same bug:

    In ProfileApplications, under Associations, the following property is incorrect:

    • importedProfile: Profile [1]
    References the Profiles that are applied to a Package through this ProfileApplication.
    Subsets PackageImport::importedPackage

    It should describe the following property ProfileApplication::appliedProfile : Profile[1] as follows:

    appliedProfile : Profile[1]
    References the Profile that is applied to a Package through this ProfileApplication.
    Subsets DirectedRelationship::target

    In the UML2.xInfrastructure metamodel and the 2.4 beta2 merged metamodel
    the documentation for ProfileApplication::appliedProfile should be changed from:

    References the Profiles that are applied to a Package through this ProfileApplication.

    to:

    References the Profile that is applied to a Package through this ProfileApplication.

    This affects the following documents:

    UML2.4 Infrastructure & Superstructure beta2 (ptc/2010-11-16 and ptc/2010-11-14)
    UML2.3 Infrastructure & Superstructure (formal/2010-05-03 and formal/2010-05-05)
    UML2.2 Infrastructure & Superstructure (formal/2009-02-04 and formal/2009-02-02)
    UML2.1.2 Infrastructure & Superstructure (formal/2007-11-04 and formal/2011-11-02)
    UML2.1.1 Infrastructure & Superstructure (formal/2007-02-06 and formal/2007-02-05)
    UML2.0 Infrastructure & Superstructure (formal/2005-07-04 and formal/2005-07-05)

    This affects the following normative files:

    http://www.omg.org/spec/UML/20101101/UML.xmi
    http://www.omg.org/spec/UML/20101101/Infrastructure.xmi
    http://www.omg.org/spec/UML/20090901/Infrastructure.cmof
    http://www.omg.org/spec/UML/20061012/Infrastructure.cmof
    http://www.omg.org/spec/UML/20061012/Infrastructure.cmof

    The same bug is also in the Documents/Specifications/2.4/Deliverable files in SVN revision 21132

  • Reported: UML 2.4 — Fri, 29 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

ChangeEvent::changeExpression should be of type ValueSpecification

  • Key: UML241-25
  • Legacy Issue Number: 16896
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Subsection Associations is not in synch with the abstract syntax depicted in Figure 13.12.

    In the abstract syntax, change expression is typed by ValueSpecification, whereas in Association section it is described as Expression.

    Possible resolution:

    Change changeExpression : Expression

    to

    changeExpression : ValueSpecification.

  • Reported: UML 2.4 — Wed, 14 Dec 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Validity duration of implicitly assigned parameters in SignalEvent/CallEvent

  • Key: UML241-24
  • Legacy Issue Number: 16649
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The textual syntax of CallEvent and SignalEvents states the following:

    "<call-event> :: <name> [‘(‘ [<assignment-specification>] ‘)’]
    <assignment-specification> ::= <attr-name> [‘,’ <attr-name>]*

    <assignment-specification> is optional and may be omitted even if the operation has parameters."

    Does this mean that the parameters of the event are still assigned to attributes of the context object? If so, how long are those implicitly assigned
    attribute values stored in the context object? Since this is just a workaround to be able to express guard conditions that evaluate whether a transition can fire based
    on the recieved trigger, I would assume, the implicitly assigned attribute values are kind of transient or temporarly and will become invalid (or deleted) after all guards of the outgoing state are evaluated. Otherwise, I would like have this paragraph stated
    clearer. It is a vital and crucial part how to deal with triggering events and with guard that refer to those trigger events.

  • Reported: UML 2.4 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    There is no implication in this notation of “transient” or “temporary” assignment. The values are assigned to the given
    attributes, which retain those values until reassigned. However, the exact mechanism for accomplishing the intent
    behind this notation is not formalized in the specification. The UML 2.5 specification now includes the following
    clarification (from Subclause 13.3.4):
    “<assignment-specification> is optional and may be omitted even if the Operation has Parameters. No standard mapping
    is defined from an assignment specification to the UML abstract syntax. A conforming tool is not required to
    support this notation. If it does, it may provide a mapping to standard UML abstract syntax, e.g., by implicitly inserting
    Actions to carry out the behavior implied by the notation.”
    Disposition: Closed - No Change
    Report

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XMI in small caps

  • Key: UML241-17
  • Legacy Issue Number: 16363
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 177, Clause 12, second paragraph, in the middle, XMI is written
    in small case, as "...whose xmi serialization...", maybe it's recomended
    to write in upper case as in the rest of the document.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Core Package versus Construct Package

  • Key: UML241-16
  • Legacy Issue Number: 16362
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 14, Figure 7.3 of the OMG Unified Modeling Language (OMG UML),
    Infrastructure document, I think there's a small error in the picture.

    The picture details the Core package, as explained in the text. But
    the name in the top of the package is written as "Construct" (please
    note that I'm talking about the name of the whole package, the left-
    hand side one in the picture, and not the name os the sub-package
    Construct itself).

    It gets a little bit confusing that the name of the whole package
    is written as "Construct" instead of "Core".

    Please note also that the Figure "Part II, Figure 2" on page 27 is
    the same. And Figure 9.1 on page 29. And Figure 10.1 on page 91. And
    11.1 on page 103. And maybe others that I couldn't find now.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

UML Appendix A : Figure A.3 Two Diagrams of Packages”

  • Key: UML241-20
  • Legacy Issue Number: 16483
  • Status: closed  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In “Figure A.3 Two Diagrams of Packages” the left most diagram has a header that says:

    “i) Package symbol (as part of a larger diagram diagram)”

    This text should be (as far as I can figure out)

    “i) Package symbol (as part of a larger package diagram)”

    Similarly, the paragraph before the diagram has the following text

    “Figure A.3 illustrates that a package symbol for package P (in some containing package CP) may show the same contents as the class diagram for the package. i) is a diagram for package CP with graphical symbols representing the fact that the CP package contains a package P.”

    To clarify this, make the following one word change

    “Figure A.3 illustrates that a package symbol for package P (in some containing package CP) may show the same contents as the class diagram for the package. i) is a package diagram for package CP with graphical symbols representing the fact that the CP package contains a package P.”

  • Reported: UML 2.4 — Tue, 2 Aug 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Accept the proposals

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML Metadata Interchange (XMI) - p9

  • Key: UML241-15
  • Legacy Issue Number: 16361
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 9 of the OMG Unified Modeling Language (OMG UML), Superstructure
    document, there is the same error (or maybe, typo) as in the Infrastructure
    document. It's in the seventh bullet at the beginning of the page, where
    it's written:

    XMI Metadata Interchange (XMI)

    Maybe the correct text would be:

    XML Metadata Interchange (XMI)

    That is, XML instead of XMI at the beginning of the phrase.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

XML Metadata Interchange (XMI)

  • Key: UML241-14
  • Legacy Issue Number: 16360
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    On page 5 of the OMG Unified Modeling Language (OMG UML), Infrastructure
    document, I think there's a small error (maybe a typo). It's in the last
    line of this page, where it's written:

    XMI Metadata Interchange (XMI)

    Maybe the correct text would be:

    XML Metadata Interchange (XMI)

    That is, XML instead of XMI at the beginning of the phrase.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Implicit parameter assignment may cause name clashes

  • Key: UML241-23
  • Legacy Issue Number: 16648
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    The textual syntax of CallEvent and SignalEvents states the following:

    "<call-event> :: <name> [‘(‘ [<assignment-specification>] ‘)’]
    <assignment-specification> ::= <attr-name> [‘,’ <attr-name>]*

    <attr-name> is an implicit assignment of the corresponding parameter of the operation to an attribute (with this name)
    UML Superstructure Specification, of the context object owning the triggered behavior"

    This may lead to a situation where name clashes can occurr, if the context object already contains an identically named attibute.
    How should situations like a name clashes be resolved?

  • Reported: UML 2.4 — Mon, 31 Oct 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    The corresponding wording in the UML 2.5 specification is (from Subclause 13.3.4):
    “<assigned-name> is an implicit assignment of the argument value for the corresponding Parameter of the Operation
    to a Property or Variable of the context object for the triggered Behavior.”
    The “assigned-name” is the name of a Property or Variable that the context object already contains, not a definition of
    a new attribute. There is therefore no possibility of “name clash”.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Number of Compliance Levels

  • Key: UML241-13
  • Legacy Issue Number: 16359
  • Status: closed  
  • Source: Visionnaire ( Sergio Mainetti)
  • Summary:

    In the OMG Unified Modeling Language (OMG UML), Infrastructure document,
    it is said that this document, and the Superstructure document, should be
    used in conjunction (page 9) as the two volumes cross-reference each other
    and the specifications are fully integrated.

    But on page 2 of the OMG Unified Modeling Language (OMG UML), Infrastructure
    document we can find 2 compliance levels. And on page 2 of the OMG Unified
    Modeling Language (OMG UML), Superstructure document (ptc/2010-11-14 version
    2.4) we can find 4 compliance levels. Which is rioght ? Two our four ? As
    both documents are integrated shouldn't them have the same explanation for
    compliance levels ?

    It gets a little confusing to understand this.

  • Reported: UML 2.4 — Fri, 8 Jul 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Presentation options of statemachine transitions: Figure 15.45 is ambiguous or wrong

  • Key: UML241-2
  • Legacy Issue Number: 16002
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Arnaud Cuccuru)
  • Summary:

    Figure 15.45 of superstructure v2.3 illustrates the representation of deferred triggers on states. The transition between states "Get Cups" and "Pour coffee" specifies a trigger "light goes out" which is also identified as a deferred trigger of state "Get Cups". Does "light goes out" trigger the transition, or is it deferred? If the figure is not wrong, it would probably be helpful to add a comment in the text (note that figure 15.45 is not referenced in the text).

  • Reported: UML 2.4 — Tue, 1 Feb 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Indeed, this is a very confusing example and is also wrong as the submitter points out. Also, there should
    be some explanation of this diagram.
    Replace this diagram with a simpler one and add some explanatory text.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Can a Generalization really be in multiple GeneralizationSets?

  • Key: UML241-1
  • Legacy Issue Number: 15993
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    According to the abstract syntax, Generalization::generalizationSet has upper bound *.

    According to the text:

    Package PowerTypes A generalization can be designated as being a member of a particular generalization set.

    There is only one place where the possibility of many sets is mentioned, where it says:

    “The generalizationSet association designates the collection of subsets to which the Generalization link belongs. All of the Generalization links that share a given general Classifier are divided into subsets (e.g., partitions or overlapping subset groups) using the generalizationSet association. Each collection of subsets represents an orthogonal dimension of specialization of the general Classifier.”

    The first of these sentences implies that a Generalization can belong to many (“collection of”) GeneralizationSets. The second sentence contains a phrase “subsets (e.g., partitions or overlapping subset groups)” that makes little sense. Rephrasing “subset groups” as “subsets” gives us “e.g., partitions or overlapping subsets” which seems to imply that the GeneralizationSets may overlap. But then “Each collection of subsets represents an orthogonal dimension of specialization” translates to “each collection of GeneralizationSets represents an orthogonal dimension…” which is obviously wrong. Rephrasing as “Each GeneralizationSet represents an orthogonal dimension …” makes more sense: but if they are orthogonal, how can they overlap?

    Then, in the notation and further explanations, there is no discussion whatsoever of the possibility of a generalization belonging to many GeneralizationSets.

    I think this is clearly an error in the metamodel.

  • Reported: UML 2.4 — Thu, 27 Jan 2011 05:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    The text that the issue complains about is no longer in the spec. It’s clear that a Generalization can belong
    in more than one GeneralizationSet: “The generalizationSet property designates the GeneralizationSets to
    which the Generalization belongs.”
    However, there is a misleading phrase in the Notation that could be improved.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No Rules for Element Names

  • Key: UML241-5
  • Legacy Issue Number: 16115
  • Status: closed  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    UML specification does not provide exact rules for element names. For example, namespace "provides a means for resolving composite names, such as name1::name2::name3." What are the rules for the name1/2/3? Could we use spaces, dashes, digits?
    For the class name we should: "capitalize the first letter of class names (if the character set supports uppercase)." But what are the rules for the class name? "A use case is shown as an ellipse, either containing the name of the use case or with the name of the use case placed below the ellipse." But what are the rules for the use case name?

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    There are no rules for names in UML. The UML standard does not restricted what characters can be used in a name
    or how the name is constructed.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 15.32

  • Key: UML241-4
  • Legacy Issue Number: 16111
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I downloaded (and partially read) the UML Superstructure file "10-05-05.pdf" from your site. That's one of two defining documents of UML 2.3.

    Figure 15.32 shows the "Typing password" state from a Statechart diagram. It defines two "entry" actions: setEchoInvisible and setEchoNormal. Clearly, the second action should be an exit action, not an entry action. Can you correct this error in the next version of the document? It's a minor error, but you'll agree with me that it's a bad example this way, I suppose.

  • Reported: UML 2.4 — Fri, 18 Mar 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Agreed. This is diagram 14.5 in the new text.
    Fix the diagram by replacing the second “entry” label with the label “exit”.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Figure 15.32

  • Key: UML241-8
  • Legacy Issue Number: 16169
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Figure 15.32 shows the "Typing password" state from a Statechart diagram. It defines two "entry" actions: setEchoInvisible and setEchoNormal. Clearly, the second action should be an exit action, not an entry action. Can you correct this error in the next version of the document? It's a minor error, but you'll agree with me that it's a bad example this way, I suppose

  • Reported: UML 2.4 — Fri, 18 Mar 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    Merged with 16111

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typo: "joint" should say "join"

  • Key: UML241-7
  • Legacy Issue Number: 16164
  • Status: closed  
  • Source: asu.edu ( Joe Mooney)
  • Summary:

    Typo: say join and not joint.

    The notation for a fork and join is a short heavy bar (Figure 15.25). The bar may have one or more arrows from source
    states to the bar (when representing a joint).

  • Reported: UML 2.4 — Wed, 4 May 2011 04:00 GMT
  • Disposition: Resolved — UML 2.4.1
  • Disposition Summary:

    It should indeed be “join” and not “joint”. Correct the text appropriately

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Constraint is overly restrictive

  • Key: UMLR-504
  • Legacy Issue Number: 18077
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text: The ExtensionPoints referenced by the Extend relationship must belong to the UseCase that is being extended

    Does this "belong" also include
    1) ExtensionPoints that would be inherited?
    2) ExtensionPoints that would be defined in Included Use Cases.

    Both of these are required to support behavioral refactoring and reuse. If a "super" UseCase or an Included UseCase are made to pull out common behavioral parts, it may be that some an extending use case needs to be inserted at
    a) extension points that cross use case boundaries (e.g., in the super and child use case, or in the included and base use case) or
    b) an extension UseCase needs to be inserted in a base use case, but not in all use cases tsshat include the Included UseCase, and not in all children of the generalized UseCase.

    Without including the extensionPoints from both these sources, such situations cannot be handled.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.4 Notation P. 688 - Can Use Cases have attributes and operations?

  • Key: UMLR-502
  • Legacy Issue Number: 18085
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    A UseCase is a BehavioredClassifier, which is a Classifier, which has features of Type Property (Subclasses are Operation and Reception). However "feature" is a derived union and neither BehavioredClassifier nor UseCase define subsets of it. Therefore the features of a UseCase are always an empty set. I heard of one UML-Tool that actually enforces this rule.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure A.5 P. 734 - Use Cases are not behavior diagrams

  • Key: UMLR-496
  • Legacy Issue Number: 18101
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Use case diagrams don’t show change over time, they show intents, purposes, etc. They are neither structure nor behavior. Redraw diagram to make new category
    They are more similar to SysML requirement diagrams

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Appendix A, list of frame names, p 734 - List of Namespaces suitable for diagram headers is overly restrictive

  • Key: UMLR-497
  • Legacy Issue Number: 18100
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    A diagram of Model, Node, Datatype, etc. should be allowed.
    This is also UML 2.4 Open Issue 16484.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.1 Summary p 685 - Bases of specialized stereotypes

  • Key: UMLR-500
  • Legacy Issue Number: 18086
  • Status: open  
  • Source: NIST ( Mr. Conrad Bock)
  • Summary:

    Was wondering if clarification was needed on adding bases to specialized stereotypes. Since Extensions are associations:

    • Bases of general stereotypes inherit to specialized stereotypes, and instances of specialized stereotypes can be applied to any of the bases, including inherited ones.

    • Bases of specialized stereotypes can be specialized from more general bases by redefinition or subsetting of ExtensionEnds.

    This all follows from Extensions as associations/classifiers, so maybe doesn't really need to be explicitly said, not sure.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 19.5 Classifier Descriptions Deployment Specification Attributes P. 711 - Why a multiplicity of [0..1]

  • Key: UMLR-501
  • Legacy Issue Number: 18087
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    An artifact can be located in multiple locations, for example, on a disk and in ROM, and in RAM. Similarly, it could execute partially in ROM and also in RAM. In addition, an executable could reside in multiple places in memory on the same machines, with multiple copies running at once. Also they could assigned to different "cores"

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 22.3 Standard Stereotypes «Metamodel» p. 731 - «Subsystem» should be allowed for more classifiers

  • Key: UMLR-498
  • Legacy Issue Number: 18099
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Subsystem should also be allowed for other types of classifier, e.g., class. Limiting this to components enforces a particular methodological approach and is incompatible with Systems Engineers, who would use «Subsystem» for blocks, a specialization of Class.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 19.5 Node Association Ends Node P. 714 - Shared ownership of nodes

  • Key: UMLR-499
  • Legacy Issue Number: 18088
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    In fancy hw, a node could be owned by more than one owning node: Shared memory, shared processors, distributed processing...

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.2 Classifier Descriptions Extend Constraints. 695 - Extensions must be a DAG

  • Key: UMLR-506
  • Legacy Issue Number: 18076
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure B.3. 737 - A diagram is a PackageableElement

  • Key: UMLR-495
  • Legacy Issue Number: 18102
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    A diagram is a packageableElement.

    What does it look like in a package

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Reword isComputable

  • Key: UMLR-568
  • Legacy Issue Number: 17872
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    This is woolly just redirecting to 'can be computed'.

    Suggest: A ValueSpecification can be computed when all the algorithms, resources and values required to perform a computation are available. So a ValueSpecification would not be computable if an operation without a body was invoked, an off-line processor is required, or a source value is required. isComputable() is intended to be a static determination of capability, so a computation failure such as divide-by-zero or an I/O
    failure would not prevent isComputable() returning true, rather they would cause a query
    such as realValue() to return no value.

    ?? if a computation needs a currently locked resource, is it computable? Probably yes, since if the computation waits patiently the result will appear ??

    ?? Should be three-valued...

    True => a computation now will run
    False => a computation now will abort
    Null => a computation now might abort

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 8.6 p 98 TimeObservation ...simplify

  • Key: UMLR-569
  • Legacy Issue Number: 17868
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Simpler:
    A TimeObservation identifies a time instant at which execution either enters or exits a particular NamedElement.
    ...

    firstEvent[i] is true to select the enter, or false to select the exit event when observing execution of the NamedElement

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Too many alls

  • Key: UMLR-576
  • Legacy Issue Number: 17862
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Too many 'all's; remove all in front of all the component values.

    Suggest just: ... concatenating the ordered String values of each operand or subExpression.

    Simplerbody: if subExpression->notEmpty()then subExpression->iterate(se; stringValue: String = '' | stringValue + se.stringValue())else operand->iterate(op; stringValue: String = '' | stringValue + op.stringValue())endifif notbody: subExpression->sum() + operand->sum()

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Intended to Produce

  • Key: UMLR-575
  • Legacy Issue Number: 17858
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    How does the isIntegral determine the intent of the expression. It can only determine if the expressions produces an integer. Redefine

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bad Description, observation has no value

  • Key: UMLR-577
  • Legacy Issue Number: 17854
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Bad description; observation has no value.

    Suggest:

    Observation specifies the event or events observed to determine a TimeExpression or Duration.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Like to overridden definition

  • Key: UMLR-580
  • Legacy Issue Number: 17852
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    In e.g. LiteralInteger and LiteralNull on p 91 (and the rest)there is no hyperlink from isComputable() to the overridden definition and indeed no qualified name to aid manual navigation.
    Consider
    Move 6 versions of isComputable() to LiteralSpecification.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Why can’t the operand be a stringExpression

  • Key: UMLR-573
  • Legacy Issue Number: 17863
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Too many 'all's; remove all in front of all the component values.

    Suggest just: ... concatenating the ordered String values of each operand or subExpression.

    Simpler body: if subExpression->notEmpty()then subExpression->iterate(se; stringValue: String = '' | stringValue + se.stringValue())else operand->iterate(op; stringValue: String = '' | stringValue + op.stringValue())endifif notbody: subExpression->sum() + operand->sum()

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Range Confusion

  • Key: UMLR-578
  • Legacy Issue Number: 17851
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    'range' is a bit confusing again. Use 'intervening distance', so that (temporal) distance is a consistent terminology.

    Use 'larger ValueSpecification' or 'ending ValueSpecification' rather than 'maximum value of the range'

    Use 'smaller ValueSpecification' or 'starting ValueSpecification' rather than 'minimum value of the range'

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Simplify (Location: 8.6 p 97 TimeExpression)

  • Key: UMLR-570
  • Legacy Issue Number: 17866
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    The worded requirement should be in OCL, possibly deferring the issue to a clear definition of isConstant().

    expr <> null and observation->isEmpty() implies expr->isConstant()

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bad Description

  • Key: UMLR-574
  • Legacy Issue Number: 17855
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Unnecessarily wordy suggest just:

    An OpaqueExpression specifies the computation of a set of values either in terms of a UML Behavior or a textual expression in some language.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Simplify

  • Key: UMLR-571
  • Legacy Issue Number: 17865
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    firstEvent[i] is true to select the enter, or false to select the exit event to constrain execution of the constrainedElement.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What incompatible about sub-expressions and operands

  • Key: UMLR-572
  • Legacy Issue Number: 17864
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The problem seems solvable

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Add condition : Constraint[0..1] to the include relationship

  • Key: UMLR-432
  • Legacy Issue Number: 18857
  • Status: open  
  • Source: Learning Tree International ( Brett Martensen)
  • Summary:

    The extend relationship is not intuitive to most users of UML.

    Add the condition:Constraint[0..1] and extension point (renamed as branch point) as an optional property of the include relationship and remove the extend relationship from the specification.

  • Reported: UML 2.4.1 — Wed, 7 Aug 2013 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Definition of invariant condition

  • Key: UMLR-595
  • Legacy Issue Number: 17772
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    This is not the normal interpretation of invariant conditions, and I believe it has no support in UML 2.4.1. The typical definition for invariant condition is that it must be true (it must hold) whenever it is checked, pre, post, and during. However, it need not hold while the object is not at a stable point and not query-able (not inspectable), but it must be true when and if the condition can be checked (by normal means). In an environment with multi-threading, this is often done with locks of some sort.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section Unbalanced

  • Key: UMLR-597
  • Legacy Issue Number: 17762
  • Status: open  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    The section needs some introductory material. What's here is good, useful and interesting stuff, but its purpose and why it's located at this point in the spec is not sufficiently motivated. The material presented is also somewhat unbalanced. For example, §6.3.1 calls out three model element categories: Classifiers, Events, and Behaviors. Then §6.3.3 contains some nice text on semantics of Behaviors, but nothing further is said about Classifiers or Events. Suggest some text for the two missing categories should be added – if they are important enough to mention, they deserve discussion.
    Proposed Resolution: Add described text.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Need table correlating Literals with symbols (+,-,#,~)

  • Key: UMLR-592
  • Legacy Issue Number: 17815
  • Status: open  
  • Source: Lockheed Martin ( John Watson)
  • Summary:

    There does not seem to be anywhere where there is any coorelation between the symbols and their meaning. If anything, it would be useful here.

    Throughout the document, readers are referred to 7.4 (where the enumerations) is defined, but that doesn’t help us to know what +, - … mean.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Inconsistent use of (s)

  • Key: UMLR-593
  • Legacy Issue Number: 17807
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Sometimes a property with upper bound > 1 is referred to as having "Elements", for example, and sometimes "Element(s)". Dependency::client, Dependency::supplier, DirectedRelationship::source, DirectedRelationship::target all use the latter whereas ElementElement::ownedComments and Constraint::constrainedElements use the former. I'm sure there are many other examples. I think the former is better stylistically. (For what it's worth, Oracle's corporate documentation standards regard the use of parenthesized plurals as bad practice.)

    Proposed Resolution:

    Consistently use plurals rather than plural(s).

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 11.7 has no content or notation for template Collaborations Clause - 11: Structured Classifiers

  • Key: UMLR-601
  • Legacy Issue Number: 17750
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Section 11.7 has no content or notation for template Collaborations. There was material in UML 2.4 section 17.4.7 about these.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 11.3.4 isService clarification - Clause 11: Structured Classifiers

  • Key: UMLR-603
  • Legacy Issue Number: 17748
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Section 11.3.4 says “A Port of an EncapsulatedClassifier is shown as a small square symbol”. Does this perhaps only apply to Ports for which isService is true? The definition of isService would certainly seem to imply that a Port marked with isService = false would not appear on parts, for example. RSA hides the port when you make isService = false.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Descendants rather than specializations

  • Key: UMLR-596
  • Legacy Issue Number: 17778
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The Elements and Relationships sections both use the term "Descendants". Surely the term used here should be Specializations? I suspect this may be more widespread than just this section (7.2.4 contains another example).

    Proposed Resolution:

    Use specialization rather than descendants.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Section 11.2.4 clarification - Clause 11: Structured Classifiers

  • Key: UMLR-602
  • Legacy Issue Number: 17747
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Section 11.2.4 says “Detail may also be shown within the part box indicating specific values for Properties of the part’s type when instances corresponding to the Property are created.” What does this mean?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

List attributes whose ordered property has change in UML 2.5

  • Key: UMLR-600
  • Legacy Issue Number: 17760
  • Status: open  
  • Source: Thematix Partners LLC ( Dr. Doug Tolbert)
  • Summary:

    Summary: As an aid to tool vendors, can properties whose

    {ordered}

    status has been changed be identified in the text or listed here?
    Proposed Resolution: Add described text.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Bound Element Semantics overly specific

  • Key: UMLR-598
  • Legacy Issue Number: 17782
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Point 2 ("If the copy...") seems to be overly specific for this section. Shouldn't this information be part of the Generalization and Operation semantics?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML 2.5 FTF issues for Clause 18: UseCases

  • Key: UMLR-599
  • Legacy Issue Number: 17751
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The condition of an Extend is a Constraint. What are its constrainedElements?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Template Notation example

  • Key: UMLR-594
  • Legacy Issue Number: 17783
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    This could really do with a graphical example.

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification on the semantics of CommunicationPath

  • Key: UMLR-615
  • Legacy Issue Number: 17591
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of CommunicationPath
    Where: section 19.4.3
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    The semantics of CommunicationPath is poorly defined: what is a 'specific communication path'? A wire, a protocol used...?

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

isIntegral()

  • Key: UMLR-614
  • Legacy Issue Number: 17859
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Wouldn’t it be a better name to have the operation called isInteger?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Capitalization of dependency

  • Key: UMLR-613
  • Legacy Issue Number: 17803
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "dependency" should be "Dependency"

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Node::nestedNode should subset Class::nestedClassifier, not Namespace::ownedMember.

  • Key: UMLR-476
  • Legacy Issue Number: 18163
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The way it is modeled now, a Node’s nested nodes will not appear in its nestedClassifier property, which must be wrong.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of State in ProtocolStateMachines

  • Key: UMLR-477
  • Legacy Issue Number: 18162
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Category: Minor

    In the section on “State in ProtocolStateMachines” it is stated:

    “The States of ProtocolStateMachines are exposed to the users of their context Classifiers. A protocol State represents an exposed stable situation of its context Classifier: When an instance of the Classifier classifier is not processing any BehavioralFeature invocation, users of this instance can always know its state configuration. ”

    This does not seem to make sense, at least for declarative protocol state machines – they do not have a run-time manifestation, so it is not clear what it means for the state of such a machine to be “exposed to collaborators”.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Should “completion” event be an explicit event type?

  • Key: UMLR-479
  • Legacy Issue Number: 18159
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Category: Minor

    Should a completion event described in the StateMachines chapter be defined as an explicit event type like ChangeEvent, etc.? If so, then it should be discussed in the Commo Behaviors clause as well.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Not clear if “else” keyword is defined for State Machines

  • Key: UMLR-481
  • Legacy Issue Number: 18158
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Category: Minor

    The 2.5 spec says:

    “As a way of avoiding this situation in some cases, it is possible to associate a predefined guard denoted as “else” with at most one outgoing Transition”

    The formal specification of the “else” keyword is not given (presumably maps to a Constraint that is the conjunctive negation of all the other Constraints)

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

State of the substates of the history state

  • Key: UMLR-482
  • Legacy Issue Number: 18157
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Category: Clarification

    The 2.5 spec says:

    “Shallow history entry: If the incoming Transition terminates on a shallowHistory Pseudostate of the composite State, the active substate becomes the substate that was most recently active prior to this entry,”

    It is not clear what the ``state`of the substates of the history state are.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

It is a pity that UML does not provide the ability for Messages to correspond directly to property accesses and updates

  • Key: UMLR-473
  • Legacy Issue Number: 18170
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    It is a pity that UML does not provide the ability for Messages to correspond directly to property accesses and updates

  • Reported: UML 2.4.1 — Fri, 24 Aug 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Meaning of absent multiplicity notation

  • Key: UMLR-474
  • Legacy Issue Number: 18164
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    The UML 2.5 beta does not appear to take a clear position on what it means when the multiplicity is omitted from the notation for an element, although there are many places in the spec itself where multiplicity is absent.

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Figure 14.39 – missing superclass

  • Key: UMLR-478
  • Legacy Issue Number: 18161
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Category: Minor

    The diagram for ProtocolStateMachines does not show the superclass of ProtocolConformance; it should in line with the general convention for such abstract syntax diagrams

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification

  • Key: UMLR-517
  • Legacy Issue Number: 18037
  • Status: open  
  • Source: Oracle ( Darren Kumasawa)
  • Summary:

    Location:
    Page #607, 17.2.3 Semantics, Execution Specifications
    Page #619, 17.5.3 Semantics, Execution Occurrence Specifications
    Title: Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification

    Summary:
    Page #607, 17.2.3 Semantics, Execution Specifications
    "Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)."

    Page #619, 17.5.3 Semantics, Execution Occurrence Specifications
    "A ExecutionOccurrenceSpecification represents, on a lifeline, the start event or the end event of an ExecutionSpecification."

    When should ExecutionOccurrenceSpecifications be used as start and finish of ExecutionSpecification, and when should Message/Destruction OccurrenceSpecifications be used instead? The ExecutionOccurrenceSpecification is the only one that has a reference back to ExecutionSpecification. Is there a guideline of when to use one over the other?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Pg. 617, Figure 17.4.4: Notation, Sub-clause: Message

  • Key: UMLR-518
  • Legacy Issue Number: 18036
  • Status: open  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Title: Incorrect specification of the notation for a reply message.
    Summary:
    This clause states, “A reply Message (messageSort equals reply) has a dashed line with a filled arrow head.” A reply message has an open arrow head as shown in the usage example in Figure 17.14.

    Proposed Resolution: Replace “…filled arrow head” with “…open arrow head” in the excerpted sentence.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - No Alternative Path

  • Key: UMLR-508
  • Legacy Issue Number: 18060
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text: Once a given fragment is completed, execution continues with the behavior of the extended UseCase following the ExtensionPoint.

    This means that inserting an extension UC can't ever supply alternative behavior to the base use cases, but can only supply additional behavior. This is contrary to the vast majority of practice.
    In addition, it prevents extension use cases from being used for exception handling where the behavior ends in the extension.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - First ExtensionPoint

  • Key: UMLR-509
  • Legacy Issue Number: 18059
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

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

    It is a bit unclear whether “first” means the first of extensionPoints in the

    {ordered}

    extensionLocation list or the first that is reached in the particular execution path.

    Please clarify

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - What classifiers can be a subject?

  • Key: UMLR-513
  • Legacy Issue Number: 18048
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text: “The subject of a UseCase could be a system or any other element that may have behavior, such as a Component, subsystem, or Class”

    The restriction on behavior elements is not clear.

    This limits subjects to element that may have behavior. There is no OCL to enforce this. Is this only BehavioredClassifiers? Can a UseCase be the subject of usecase?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18. Global - No discussion of use case instances

  • Key: UMLR-516
  • Legacy Issue Number: 18043
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Need some discussion on the use and limitations of use case instances

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiplicity at Use Case end

  • Key: UMLR-511
  • Legacy Issue Number: 18054
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “When an Actor has an association to a UseCase with a multiplicity that is greater than one at the UseCase end, it means that a given Actor can be involved in multiple UseCases of that type.”

    [AC] This relationship between Actors and UseCases is asymmetric and in my opinion inconsistent. When a UseCase has a upper multiplicity >1 towards Actor, this means that multiple instances of Actor are involved. At the opposite end, the meaning is undetermined. This should be avoided in a metamodel definition. It would surely be less ambiguous to state that the upper multiplicity from Actor to UseCase is just 1.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - Show name of extension

  • Key: UMLR-510
  • Legacy Issue Number: 18056
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “Extend is a kind of DirectedRelationship, such that the source is the extending UseCase and the target is the extended UseCase. It is also a kind of NamedElement so that it can have a name in the context of its owning UseCase.”

    [AC] I can infer that the owning UseCase is the extending UseCase, but I think this should be stated again, to avoid misunderstandings. It could be also useful to give an example, with a specific figure, of a naming of the extend relationship.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location:Page #640, 17.8.2 Example Sequence Diagram

  • Key: UMLR-514
  • Legacy Issue Number: 18040
  • Status: open  
  • Source: Oracle ( Darren Kumasawa)
  • Summary:

    Title: Need more complicated Example Sequence Diagram

    Summary:
    Section 17.8.2 should include an example of a more complicated Sequence Diagram that includes BehaviorExecutionSpecification, ExecutionOccurrenceSpecification and CombinedFragment metamodel elements. It is unclear how these elements should be ordered in the "fragment" set of the Interaction. See diagram 17.14 for an example that would be useful to see the metamodel elements depicted.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 18.1.3 Semantics Use Cases and Actors P. 686 - Multiple subjects require the same actors

  • Key: UMLR-512
  • Legacy Issue Number: 18052
  • Status: open  
  • Source: Soluta.net ( Adriano Comai)
  • Summary:

    current text: “The same UseCase can be applied to multiple subjects”.

    [AC] I would add: “if, and only if, it is associated with the same actors”. Otherwise, it would be possible to have an inconsistent “reuse” of use cases, with a different set of actors in each context.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

18.1.3 Semantics Use Case and Actors Extends P. 687 - Single Location

  • Key: UMLR-507
  • Legacy Issue Number: 18062
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text: “All of the behavior of the included UseCase is executed at a single location in the included UseCase before execution of the including UseCase is resumed.

    It appears that it’s not possible (or unclear how) to insert the same included Use Case in multiple locations in the base (including) use case. Surely this is possible.

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: weak sequencing p. 622

  • Key: UMLR-515
  • Legacy Issue Number: 18038
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Need better explanation and examples

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

What is a DurationConstaint

  • Key: UMLR-585
  • Legacy Issue Number: 17845
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    I've read the description of firstEvent four times and I still do not understand it. Rewrite so there is a simple if/else that avoids the need to do detailed comparison between two very similar sentences.

    Suggest:

    A DurationConstraint is a Constraint that refers to a DurationInterval. which may be the interval between execution entering and exiting a single constrained element, or between selectable enter/exit events on a pair of constrained elements.

    ...
    When there are two constrainedElements, firstEvent[i] is true to select the enter, or false to select the exit event for execution of the corresponding constrainedElement.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Time constant

  • Key: UMLR-586
  • Legacy Issue Number: 17837
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Time constant means something else to me.
    Suggest: constant time value

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

More detail on Express

  • Key: UMLR-579
  • Legacy Issue Number: 17850
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    What is a symbol? Suggest: a symbol such as "+" may be used to define the functionality of a particular expression node.

    Are there any semantics for the inherited name? Suggest: the inherited name may be used to give distinct identifications to expression nodes.

    Are there any semantics for the inherited type? Suggest: the inherited type may be used to identify the type resulting from evaluation of the expression node.

    What type should be used for a set of values? Suggest: a domain-specific type system may be appropriate to represent a richer or more specific variety of values than can be modeled directly in UML.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Expression examples unclear

  • Key: UMLR-590
  • Legacy Issue Number: 17835
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    These are unclear. How many Expression nodes in "plus(x,1)"? Is "xor" well-formed without arguments?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OCL not indexed

  • Key: UMLR-588
  • Legacy Issue Number: 17833
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Index OCL

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Semantics Clarification

  • Key: UMLR-591
  • Legacy Issue Number: 17828
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    What are the relative semantics of 'symbol' and 'name'? What are the relative semantics of 'type'?

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Event

  • Key: UMLR-587
  • Legacy Issue Number: 17836
  • Status: open  
  • Source: INCOSE ( Sanford Friedenthal)
  • Summary:

    Should there be a specific metaclass for event that DurationObservation and TimeObservation refer to.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

incompatible multiplicities

  • Key: UMLR-581
  • Legacy Issue Number: 17849
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    It defines a symbol is inconsistent with the [0..1] multi

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

one -- > first

  • Key: UMLR-583
  • Legacy Issue Number: 17848
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    the first NamedElement is better than one event Element

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Orphan Title

  • Key: UMLR-589
  • Legacy Issue Number: 17829
  • Status: open  
  • Source: Model Driven Solutions ( Dr. Edward Willink)
  • Summary:

    Orphan title. Use Keep with Next style

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Pg. 613, Figure 17.6 - : Incorrect multiplicities in the metamodel in Figure 17.6

  • Key: UMLR-521
  • Legacy Issue Number: 18030
  • Status: open  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    The multiplicity shown for “coveredBy : InteractionFragment” is “”. However, I believe the lower multiplicity should be 1, not 0. A lifeline can only exist within an Interaction; it cannot exist independently. This is affirmed by the multiplicity of “1” shown in this figure for the end “interaction : Interaction”. And an Interaction is a type of InteractionFragment as we see in the metamodel in Figure 17.1. Therefore, an instance of Lifeline must always know at least one instance of InteractionFragment: the Interaction that owns it. And thus, the multiplicity for “coveredBy : InteractionFragment” should be “1..”, not “*”.

    Proposed Resolution:
    Change the multiplicity for the end “coveredBy : InteractionFragment” to “1..*”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: p 611

  • Key: UMLR-522
  • Legacy Issue Number: 18028
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    The notation in Figure 17.5 does not match the almost identical diagram of Figure 8.5

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Not clear when to use ExecutionOccurrenceSpecification with ExecutionSpecification

  • Key: UMLR-524
  • Legacy Issue Number: 18024
  • Status: open  
  • Source: Oracle ( Darren Kumasawa)
  • Summary:

    Location:
    Page #607, 17.2.3 Semantics, Execution Specifications
    Page #619, 17.5.3 Semantics, Execution Occurrence Specifications

    Summary:
    Page #607, 17.2.3 Semantics, Execution Specifications
    "Typically the start occurrence and the finish occurrence will represent OccurrenceSpecifications such as a receive OccurrenceSpecification (of a Message) and the send OccurrenceSpecification (of a reply Message)."

    Page #619, 17.5.3 Semantics, Execution Occurrence Specifications
    "A ExecutionOccurrenceSpecification represents, on a lifeline, the start event or the end event of an ExecutionSpecification."

    When should ExecutionOccurrenceSpecifications be used as start and finish of ExecutionSpecification, and when should Message/Destruction OccurrenceSpecifications be used instead? The ExecutionOccurrenceSpecification is the only one that has a reference back to ExecutionSpecification. Is there a guideline of when to use one over the other?

    Source: darren.kumasawa@oracle.com

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location p413 Final Node - Rollback behavior

  • Key: UMLR-529
  • Legacy Issue Number: 18011
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Consider adding a «rollback» region that is automatically executed if the parent is canceled.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location p413 Final Node - Atomic behavior

  • Key: UMLR-532
  • Legacy Issue Number: 18010
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It is often necessary to prevent an ActivityFinalNode from terminating behavior in the middle.
    We recommend the creation of a stereotype for an Activity or Action, such as «atomic» which indicates that reaching an ActivityFinalNode on the diagram will allow the behavior to finish, but that no output tokens are emitted when this occurs.

    This prevents some sorts of inconsistency that can occur when cancelling.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 17.3.4 Notation Lifeline p 613 - Specification of color

  • Key: UMLR-519
  • Legacy Issue Number: 18033
  • Status: open  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    Description: This clause states, “ExecutionSpecifications are represented as thin rectangles (grey or white) on the lifeline.” However, this is inconsistent with the idea that UML does not prescribe color for notations

    Proposed Resolution: In place of references to color, we should stick with the convention of using the terms “hollow” to mean the same color as the diagram background and “solid” to mean the same color as the boundary of the node or the path notation. In the case of overlapping notations (e.g. ExecutionSpecifications), perhaps the spec. can prescribe patterns (e.g. cross-hatch) instead of color.

    Source: Lenny Delligatti
    Discussion:

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Pg. 613, Figure 17.6 - Incorrect multiplicities in the metamodel in Figure 17.6

  • Key: UMLR-520
  • Legacy Issue Number: 18031
  • Status: open  
  • Source: Delligatti Associates, LLC ( Mr. Lenny Delligatti)
  • Summary:

    The multiplicity shown for both ends named “covered” of type “Lifeline” is “*”. The multiplicity for both of these ends should be “1” to match the metaclass entries for “OccurrenceSpecification” and “StateInvariant”. Both entries show that these two metaclasses each have an association “covered : Lifeline [1]”. And “1” is the intuitively correct multiplicity; an instance of OccurrenceSpecification (e.g. send, receive, start, end, destruction) can only be associated with a single lifeline. And an instance of StateInvariant is placed on a single lifeline.

    Proposed Resolution:

    Change the multiplicity for both of the ends “covered : Lifeline” to “1”.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Interactions p 607

  • Key: UMLR-525
  • Legacy Issue Number: 18022
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Current text:
    The invalid set of traces is associated only with the use of a Negative CombinedInteraction. For simplicity we describe only valid traces for all other constructs

    This is not quite true
    1) An assert declares all non-compliant traces as invalid
    2) It may also be possible to use consider on normal trace where the message to be considered is not in the trace to indicate that if it occurs it is invalid.
    3) It is also possible to declare invalid traces with state invariants. For example, imagine a constraint such as

    {1=2}

    Source: Michael Jesse Chonoles

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 16.2.3 Semantics / Opaque Actions

  • Key: UMLR-523
  • Legacy Issue Number: 18018
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Detail:
    Why restrict OpaqueActions to textual concrete syntax, when other approaches are possible.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure 15.67 page 436

  • Key: UMLR-527
  • Legacy Issue Number: 18016
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Detail:
    Show notation to indicate specific partitions for control nodes

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: p 504 - Marshall Actions

  • Key: UMLR-526
  • Legacy Issue Number: 18020
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Why aren’t there Marshall Actions

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Issue for UML 2.5 FTF against Clause 9: Classifiers

  • Key: UMLR-608
  • Legacy Issue Number: 17746
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    Section 9.6.4. There is no notation for raisedException. Can we add a notation?

  • Reported: UML 2.4.1 — Tue, 25 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 265, 12.2.3 Semantics - Unchanged URIs

  • Key: UMLR-557
  • Legacy Issue Number: 17949
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "The URIs should hence be unique and unchanged once assigned." The UML metamodel changes its URI with every release. I think the UPDM profile used the same URI for multiple packages/profiles. Both of which conflict with the specification statement

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 12.2.3 Semantics Package p 265 - Reference to unknown section heading

  • Key: UMLR-555
  • Legacy Issue Number: 17948
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The reference "(see Using XMI to Exchange Profiles in section Profile)", isn't using a known section heading and doesn't give a relevant section number.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 9.6.4 Notation p 127 Missing Infix operation syntax / discussion

  • Key: UMLR-566
  • Legacy Issue Number: 17907
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Location: 9.6.4 Notation p 127 Missing Infix operation syntax / discussion

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

ParameterSet Notation

  • Key: UMLR-567
  • Legacy Issue Number: 17894
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Notation for parameterset in a standard operation calls is very needed. If parametersets are used in an activity diagram, it may not be possible to match this up with an operation on the class, either in a list of operations or from a sequence diagram

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: constraints class_behavior p.190

  • Key: UMLR-561
  • Legacy Issue Number: 17937
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    current text:
    If a behavior is classifier behavior, it does not have a specification

    Why is this so. How do you handle classifier behavior that has parameters (sometime called object behavior). It’s usually started by the constructor.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location 10.3.3 Receptions p.186 - exceptions for receptions?

  • Key: UMLR-562
  • Legacy Issue Number: 17935
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Can’t receptions have out exceptions?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

p 118: isException and other outputs

  • Key: UMLR-563
  • Legacy Issue Number: 17929
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    An output posted to a Parameter with isException true during an invocation of a BehavioralFeature excludes outputs from being posted to any other outputs of the BehavioralFeature during the same invocation.

    This does not seem to match description of how exception handlers work later. I would rewrite it:

    Proposed text:
    An output may be posted to a Parameter with isException true during an invocation of a BehavioralFeature. When this occurs, unless an ExceptionHandler catches the exception, other outputs are not posted from the BehavioralFeature during the same invocation. When an ExceptionHandler catches the exception, outputs are posted from the BehavioralFeature at the level of the ExceptionHandler.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Constraints p 193 - All feturs must be public?

  • Key: UMLR-560
  • Legacy Issue Number: 17939
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Why
    An interface should be allowed to have not public proprieties/attributes. These are necessary to have them referred to in the protocol state machine, but they need not be public attributes, i.e., no direct or query-based access to their values from he outside. They need to be there to allow for a consistent description of the state-based behavior.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location p 162 ParameterSet associationends: Exceptions and parametersets

  • Key: UMLR-564
  • Legacy Issue Number: 17927
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    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

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 12.1 Packages Summary p 264

  • Key: UMLR-558
  • Legacy Issue Number: 17947
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Summary:

    "Models...which organize extensions to UML." suggests that Models contain extensions, which I don't think is true.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure 11-5 (ii) p 204

  • Key: UMLR-559
  • Legacy Issue Number: 17941
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    How do we show that each engine has 2 connections to each Wheel, as opposed to two in total?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Query of alternative scopes?

  • Key: UMLR-565
  • Legacy Issue Number: 17885
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    It should be possible within UML to query which of the alternative semantics apply.

  • Reported: UML 2.4.1 — Wed, 26 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Problems with XMI IDs in the UML 2.5 UML.xmi file

  • Key: UMLR-486
  • Legacy Issue Number: 18141
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    In the case of a derived, non-union attribute for which there is a corresponding derivation operation with the same name, the XMI IDs of one or the other of the attribute or the operation are incorrect in the UML 2.5 Beta 1 UML.xmi file (that is, inconsistent with what the IDs were in UML 2.4.1). For example, the XMI ID for the attribute NamedElement::qualifiedName is AcceptCallAction-qualifiedName. The XMI ID for the operation Namespace::importedMember is ConditionalNode-importedMember. Worse, the XMI IDs of the attribute Connector::kind and the operation Connector::kind are both the same, Connector-kind.

  • Reported: UML 2.4.1 — Fri, 5 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

17 Semantics of interactions

  • Key: UMLR-487
  • Legacy Issue Number: 18131
  • Status: open  
  • Source: NASA ( Dr. Nicolas F. Rouquette)
  • Summary:

    17 Semantics of interactions (missing constraints for resolving Operations, Signals and Actions in MessageOccurrenceSpecifications & ExecutionOccurrenceSpecifications in the scope of the Interaction itself)
    Consider Figure 17.2 (in the UML2.5 Revised August draft):

    Clearly we expect that:

    "oper1()" is a Message whose Message::signature refers to A::oper1()

    "callback()" is a Message whose Message::signature refers to C::callback()

    However, there is nothing in the spec that constrains the ownership of a Message::signature : NamedElement relative to the Interaction context of that Message.

    In fact, other possible interpretations because UML does not prescribe a particular resolution process for determining the Behavior for a given BehavioralFeature or Reception (see section 13.2.3)

    The spec does not currently specify any kind of bound on this resolution process — that is, Behaviors could be found potentially anywhere in the model.

    This is obviously absurd: it is unreasonable to expect that Figure 17.2 corresponds to a model where neither A nor C define "oper1()" or "callback()" but rather that these 2 operations are defined in an completely unrelated class not involved in the interaction at all – e.g., B.

  • Reported: UML 2.4.1 — Tue, 2 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UML Interactions do not provide the ability for Messages to correspond directly to property accesses and updates

  • Key: UMLR-490
  • Legacy Issue Number: 18126
  • Status: open  
  • Source: Model Driven Solutions ( Mr. Steve Cook)
  • Summary:

    It is a pity that UML Interactions do not provide the ability for Messages to correspond directly to property accesses and updates

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: B.6 UML ProfileDiagrams . 768 - Profile Diagram Elements

  • Key: UMLR-493
  • Legacy Issue Number: 18110
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Wouldn’t this be the «profile» Package being modeled?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: B.6 UMLClass Diagram P. 757 - Class namespace diagrams?

  • Key: UMLR-492
  • Legacy Issue Number: 18107
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    if I'm using a class diagram to show the namespace structure of a class (not the composite structure), wouldn't that classdiagram have a modelElement, that of the owning class

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Overriding deferred events

  • Key: UMLR-483
  • Legacy Issue Number: 18156
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Category: Minor

    The 2.5 spec says:

    “Event occurrences remain in the event pool until:

    · a state configuration is reached where these Event types are no longer deferred or,

    · if a deferred Event type is used explicitly in a Trigger of a Transition whose source is the deferring State (i.e., a kind of override option)

    It is not clear if the override capability extends inside the deferring State or only on the outside. The latter option was chosen in the spec, since it would be difficult to spot the override if it occurred inside the deferring state. But….

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Stable state not needed

  • Key: UMLR-484
  • Legacy Issue Number: 18154
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Category: Minor

    The 2.5 spec says:

    “A state configuration is said to be stable when:

    · no further Transitions from that state configuration are enabled and

    · all the entry Behaviors of that configuration, if present, have completed (but not necessarily the doActivity Behaviors of that configuration, which, if defined, may continue executing”

    I believe that the concept of a stable state configuration is not necessary, since all state configurations are, by definition, stable. I cannot think of a transient one

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Annex C Keywords P. 778 - Inconsistent metaclass keywords

  • Key: UMLR-491
  • Legacy Issue Number: 18115
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    There a number of keywords that are used when the same notation is used for multiple metaclasses. These aren't derived from the name of the metaclass in a consistent manner. For example, centralBuffer for CentralBufferNode, deployment spec for DeploymentSpecification, substitute for Substitution.

    Stereotypes are now given as their exact name, without transliteration or abbreviation. Should the same approach be used for metaclasses?

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Default entry if default history transition missing

  • Key: UMLR-485
  • Legacy Issue Number: 18155
  • Status: open  
  • Source: Simula Research Laboratory ( Dr. Bran Selic)
  • Summary:

    Category: Minor

    The behavior in case of a default entry when the default history transition is missing was not specified; The following option was added in 2.5, but needs to be checked by vendors:

    “If no default history Transition is defined, then standard default entry of the State is performed”

  • Reported: UML 2.4.1 — Wed, 10 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: B.2.2 P. 738 - What ISO document

  • Key: UMLR-494
  • Legacy Issue Number: 18103
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Explain which document

  • Reported: UML 2.4.1 — Fri, 28 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 270/271, 12.2.3 Semantics - Model description confusing

  • Key: UMLR-549
  • Legacy Issue Number: 17956
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The description of Model uses viewpoint, vantage point and perspective. I realise these are synonyms but they don't really all need to be used here. Just use viewpoint as that is the attribute name. A Model is a view, but that isn't mentioned until the third paragraph. Really that should be in the first paragraph. Abstraction is also used giving the impression that it is something distinct from the viewpoint. However surely the viewpoint defines the level of abstraction. It might be a good idea to the define the terms viewpoint and view first of all and then show how Model relates to them.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 269, 12.2.3 Semantics - Association merge aggregation constraint is property rule

  • Key: UMLR-550
  • Legacy Issue Number: 17955
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Association Rules, Constraints 2 is a property rule so ought to appear there. The property rules ought to say something about shared aggregation too.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 286, 12.3.3 Semantics - Incorrect if statement

  • Key: UMLR-545
  • Legacy Issue Number: 17961
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "If the value is the name of a NamedElement..." doesn't make sense as the name is a string and doesn't have a qualified name.

    Proposed Resolution:

    Replace with:

    "If the value is a NamedElement..."

    Revised Text:
    Source: dave.hawkins@oracle.com

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 285, 12.3.3 Semantics - Old behavior unnecessarily preserved

  • Key: UMLR-544
  • Legacy Issue Number: 17960
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "Matching between the names of Stereotype definitions and applications is case-insensitive, so naming stereotype applications with lower-case letters where the stereotypes are defined using upper-case letters is valid, although stylistically obsolete."

    What does matching actually mean here? I think this should really just say that the correct way to display stereotype names is exactly as they are in the model.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 269, 12.2.3 Semantics - Property merge transformation conflicts with constrain

  • Key: UMLR-552
  • Legacy Issue Number: 17953
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Property Rules, Constraints 2 means that Transformations 7 is either wrong or unnecessary

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 267, 12.2.3 Semantics - Type and TypedElement confusion

  • Key: UMLR-553
  • Legacy Issue Number: 17952
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    General Package Merge Rules, Transformations 4 is round the wrong way. A TypedElement references a Type not the other way round. I suspect this rule shouldn't say anything about types at all. It should just be "All references to elements...resulting Elements..."

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 265, 12.2.3 Semantics PackageMerge - Long-winded package merge description

  • Key: UMLR-556
  • Legacy Issue Number: 17950
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The paragraph starting "A PackageMerge can be viewed..." is a bit long-winded and contains lots of parentheses.

    Proposed Resolution:

    Simplify text, removing parentheses:

    A PackageMerge can be viewed as a set of transformations whereby the contents of the merged Package and the receiving Package are combined. Matching elements are merged into a single resulting element according to the formal rules of PackageMerge specified below. This is akin to “copying down” the features of superclasses into a subclass: the fully expanded subclass is the equivalent to the resulting package

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 281, 12.3.3 Semantics - Duplicated text

  • Key: UMLR-546
  • Legacy Issue Number: 17959
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The "Defining Profiles for Non-UML Metamodels" section seems to duplicate the "Restricting Availability of UML Elements" section (which also has the wrong heading style). Surely this could just be done as a single block of text that describes the filtering rules in general and then gives a specific example using the UML metamodel, while stating that in theory other metamodels could be extended.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Page 266, 12.2.3 Semantics - Un-matched resulting elements aren't always the same

  • Key: UMLR-554
  • Legacy Issue Number: 17951
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The "resulting element" is described as being the same when no match exists. However this isn't strictly true. References from the element may be updated to other resulting elements

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 280, 12.3.3 Semantics - Note should be main text

  • Key: UMLR-548
  • Legacy Issue Number: 17957
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    "[Note: ...]"

    I don't see why this is a note, it should just be a normal bit of text.

    Proposed Resolution:

    Remove "[Node:" and "]" keeping the note text.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 269, 12.2.3 Semantics - Property merge rule pointless

  • Key: UMLR-551
  • Legacy Issue Number: 17954
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    Property Rules, Transformations 5 doesn't really do anything. It should probably be specifying the value of isDerivedUnion

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 280, 12.3.3 Semantics - Poorly indented XMI

  • Key: UMLR-547
  • Legacy Issue Number: 17958
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    The XMI for the HomeExample profile has variable indenting and unaligned XML open/close elements.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 286, 12.3.3 Semantics - Nonsensical alternative to stereotype name

  • Key: UMLR-543
  • Legacy Issue Number: 17962
  • Status: open  
  • Source: Oracle ( Dave Hawkins)
  • Summary:

    An alternative name is given for stereotypes:

    "If the ExtensionEnd is given a name, this name can be used in lieu of the stereotype name within the pair of guillemets when the stereotype is applied to a model element."

    Earlier, the specification of the extension end name is given as "extension_stereotypeName" so this is a rather bizarre option. When would this ever make sense?

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: p 410

  • Key: UMLR-531
  • Legacy Issue Number: 18006
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Show how to pass activities around

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 328, 14.2.3 - UseCase cannot be the context of a StateMachine

  • Key: UMLR-537
  • Legacy Issue Number: 17975
  • Status: open  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    “If the StateMachine has a kind of BehavioredClassifier context, then that Classifier defines which Signal and CallEvent triggers
    are applicable”. A UseCase is a BehavioredClassifier and thus would be the context of a Statemachine. Since a UseCase cannot have Signal receptions or operations no such triggers would be applicable to this StateMachine.

    Proposed Res
    The radical solution would be to make UseCase not a BehavioredClassifier. However this would be out of scope. Therefore the next sentence should be changed:
    “If the StateMachine has no BehavioredClassifier context or this context is a UseCase…”

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Signal Receipt symbol

  • Key: UMLR-536
  • Legacy Issue Number: 17987
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    What is the motivation for the limitation on not have time events, or call events here

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 346, State List Notations - Why must state lists be effect free?

  • Key: UMLR-534
  • Legacy Issue Number: 17984
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Why must they be effect-free? If all the transitions have the same effect, it would be easily understandable

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: 13.3.5 Examples p 314

  • Key: UMLR-538
  • Legacy Issue Number: 17970
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Explain why there are no examples

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Opaque and Function Behaviors p 308

  • Key: UMLR-540
  • Legacy Issue Number: 17968
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Detail: Why limit OpagueBehavior to a textual specification. It seems to me that any language other than UML, including graphical languages would be opaque for this purpose.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: p. 336 Compound transitions - Run-to-completion Paradigm

  • Key: UMLR-533
  • Legacy Issue Number: 17999
  • Status: open  
  • Source: University of Texas ( Omar Badreddin)
  • Summary:

    It should be stated that a do-activity is the exception here. Also, code within the do activity should be prevented from updating the state machine configurations or firing of events (directly or indirectly).

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 316 redefinedBehavior - Extends

  • Key: UMLR-539
  • Legacy Issue Number: 17972
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    What does “extends” mean in this context. Is it the extends of use cases? Or statemachines? Or profiles? I don’t believe it is defined clearly

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Page 331 deep history entry - Default deep history entry

  • Key: UMLR-535
  • Legacy Issue Number: 17979
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Shouldn’t there be a default deep history transition. See p. 374.

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Location: Figure 12-13 p.281 - Incorrect use of << for «.

  • Key: UMLR-541
  • Legacy Issue Number: 17964
  • Status: open  
  • Source: Change Vision ( Michael Chonoles)
  • Summary:

    Figure 12-13 has interface titled <<Home>> it should be «Home»

  • Reported: UML 2.4.1 — Thu, 27 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

How to model a transition to history pseudostates in two orthogonal regions?

  • Key: UMLR-610
  • Legacy Issue Number: 17596
  • Status: open  
  • Source: self-employed ( Volker Spinke)
  • Summary:

    A transition that terminates on the outside edge of a composite state is called a default entry. In this case, the default entry rule is applied e. g. the transition originating from the initial pseudostate is performed. If the most recently active substate prior to this entry shall become the active substate, the transition must be drawn to a history pseudostate. Page 564 clearly states this.

    Next, the composite state is extended to an orthogonal state with two regions. Both regions contain a history pseudostate. A transition shall fork to both history states. I thought this is easy to model by introducing a fork pseudostate in the transition and drawing two outgoing transitions from the fork to the history pseudostates.

    This is obviously not the case as constraints rule 3 on page 582 states: "A fork segment must always target a state. (source.oclIsKindOf(Pseudostate) and source.kind = #fork) implies (target.oclIsKindOf(State))"

    It is also mentioned at other locations that an outgoing transition of a fork pseudostate must target a state. Pseudostates are not allowed as targets of outgoing transitions from a fork pseudostate.

    I am confused by this rule. My question is: How do I have to model a transition ending on the history states in two orthogonal regions?

    Thanks for your kind advice.

  • Reported: UML 2.4.1 — Mon, 17 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Clarification on the semantics of inheritance between use cases

  • Key: UMLR-612
  • Legacy Issue Number: 17589
  • Status: open  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Title: Clarification on the semantics of inheritance between use cases
    Where: section 18
    Nature of Issue: Clarification
    Severity of Issue: Minor
    Full Description of the Issue:
    It appears in figure 18-11 as it is implied by the abstract syntax that inheritance among use cases is possible. The semantics of such an inheritance needs to be described.

  • Reported: UML 2.4.1 — Thu, 13 Sep 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

OccurrenceSpecification should have at least an optional notation

  • Key: UMLR-264
  • Legacy Issue Number: 16572
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Until UML 2.3, OccurrenceSpecification (OS) was an abstract superclass for the concrete occurrence specifications MessageOccurrenceSpecificatio (MOS) and ExecutionOccurrenceSpecification (EOS). In UML 2.3 OS became concrete. This apparently subtle change has a significant impact of the usage of domain-specific events in Interaction. A user can now place an OS along a lifeline directly, instead of using using the already existent ActionExecutionSpecification or BehaviorExecutionSpecification. This eases the definition of domain-specific occurrence specifications (let's call it events from henceforth) by defining stereotypes directly for an OS.

    For example, in the UML Testing Profile, there are some test-specific events (e.g. ValidationAction, a sterotype for CallOperationAction) which can be used inside Interaction. Until UML 2.3 the steps for including such a domain-specific actions in Interactions have been the following:

    1. Create an Action and let it being contained by the Interaction
    2. Configure that Action and apply the corresponding stereotype
    3. Create the ActionExecutionSpecification
    4. Create the EOS as the start EOS and link the ActionExecutionSpecification with the EOS
    5.Create the EOS as the finish EOS and link the ActionExecutionSpecification with the EOS
    6. Link the ActionExecutionSpecification with the Action

    The whole procedure involved a lot of very fine-grained and subtled concepts and requires an advanced knowledge of the Interactions metamodel (frankly, only few tools support this complex procedure).

    Since UML 2.4, the steps are reduced to the following one:
    1. Create an OccurrenceSpecification on a lifeline
    2. Apply a stereotype to the OS and configurethe OS

    The stereotyped OS assumes the semantics provided by the domain-specific OS (in UTP ValidationOccurrenceSpecification). This reduces the complexity of integrating such domain-specific events, reduces the memory foorprint and eases the handling and creation of interactions containing such stereotyped OS.

    The problem is that OS does not declare a national representation, and we doubt that this concept will be provided by tools if there is not standardized representation.

    Therefore, we suggest to define a (at least optional) notation for OS as a rectangle or rounded rectangle with a compartment for stereotype visualization and a compartment for an optional label (name of the OS or an expression within the stereotype).

    This change would not affect the XMI or metamodel, but has a significant impact of the way interaction are perceived and created.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message arguments for a Signal signature too restrictive

  • Key: UMLR-262
  • Legacy Issue Number: 16570
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Constraint 4 of Message in section 14.3.18 requires that in case of a Signal signature, the arguments of the message must correspond to the properties of the Signal.

    We found this constraint too restrictive. A Signal is a classifier, hence it is possible to create an InstanceSpecification for the Signal. A InstanceSpecification can be referenced by an InstanceValue (ValueSpecification) from within the message argument list.

    We suggest to weaken the first sentence of constraint 4 a little from :

    In the case when the Message signature is a Signal, the arguments of the Message must correspond to the attributes of the
    Signal.

    to

    In the case when the Message signature is a Signal, the arguments of the Message must correspond to the attributes of the
    Signal, or to the Signal itself.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Relation of message arguments to signature parameters ambiguous

  • Key: UMLR-261
  • Legacy Issue Number: 16569
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    In section 14.3.18, the constraints 3 and 4 say that the arguments of message must correspond to the parameters/properties of the signature (operation/signal). This leads to an ambiguous siuation in some situations. For example:

    Let's assume there is an operation with the following signatur op1(x:String[*], y:String[*]) or a Signal S with two properties
    S::p1 : String[0..1]
    S::p2 : String[0..1]

    Since there is no direct relationship between an argument and a parameter/property it is not possible to determine what argument belongs to the first parameter/property (list in case opf operation example) and what to the second one.

    This problem always occurrs when two parameters/properties of the same type are specified in a sequence and the first one has either an optional multiplicity or an upper bound equals *.

    A possible solution is to introduce an additional metaclass MessageArgumentSpecification, which should be contained by Message instead of ValueSpecification directly, with the following structure:

    MessageArgumentSpecification{
    refersTo: TypedElement [1]

    {where the referenced TypedElement is either an instance of parameter or property}

    arguments : ValueSpecification [1..*]

    {ordered}

    }

    It might be also considerable to keep the association between a referenced element and an argument bilateral. In this case, the association between Message and MessageArgumentSpecification should be ordered.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The included use case is always required for the including use case to execute correctly

  • Key: UMLR-265
  • Legacy Issue Number: 16658
  • Status: open  
  • Source: ivmx.pl ( Michal Kasprzyk)
  • Summary:

    In the 'Descriiption' section of chapter '16.3.5 Include (from UseCases)' there is a sentence:
    'Note that the included use case is not optional, and is always required for the including use case to execute correctly.'

    Interpretation of ‘include’ relationship, implying that it’s usage is valid only if included UC is obligatory for including UC to execute correctly,
    is probably the source of opinion, that the only way to model conditional parts of UC scenario using external UC, is by using ‘extend’ relationship.

    I find such conclusion in many books dealing with analysis/UML, for instance: ' Business Analysis’, page 188 (ISBN-10: 1906124612,ISBN-13: 978-1906124618).

    As a result the difference in aplicability between ‘include’ and ‘extend’ relationship is stressed almost only based on conditionallity of relationship between UC.

    In my opinion it’s valid to use ‘include’ relationship when pointing to another UC, that won’t be executed every time the base UC does.
    It’s just the internal logic of base UC scenario, that decides if it’s appropriate to call external UC or not.
    And if we depend only on result of an external UC, we should use ‘include’ relationship (so most of the time), while when there is a need to introduce its logic we should use ‘extend’ relationship.

    I think, that the sentencje:
    'Note that the included use case is not optional, and is always required for the including use case to execute correctly'
    should be removed or clarified, because if forces analysts to use mostly (if not only) an ‘extend’ relationship, that is far more complicated to use and time consuming to document than ‘include’.

  • Reported: UML 2.4.1 — Thu, 10 Nov 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Abstraction::mapping should be of type ValueSpecification or OpaqueExpression

  • Key: UMLR-266
  • Legacy Issue Number: 16897
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    In many cases, modeler would like to specify the mapping of an Abstraction on an informal level by just providing a LiteralString or OpaqueExpression describing the mapping in a natural language.

    The necessity to use an Expression is for this kind of usage of this feature cumbersome and clunky.

    The resolution could be to use a more common metaclass of Expression, i.e. ValueSpecification, to provide the highest level of flexibility to the modeler, how mappings can be specified.

  • Reported: UML 2.4 — Wed, 14 Dec 2011 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Message arguments should not be contained in a message

  • Key: UMLR-263
  • Legacy Issue Number: 16571
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    Figure 14.4 - Messages in the spec depicts that arguments of a message are contained in that message. This containmentship is not necessary and in many cases counterproductive.

    The containment prevents ValueSpecifications for being reused in multiple messages. Instead, the very same ValueSpecification must be created in each message.

    Since ValueSpecification is a PackageableElement, there is no problem in making the association between Message and ValueSpecification a non-containment association.

  • Reported: UML 2.4 — Thu, 29 Sep 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Cannot set an activity as the source or target of an information flow

  • Key: UMLR-294
  • Legacy Issue Number: 19133
  • Status: open  
  • Source: Alstom Transport ( Wagner Schalch Mendes)
  • Summary:

    According to the constraints specified for an InformationFlow, its sources and targets can be only 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.

    In my opinion, Activity should also be included in the list.

  • Reported: UML 2.4.1 — Wed, 4 Dec 2013 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Use cases specifying the same subject cannot be associated: exception

  • Key: UMLR-254
  • Legacy Issue Number: 16292
  • Status: open  
  • Source: London Life Insurance Co. ( Willem Van Galen)
  • Summary:

    The UML Superstructure Specification V2.4 states in 16.3.6 UseCase (from UseCases): “Two use cases specifying the same subject cannot be associated since each of them individually describes a complete usage of the subject.”

    For the longest time, this looked like a common-sense rule. However, it seems to me that in the context of SOA there is at least on exception to this rule.

    Let’s say that:
    1. The subject represents a component (as understood in SOA) and the use cases represent the component’s services.
    2. The initiating actor of all of the component’s services is Another Use Case. This reflects the SOA reality that services are not directly consumed by human actors but by other use cases.
    3. The component offers services A and B, both of which trace back to legitimate uses.
    4. As it happens, when service B is defined in detail it turns out that one of its steps amounts exactly to the functionality represented as service A.

    In such situations, where the subject already has a public service (A) that can actually be reused by one or more of its other public services (B), I think it’s entirely reasonable to allow B to be associated with A. After all, A’s initiating actor is Another Use Case, which is exactly what B is. In object-orientated terms this amounts to an object performing an operation on itself.

    I propose for UML to accommodate this scenario.

  • Reported: UML 2.4 — Sat, 28 May 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Metaclass stereotype notion (02)

  • Key: UMLR-252
  • Legacy Issue Number: 16119
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Text says: "The names of Profiles are shown using a dashed arrow with an open arrowhead from the package to the applied profile."
    "The names" is not relevant in this context. The arrow is related to profile application.
    The text should say something like: "The applied Profiles are shown ..."

  • Reported: UML 2.4 — Fri, 27 Jun 2014 11:17 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Metaclass stereotype notion

  • Key: UMLR-251
  • Legacy Issue Number: 16118
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Text says: "A Class that is extended by a Stereotype may be extended by the optional stereotype «Metaclass» ..."
    The second "extended" has no sense.
    It should say something like: "A Class that is extended by a Stereotype may be denoted by the optional stereotype «Metaclass» ..."

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Profile URI Attribute - Mingled URI Definition and Use in XMI

  • Key: UMLR-250
  • Legacy Issue Number: 16117
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    While describing profile URI attribute for profiles UML specification mingled definition of URI and format used for XMI. URI value as a whole should follow URI specification RFC 2396 and OMG recommended format:
    uri = http://profileParentQualifiedName/version/profileName.xmi
    When URI is used for XMI, the profileParentQualifiedName part should also be (made?) valid XML QName, e.g. with "all other illegal XML QName characters removed". Note, that XML QName usually has namespace prefix followed by ':', e.g. 'taxes:dependent', which contradicts to and has no sense as related to the first URI 2396 requirement.

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Package URI Attribute Uses Obsolete RFC 2396

  • Key: UMLR-249
  • Legacy Issue Number: 16116
  • Status: open  
  • Source: email.com ( Kirill Fakhroutdinov)
  • Summary:

    Specification requires URI package attribute to follow the rules and syntax of the IETF URI specification RFC 2396. RFC 2396 was rendered obsolete by the more recent version of the URI syntax - RFC 3986, released in 2005.

  • Reported: UML 2.4 — Sun, 17 Apr 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

A deferrable trigger may have a guard

  • Key: UMLR-255
  • Legacy Issue Number: 16307
  • Status: open  
  • Source: asu.edu ( Joe Mooney)
  • Summary:

    It is an unfortunate restriction to omit guards from the specification of <trigger>/defer.

    Please explicitly state or reconsider this restriction since using a guard would simplify many scenarios involving event deferral

  • Reported: UML 2.4 — Wed, 1 Jun 2011 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Name of Package in Figure 7.3 should be "Core" rather than "Constructs"

  • Key: UMLR-311
  • Legacy Issue Number: 19282
  • Status: open  
  • Source: lemke24.org ( Andreas Lemke)
  • Summary:

    The subtitle of the Figure 7.3:
    "The Core Packages"
    But the Name of the Package in the figure is "Constructs".

  • Reported: UML 2.4.1 — Mon, 10 Mar 2014 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Interaction.action should subset ownedMember in lieu of ownedElement

  • Key: UMLR-270
  • Legacy Issue Number: 17315
  • Status: open  
  • Source: Fraunhofer FOKUS ( Mr. Marc-Florian Wendland)
  • Summary:

    In Figure 14.5 of UML 2.4.1 (and still valid for UML 2.5), the association end 'action' of Interaction subsets Element.ownedElement. Since Interaction is a Namespace and Action a NamedElement, I reckon it ought to subset Namespace.ownedMember instead.

  • Reported: UML 2.4.1 — Thu, 19 Apr 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT