${taskforce.name} Avatar
  1. OMG Task Force

Unified Modeling Language 2.5 (UML) FTF — All Issues

  • Key: UML25
  • Issues Count: 492
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
UML25-345 Location: 9.6.4 Notation p 128: Confusing indentation UML 2.4.1 UML 2.5 Resolved closed
UML25-684 Typo in Interaction Example UML 2.5b1 UML 2.5 Duplicate or Merged 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-679 Operation::isConsistentWith() UML 2.5b1 UML 2.5 Resolved closed
UML25-680 Profile::references_same_metamodel UML 2.5b1 UML 2.5 Resolved closed
UML25-678 redefined states UML 2.5b1 UML 2.5 Resolved closed
UML25-677 Event pools for passive objects? UML 2.5b1 UML 2.5 Resolved closed
UML25-676 Who owns MessageEnds? UML 2.5b1 UML 2.5 Resolved closed
UML25-629 15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines) XMI 1.0 UML 2.5 Resolved closed
UML25-628 Notation of enumeration literals UML 2.0 UML 2.5 Resolved closed
UML25-626 UML2 Super / Templates / ordering of subExpressions UML 1.4.2 UML 2.5 Resolved closed
UML25-627 Figure 307 and Figure 308 are exactly the same UML 2.0 UML 2.5 Resolved closed
UML25-625 UML 2 Super/ Classes / issue with Property::isComposite UML 1.4.2 UML 2.5 Resolved closed
UML25-623 "Class" should read "Classifier" in Generalization subsection for Behaviore UML 1.4.2 UML 2.5 Resolved closed
UML25-624 Associations section of InteractionUse UML 2.0 UML 2.5 Resolved closed
UML25-620 15.3.14 Transition (from BehaviorStateMachines) XMI 1.0 UML 2.5 Resolved closed
UML25-622 inconsistent Generalization subsections in spec format UML 1.4.2 UML 2.5 Resolved closed
UML25-619 15.3.10 Region (from BehaviorStateMachines) UML 1.4.2 UML 2.5 Resolved closed
UML25-621 notational standard for {subsets x} in textual contexts UML 1.4.2 UML 2.5 Resolved closed
UML25-618 15.3.8 Pseudostate (from BehaviorStateMachines) UML 1.4.2 UML 2.5 Resolved closed
UML25-617 15.3.16 Vertex (from BehaviorStateMachines) UML 1.4.2 UML 2.5 Resolved closed
UML25-616 Artifact (from Artifacts) UML 1.4.2 UML 2.5 Resolved closed
UML25-612 9.3.6 Connector (from InternalStructures) UML 1.4.2 UML 2.5 Resolved closed
UML25-614 .3.44 Property (from Kernel) UML 1.4.2 UML 2.5 Resolved closed
UML25-613 8.3.1 Component (from BasicComponents, PackagingComponents) UML 1.4.2 UML 2.5 Resolved closed
UML25-615 9.3.11 Port (from Ports) UML 1.4.2 UML 2.5 Resolved closed
UML25-611 7.3.24 Interface (from Interfaces) UML 1.4.2 UML 2.5 Resolved closed
UML25-610 UML2 super/CommonBehavior/Opaque behavior : bad OO modelling UML 1.4.2 UML 2.5 Resolved closed
UML25-608 Dependency associations UML 2.0 UML 2.5 Resolved closed
UML25-609 Deployment (from ComponentDeployments, Nodes) UML 2.0 UML 2.5 Resolved closed
UML25-606 UML 2 Superstructure -Incompatible use of term link UML 1.4.2 UML 2.5 Resolved closed
UML25-602 Associations between interfaces UML 1.4.2 UML 2.5 Resolved closed
UML25-607 UML 2 Super/Templates/Inconsistent organization UML 1.4.2 UML 2.5 Resolved closed
UML25-603 CollaborationOccurence UML 2.0 UML 2.5 Resolved closed
UML25-605 UML 2 Superstructure - cross-hair notation for nested classes UML 1.4.2 UML 2.5 Resolved closed
UML25-604 UML 2.0 Issue: Semantics of Provided and Required Interfaces UML 1.4.2 UML 2.5 Resolved closed
UML25-601 UML 2 Super and Infra/ defualt property of Parameter::effect UML 1.4.2 UML 2.5 Resolved closed
UML25-673 Incomplete sentence UML 2.5b1 UML 2.5 Resolved closed
UML25-674 TestIdentityAction for datatypes FUML 1.0b2 UML 2.5 Resolved closed
UML25-672 Problems with OCL definition of Package::makesVisible UML 2.5b1 UML 2.5 Resolved closed
UML25-675 Modeling sent messages in State Machines UML 2.3b1 UML 2.5 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-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-667 Surplus classifier field serialized in Superstructure.xmi 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-666 DurationObservation#event should be ordered 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-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-663 Constraint [1] uses undefined attribute "ownedAttribute 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-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-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-657 color of the notation is specified 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-655 Opposite ends of derived unions should be derived unions 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-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-652 incorrect upper value of coveredBy of Lifeline 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-648 Error in UML diagrams? 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-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-643 Figure 15.2 does not include TransitionKind 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-640 role "interval" appears "interva" UML 2.4.1 UML 2.5 Resolved closed
UML25-646 default is wrong 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-635 "A_realization_abstraction_component" is useless 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-639 OpaqueBehavior#body attributes "nonunique" truncated as "nonuni..." 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-636 RedefinableElement (from Kernel) is preferable 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-632 ChangeEvent association mismatch UML 2.4.1 UML 2.5 Resolved closed
UML25-633 UML Superstructure Specification 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-630 UML 2.3: Transitions outgoing junction vertexes should be allowed to have triggers UML 2.4.1 UML 2.5 Resolved closed
UML25-554 Activity::structuredNode is incorrectly marked as readOnly = true UML 2.5b1 UML 2.5 Resolved closed
UML25-553 misleading omission UML 2.5b1 UML 2.5 Resolved closed
UML25-552 Validation errors in UML metamodel UML 2.5b1 UML 2.5 Resolved closed
UML25-551 UML 2.5 issue: subsettingContext() has incorrect logic UML 2.5b1 UML 2.5 Resolved closed
UML25-548 Annex E lacks sub-clauses for the XMI details for StandardProfile and UMLDI UML 2.5b1 UML 2.5 Resolved closed
UML25-550 Headed composite and not ownedElement UML 2.5b1 UML 2.5 Resolved closed
UML25-549 Assocation display options too narrow UML 2.5b1 UML 2.5 Resolved closed
UML25-547 PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value UML 2.5b1 UML 2.5 Resolved closed
UML25-546 Wording corrections in Behavior Diagrams and Activity Diagram Labels UML 2.5b1 UML 2.5 Resolved closed
UML25-544 Template parameter rectangles UML 2.5b1 UML 2.5 Resolved closed
UML25-543 Ownership of property qualifier rectangles UML 2.5b1 UML 2.5 Resolved closed
UML25-545 Labels for generalization sets in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-542 Dependencies with more than two ends in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-540 Dashed interaction lifelines in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-541 Classifier and state annotations in UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-539 Avoid covariant parameters in metamodel operation redefinition UML 2.5b1 UML 2.5 Resolved closed
UML25-538 Clarification of use of BNF for textual notations UML 2.5b1 UML 2.5 Resolved closed
UML25-535 The resolution to issue 18415 contains invalid OCL UML 2.5b1 UML 2.5 Resolved closed
UML25-537 ActivityParameterNode notation UML 2.5b1 UML 2.5 Resolved closed
UML25-536 The resolution to Issue 18528 contains incorrect OCL and operation names UML 2.5b1 UML 2.5 Resolved closed
UML25-533 The resolution to 18697 contains errors UML 2.5b1 UML 2.5 Resolved closed
UML25-534 Improve documentation of how derived properties are calculated UML 2.5b1 UML 2.5 Resolved closed
UML25-531 Association::endType() is inconsistent UML 2.5b1 UML 2.5 Resolved closed
UML25-532 Action operation redefinition is invalid UML 2.5b1 UML 2.5 Resolved closed
UML25-530 UML 2.5 FTF Receptions may not have a method UML 2.5b1 UML 2.5 Resolved closed
UML25-529 actors of a use case express the requirements of its subject(s) regarding its/their environment. UML 2.5b1 UML 2.5 Resolved closed
UML25-527 UML 2.5: Clarification of semantics for CreateLinkAction and DestroyLinkAction UML 2.5b1 UML 2.5 Resolved closed
UML25-525 Behavior after exceptions are encountered UML 2.5b1 UML 2.5 Resolved closed
UML25-528 UML: Parameter Direction and Effect UML 2.5b1 UML 2.5 Resolved closed
UML25-524 Completion events disambiguation UML 2.5b1 UML 2.5 Resolved closed
UML25-526 Event pools for passive objects UML 2.5b1 UML 2.5 Resolved closed
UML25-523 UML 2.5 Issue: specification for qualified association ends is in wrong clause UML 2.5b1 UML 2.5 Resolved closed
UML25-520 The current criteria used in UML for BehavioralFeature::isDistinguishable() is insufficient in practice UML 2.5b1 UML 2.5 Resolved closed
UML25-521 UseCases editorial change UML 2.5b1 UML 2.5 Resolved closed
UML25-522 UML 2.5 class_name UML 2.5b1 UML 2.5 Resolved closed
UML25-519 About UseCase description UML 2.5b1 UML 2.5 Resolved closed
UML25-516 UML2.5 clause 17 keyword inconsistency UML 2.5b1 UML 2.5 Resolved closed
UML25-518 Annex B summary table UML 2.5b1 UML 2.5 Resolved closed
UML25-517 Clarify that stereotypes can be applied to UML DI UML 2.5b1 UML 2.5 Resolved closed
UML25-515 UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole UML 2.5b1 UML 2.5 Resolved closed
UML25-514 UML2.5's Connector role constraint excludes inherited roles UML 2.5b1 UML 2.5 Resolved closed
UML25-513 parts should be allowed to show their interfaces UML 2.5b1 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-510 UML 2.5 FTF] Editorial / §15.5.1 p429 UML 2.5b1 UML 2.5 Resolved closed
UML25-511 Forked association notation ill-formed UML 2.5b1 UML 2.5 Resolved closed
UML25-509 Inheriting Connectors UML 2.5b1 UML 2.5 Resolved closed
UML25-508 UML 2.5 FTF 15.3.3 Page 406 decisionInputBehavior rather than decisionInput UML 2.5b1 UML 2.5 Resolved closed
UML25-507 UML 2.5 FTF 14.2.3 Page 327 Typo UML 2.5b1 UML 2.5 Resolved closed
UML25-506 Incorrect text on state list notation interchange UML 2.5b1 UML 2.5 Resolved closed
UML25-505 Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature UML 2.5b1 UML 2.5 Resolved closed
UML25-503 Interactions needs to fix Gate name Distinguishability rules UML 2.5b1 UML 2.5 Resolved closed
UML25-504 Classifier operation inherit(NamedElement[*]) : NamedElement[*] UML 2.5b1 UML 2.5 Resolved closed
UML25-501 UML 2.5 Beta 1 9.5.3 Qualifiers UML 2.5b1 UML 2.5 Resolved closed
UML25-502 ActionInputPin notations missing UML 2.5b1 UML 2.5 Resolved closed
UML25-500 Transition redefinition UML 2.5b1 UML 2.5 Resolved closed
UML25-499 Association notation for properties does not allow representation of aggregation UML 2.5b1 UML 2.5 Resolved closed
UML25-497 wrong multiplicity of redefining states UML 2.5b1 UML 2.5 Resolved closed
UML25-498 UML2.5 issue: incorrect use of oclKindOf()->notEmpty() UML 2.5b1 UML 2.5 Resolved closed
UML25-496 Keywords are inconsistently defined and applied UML 2.5b1 UML 2.5 Resolved closed
UML25-495 UML 2.5: ActivityPartition::represents keywords UML 2.5b1 UML 2.5 Resolved closed
UML25-494 UML2.5 issue: clause 7.7.5 does not correctly refer to Instantiate stereotype UML 2.5b1 UML 2.5 Resolved closed
UML25-490 UML 2.5 FTF - Clause 17 Interactions, Section 17.2.3 Semantics, subsection Interaction UML 2.5b1 UML 2.5 Resolved closed
UML25-492 UML2.5 issue: clause 10 Signal and Reception UML 2.5b1 UML 2.5 Resolved closed
UML25-491 Conflict in use of unlimited natural UML 2.4.1 UML 2.5 Resolved closed
UML25-493 UML 2.5 - clause 14 does not put Examples at the correct heading level UML 2.5b1 UML 2.5 Resolved closed
UML25-489 Table C.1 apply UML 2.5b1 UML 2.5 Resolved closed
UML25-488 Metaclass operations incomplete UML 2.5b1 UML 2.5 Resolved closed
UML25-486 Classifier::hasVisibilityOf(...) UML 2.5b1 UML 2.5 Resolved closed
UML25-487 InformationFlow::sources_and_target_kind UML 2.5b1 UML 2.5 Resolved closed
UML25-482 Fixed-point issues with the definition of default values for literals UML 2.5b1 UML 2.5 Resolved closed
UML25-481 Error in Dependency notation example UML 2.5b1 UML 2.5 Resolved closed
UML25-485 Two entries UML 2.5b1 UML 2.5 Resolved closed
UML25-484 UML 2.5 issue; the word "individual" is incorrect in 9.8 UML 2.5b1 UML 2.5 Resolved closed
UML25-483 UML 2.5 issue: Clause 6.3 should contain a definition of "execution scope" UML 2.5b1 UML 2.5 Resolved closed
UML25-479 Inconsistent template binding notation example UML 2.5b1 UML 2.5 Resolved closed
UML25-480 Error in diagram using StringExpressions UML 2.5b1 UML 2.5 Resolved closed
UML25-478 Notation for state machine specializations UML 2.5b1 UML 2.5 Resolved closed
UML25-477 UML2.5 issue : missing constraints on aggregation / composition UML 2.5b1 UML 2.5 Resolved closed
UML25-473 confusing wording and terminology for TransitionKind in the section “Transition kinds relative to source”. UML 2.5b1 UML 2.5 Resolved closed
UML25-476 Two different Dashed Arrow Styles for Reply message in Figure 17.2 Interaction Example UML 2.5b1 UML 2.5 Resolved closed
UML25-475 Fix the notation to allow assignment of a decision to partition when the swimlanes are not practical. UML 2.5b1 UML 2.5 Resolved closed
UML25-472 The derived property Classifier::/inheritedMember does not correctly define the meaning of inheritance UML 2.5b1 UML 2.5 Resolved closed
UML25-474 UML association semantics vis-a-vis Interfaces (and other types of classifiers) UML 2.5b1 UML 2.5 Resolved closed
UML25-471 UML 2.5 issue: structural features with isStatic = true may not have a slot in InstanceSpecifications UML 2.5b1 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-464 Location: Index p. 796 among others - Index items with only one page 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-460 Location: Index 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-463 Location: Index p 795 - Index of "is" 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-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-455 Location: Annex C Keywords P. 777 - Previously unmentioned constraints given in Keywords Annex 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-452 Location: B.6 Classifier Description UMLInheritedStateBorderKind [Enumeration] Literals p 763 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-456 Location: Annex C Keywords p 777 - Capitalization of «trace» 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-449 Location: B.2.3 P. 738 - confusing model and diagram 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-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-444 Location: Table 21-1 P. 726 - Title of table not great 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-445 Location: Table 21-1 String P. 726 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-441 Location: Table 21-1 PrimitiveType semantics Real P. 726 - IEEE 754 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-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-440 Location: 21.1 Summary P. 726 - Missing header 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-437 Location: 18.1.1 Summary p 685 - emergent behavior 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-433 Location: 18.1.5 Examples Figure 18-10. 691 - Duplicate Diagram 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-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-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-434 Location: 18.2 Classifier Descriptions Include Constraints. 696 - Includes must be a DAG 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-426 Location: 18.1.4 Notation P. 688 - Point to diagram (05) 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-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-419 18.1.3 Semantics Use Case and Actors Extends P. 687 - Easy 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-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-422 Location: 18.1.4 Notation P. 688 - Point to diagram 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-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-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-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-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-598 included use case wrongly referred to as the including use case UML 1.4.2 UML 2.5 Resolved closed
UML25-599 multiplicity of the "role:ConnectableElement" UML 2.0 UML 2.5 Resolved closed
UML25-594 P.58 Missing closing bracket in second constraint UML 1.4.2 UML 2.5 Resolved closed
UML25-600 "role binding" UML 2.0 UML 2.5 Resolved closed
UML25-597 check the BNF example given in the text UML 1.4.2 UML 2.5 Resolved closed
UML25-596 UML 2 does not permit use of a state machine UML 2.0 UML 2.5 Resolved closed
UML25-592 "required interface" UML 2.0 UML 2.5 Resolved closed
UML25-595 Active and passive UML 1.4.2 UML 2.5 Resolved closed
UML25-593 P.35 Typo in OCL definition of isDistinguishableFrom query UML 1.4.2 UML 2.5 Resolved closed
UML25-591 Compliance points - Diagram Interchange UML 1.4.2 UML 2.5 Resolved closed
UML25-590 Bidirectional messages to a port object UML 1.4.2 UML 2.5 Resolved closed
UML25-586 Profiles in Compliance Level 1? UML 1.4.2 UML 2.5 Resolved closed
UML25-588 Figures 103 and 121 use <> dependencies UML 1.4.2 UML 2.5 Resolved closed
UML25-589 Figures 120 and 121 UML 1.4.2 UML 2.5 Resolved closed
UML25-585 Redundant parameter specifications for Operation and Behavior UML 1.4.2 UML 2.5 Resolved closed
UML25-587 . <> on Usage UML 1.4.2 UML 2.5 Resolved closed
UML25-584 Missing notation for Behaviors in a BehavioredClassifier UML 1.4.2 UML 2.5 Resolved closed
UML25-583 Name without a colon for Property in Composite Structures UML 1.4.2 UML 2.5 Resolved closed
UML25-582 UML 2 Super/Components/missing description of Connector::contract UML 1.4.2 UML 2.5 Resolved closed
UML25-581 UML 2 Super/Interactions/notation for accessing a static feature UML 1.4.2 UML 2.5 Resolved closed
UML25-578 UML2 super&infra/Profiles/ownership of Image UML 1.4.2 UML 2.5 Resolved closed
UML25-580 UML 2 Super/Templates/Template substitution symbol problematic UML 1.4.2 UML 2.5 Resolved closed
UML25-577 Port should specialize featuringClassifier UML 1.4.2 UML 2.5 Resolved closed
UML25-579 UML 2 Super/Activities/Class-Activity association missing UML 1.4.2 UML 2.5 Resolved closed
UML25-576 There is no "precise mapping UML 2.0 UML 2.5 Resolved closed
UML25-574 State Machine Package--Compliance RAS 2.0b1 UML 2.5 Resolved closed
UML25-575 Semantics section of StructuralFeature UML 2.0 UML 2.5 Resolved closed
UML25-573 Actions need to be independent from Activities RAS 2.0b1 UML 2.5 Resolved closed
UML25-572 Issue in UML 2 Gate class RAS 2.0b1 UML 2.5 Resolved closed
UML25-571 Issue in UML 2 CombinedFragment class RAS 2.0b1 UML 2.5 Resolved closed
UML25-569 Issue in UML 2 Message class RAS 2.0b1 UML 2.5 Resolved closed
UML25-566 Composite structures/contradictory constraint on connector RAS 2.0b1 UML 2.5 Resolved closed
UML25-570 Issue in UML 2 Message class RAS 2.0b1 UML 2.5 Resolved closed
UML25-568 UML 2 Super/Interfaces RAS 2.0b1 UML 2.5 Resolved closed
UML25-565 Description text for CollaborationOccurrence unclear UML 2.0 UML 2.5 Resolved closed
UML25-567 Concept of 'port side' not to be found in metamodel UML 2.0 UML 2.5 Resolved closed
UML25-564 Editrial error in Section: 9.3.4 ? UML 2.0 UML 2.5 Resolved closed
UML25-562 Section: 9.3.3 UML 2.0 UML 2.5 Resolved closed
UML25-563 Association collaborationRole UML 2.0 UML 2.5 Resolved closed
UML25-561 At «implementation Class», what does "a child of instance" mean?! UML 2.0 UML 2.5 Resolved closed
UML25-558 Section: 7.11.2 UML 2.0 UML 2.5 Resolved closed
UML25-560 It is not clear what 'related to' means UML 2.0 UML 2.5 Resolved closed
UML25-559 three possibilities for aggregation kind at 7.11.2, but only two notations UML 2.0 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-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-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-405 Location: Pg. 615, Figure 17.4.3: Semantics, Sub-clause: Messages 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-407 Location: LostMessage Row p 639 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-402 Location: Pg. 612, Figure 17.5 - Modify Figure 17.5 to enhance readability 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-397 Location: p 484 - Exception store 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-398 17.1.5 Interaction Diagram Variants p 607 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-391 Location: Figure 15-23 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-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-396 Location: Figure 15-23 p.411 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-387 Location: p. 337 Conflicting Transitions 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-382 Location: p. 333 FinalState 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-379 Location: p. 330 Deferred Events - Value of Deferred Events 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-386 Location: p. 337 Conflicting Transitions 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-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-370 Location: Page 341, State - More examples needed 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-373 Location: Transition , bottom of page 352 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-371 Location: Page 346, State List Notations 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-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-368 Location: Page 338, Transition selection algorithm - Maximal Set 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-364 Location: 14.2.1 Summary - Behavior StateMachines for UseCases 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-362 Location: Page 315 Association ends - Explain about having no nestedClassifier 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-361 Location: Page 313, 13.2.4 Notation relative 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-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-358 Location 13.1 Summary p 305 - Use of the word “emergent” 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-353 Location Figure 11-21 s p.216 - Instance/roll names 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-350 Location 10.4.4 Notations p.188 - Reception compartment 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-354 Location Figure 11-22 s p.216 - Title doesn’t match contents 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-347 Location: 10.2.4 Notation p 184 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-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-343 Location p 162 two_parameter_sets: Why 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-340 Location p 153 complete_and_disjoint: Abstract Implication 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-336 Location p 145 Classifier Description: objects -> instances 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-334 Location: p 145 CallConcurrencyKind [Enumeration - blocks -- > locks 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-333 Location: p 145 (3X) Detail: simultaneously -- > concurrently 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-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-329 Location: 9.8.3 Semantics p 139 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-327 Location: 9.7.5 Examples p 134 Generalization Sets 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-324 Location: 9.6.3 Operations p 127 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-325 Location: 9.6.4 Notation p 127 Simplify description of syntax 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-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-319 Location: 9.5.3 p 121 Why not all empty 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-318 What is “Intentionally Not specified”? 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-314 Use isReadOnly default 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-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-315 Redefinition does not allow for overloading UML 2.4.1 UML 2.5 Resolved closed
UML25-310 Effect Intent UML 2.4.1 UML 2.5 Resolved closed
UML25-309 Return Parameter pronoun UML 2.4.1 UML 2.5 Resolved closed
UML25-308 Return Parameter order 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-307 Default value of readonly should be referenced UML 2.4.1 UML 2.5 Resolved closed
UML25-304 Alterative Scopes? UML 2.4.1 UML 2.5 Resolved closed
UML25-306 Redefinable Static attributes 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-302 Location: p.116 (9.4.3 Semantics) 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-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-294 IsNull not Boolean UML 2.4.1 UML 2.5 Resolved closed
UML25-296 Objects? 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-293 Turing Machine lurking paradox? 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-289 Two anonymous invariants UML 2.4.1 UML 2.5 Resolved closed
UML25-290 Min/Max UML 2.4.1 UML 2.5 Resolved closed
UML25-288 result() error UML 2.4.1 UML 2.5 Resolved closed
UML25-286 Set--> List UML 2.4.1 UML 2.5 Resolved closed
UML25-284 Invariant name UML 2.4.1 UML 2.5 Resolved closed
UML25-287 French 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-282 Duration Definition 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-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-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-276 body text strings 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-274 set - > list UML 2.4.1 UML 2.5 Resolved closed
UML25-275 sentence unclear 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-272 {ordered} at wrong end 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-271 Past vs Present UML 2.4.1 UML 2.5 Resolved closed
UML25-269 Notation: Real 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-264 Default value for LiteralString UML 2.4.1 UML 2.5 Resolved closed
UML25-266 LiteralNull semantics UML 2.4.1 UML 2.5 Resolved closed
UML25-268 Unlimited Natural 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-262 Negatively phrased sentence UML 2.4.1 UML 2.5 Resolved closed
UML25-263 Optional String Multiplicity 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-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-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-254 Use of the diamond symbol (?)needs to be explained 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-253 Instantiate Dependency 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-250 Missing OCL 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-247 Confusing description of types UML 2.4.1 UML 2.5 Resolved closed
UML25-249 While-->And 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-245 Missing TypedElement UML 2.4.1 UML 2.5 Resolved closed
UML25-243 Imports 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-246 Missing TypedElement - use of the term constrained seems to be circular 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-240 Packageable Elements and Imports UML 2.4.1 UML 2.5 Resolved closed
UML25-234 Owning Rules UML 2.4.1 UML 2.5 Resolved closed
UML25-239 Missing word 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-237 Clarification of imports 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-236 Namespace Abstract Syntax incorrect 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-233 Owning Comments UML 2.4.1 UML 2.5 Resolved closed
UML25-231 Owning Comments 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-228 What type of slash? 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-225 Figure 6.1 does not relate to rest of Specification 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-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-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-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-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-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-408 Location: Table 17.6 entire table p 646 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-221 Modeling Individuals UML 2.4.1 UML 2.5 Resolved closed
UML25-220 Within the System 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-219 Incarnation ? 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-217 Keyword Usage 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-215 DI Conformance implies Model Interchange Conformance 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-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
UML25-208 Superfluous word on p309 UML 2.5b1 UML 2.5 Resolved closed
UML25-206 ElementImport semantics UML 2.5b1 UML 2.5 Resolved closed
UML25-207 isConsistentWith() definition broken UML 2.5b1 UML 2.5 Resolved closed
UML25-204 Further clarify Element ownership constrains UML 2.5b1 UML 2.5 Resolved closed
UML25-203 Semantic conformance implies Abstract Syntax conformance UML 2.5b1 UML 2.5 Resolved closed
UML25-205 Same name" vs. "indistinguishable name" UML 2.5b1 UML 2.5 Resolved closed
UML25-202 Suggested improvements to conformance section UML 2.5b1 UML 2.5 Resolved closed
UML25-201 PDF links to Primitive Types don't work UML 2.5b1 UML 2.5 Resolved closed
UML25-200 Missing word in section 7.4.3, "Semantics" UML 2.5b1 UML 2.5 Resolved closed
UML25-199 Four typos UML 2.5b1 UML 2.5 Resolved closed
UML25-198 Declassifying of Annex D 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-197 Clarification on the semantics of Manifestation 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-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-192 Clarification on the semantics of Parameters 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

Issues Descriptions

Location: 9.6.4 Notation p 128: Confusing indentation

  • Key: UML25-345
  • Legacy Issue Number: 17930
  • Status: closed  
  • Source: Dassault Systemes ( Jim Logan)
  • 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

Typo in Interaction Example

  • Key: UML25-684
  • Legacy Issue Number: 19348
  • Status: closed  
  • Source: gmail.com ( Pete Karousos)
  • Summary:

    v=mymsg(w=myout:16):96

    // this is a reply message assigning the return value 69 to 'v'

    Either the 96 needs to be a 69 or vice-versa but the two should match.

  • Reported: UML 2.5b1 — Sun, 20 Apr 2014 04:00 GMT
  • Disposition: Duplicate or Merged — UML 2.5
  • Disposition Summary:

    No Data Available

  • Updated: Thu, 12 Mar 2015 01:57 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

Operation::isConsistentWith()

  • Key: UML25-679
  • Legacy Issue Number: 18807
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    I’m working on a couple of issues that complain that the rules for consistency of operation redefinition are incomplete.

    The current definition is this:

    isConsistentWith(redefinee : RedefinableElement) : Boolean

    {redefines RedefinableElement::isConsistentWith()}

    A redefining operation is consistent with a redefined operation if it has the same number of owned parameters, and the type of each owned parameter conforms to the type of the corresponding redefined parameter. The query isConsistentWith() specifies, for any two Operations in a context in which redefinition is possible, whether redefinition would be consistent in the sense of maintaining type covariance. Other senses of consistency may be required, for example to determine consistency in the sense of contravariance. Users may define alternative queries under names different from isConsistentWith(), as for example, users may define a query named isContravariantWith().

    pre: redefinee.isRedefinitionContextValid(self) body: redefinee.oclIsKindOf(Operation) and

    let op : Operation = redefinee.oclAsType(Operation) in

    self.ownedParameter->size() = op.ownedParameter->size() and

    Sequence

    {1..self.ownedParameter->size()}

    ->

    forAll(i |op.ownedParameter->at(1).type.conformsTo(self.ownedParameter->at.type))

    What this does is impose a “covariant” (Eiffel-like) rule on redefinition, but only on the types of the parameters – it ignores their names, multiplicity, ordering, uniqueness, direction or effect.

    The wording that says “Users may define alternative queries under names different from isConsistentWith(),…” seems to me to be unhelpful and misleading. Firstly, UML tools don’t normally provide such capabilities, and secondly, even if they did, the original consistency rule would still be enforced.

    There seem to me to be three approaches here.

    1. Tighten up the covariance rules so that they somehow incorporate names, multiplicity, uniqueness, ordering, direction etc.

    2. Recognize that “in” parameters should be contravariant, “out” and “return” parameters should be covariant, and “inout” parameters invariant, and make rules correspond to that.

    3. Relax things and make them more extensible. Remove the constraints on parameter replacement altogether (simply requiring the same number of parameters) and leave it to profiles to constrain what operation redefinition might mean.

    Given that the semantics for Operation says “In UML, such rules for type conformance are intentionally not specified” (although that sentence was inexplicably truncated between beta and betafinal) I think option 3 is correct.

    Any comments?

  • Reported: UML 2.5b1 — Wed, 10 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    issue withdrawn

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Profile::references_same_metamodel

  • Key: UML25-680
  • Legacy Issue Number: 18809
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Profile::references_same_metamodel

    All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference metamodel.

    inv: metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages()->

    union(metaclassReference.importedElement.allOwningPackages() )->notEmpty()

    Surely this OCL is completely wrong, both in its own right, and especially in the light of the following statement:

    Where both a metaclassReference and a metamodelReference are present on a profile, the latter is ignored and only the specific metaclasses are available.

    I’m thinking the right logic would be something like this:

    (metaClassReference->isEmpty() implies metamodelReference.importedPackage.member->forAll( m1, m2 | m1.allOwningPackages().intersection(m2.allOwningPackages())->notEmpty()))

    and

    metaclassReference.importedElement->forAll( m1, m2 | m1.allOwningPackages().intersection(m2.allOwningPackages())->notEmpty())

  • Reported: UML 2.5b1 — Thu, 11 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    duplicate of issue 18806 --withdrawn

  • Updated: Fri, 6 Mar 2015 23:16 GMT

redefined states

  • Key: UML25-678
  • Legacy Issue Number: 18757
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    It seems State can be redefined in one subtype only, because of multiplicity 0..1 of the "state" (see picture attached).
    That prevents from creating two subclasses which redefine the same states in inherited statemachine and our customers report the problem.

    I think, multiplicity should be changed to *.

  • Reported: UML 2.5b1 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    duplicate of issue 18455, issue closed by submitter

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Event pools for passive objects?

  • Key: UML25-677
  • Legacy Issue Number: 18755
  • Status: closed  
  • Source: Malina Software Corp. ( Bran Selic)
  • Summary:

    There does not seem to be any constraint that prevents a passive object from owning an event pool. Perhaps this is by design, but, if so, it is not clear how such an event pool is serviced. It looks like this should be clarified or perhaps a constraint preventing passive objects from having event pools should be introduced.

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    duplicate of issue 18754

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Who owns MessageEnds?

  • Key: UML25-676
  • Legacy Issue Number: 18734
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    I noticed that the metamodel does not have any composite property typed by MessageEnd.

    Since MessageEnd is a kind of NamedElement, we'd need to have a composite association to subset A_ownedMember_namespace.

  • Reported: UML 2.5b1 — Mon, 27 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 23:16 GMT

15.3.11 State (from BehaviorStateMachines, ProtocolStateMachines)

  • Key: UML25-629
  • Legacy Issue Number: 7862
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. Attributes:

    /isComposite

    /isSimple

    /isSubmachineState

    defined without a type ( it must be Boolean).

    2. Associations:

    redefinedState : State [0..1]

    Must be subsets RedefinableElement::redefinedElement.

    3.

    region : Region [*] – subsets ownedMember

    Must be “subsets Namespace::ownedMember”.

    4.

    /redefinitionContext : Classifier [1]

    This member must redefine RedefinableElement::redefinitionContext (they have different multiplicity).

    5.

    region : Region [0..1]

    Second member named ‘region’ with another multiplicity and different semantic.

    6. I think some associations must subset members from parents, but this is not present in spec. I think this chapter needs review.

  • Reported: XMI 1.0 — Tue, 31 Aug 1999 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

Notation of enumeration literals

  • Key: UML25-628
  • Legacy Issue Number: 7426
  • Status: closed  
  • Source: PostFinance ( Karl Guggisberg)
  • Summary:

    Notation of enumeration literals The UML Superstructure spec often writes enumeration literal in OCL expressions as a hash mark (#) followed by the name of the enumeration literal, i.e. #public (p. 20) #protected (p. 27) #composite (p.80) #false (p. 215) #unordered (p. 216) #entryPoint (p. 469) #deepHistory (p. 474) etc. Sometimes it also includes enumeration literals consisting of a (fully qualified) enumeration name followed by '::' and the enumeration literal name, i.e. Aggregation::none (p. 69) According to the OCL 2.0 spec, the second notation is correct (see Sec 7.4.2 in the OCL 2.0 spec) Suggestion: replace all occurences of enumeration literal names with a leading '#' by the notation introduced in OCL 2.0.

  • Reported: UML 2.0 — Tue, 1 Jun 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Disposition: Merged with 18124

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

UML2 Super / Templates / ordering of subExpressions

  • Key: UML25-626
  • Legacy Issue Number: 7882
  • Status: closed  
  • Source: Malina Software Corp. ( Bran Selic)
  • Summary:

    StringExpression:subExpression should be ordered

  • Reported: UML 1.4.2 — Wed, 27 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Actually, it seems that ordering was incorrectly applied to the opposite property StringExpression:: owning-
    Expression instead of StringExpression::subExpression. This should be corrected.

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

Figure 307 and Figure 308 are exactly the same

  • Key: UML25-627
  • Legacy Issue Number: 7884
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Figure 307 (Invocation Domain Model) and Figure 308 (Communication Domain Model) are exactly the same ("Copy&Paste error"). Communication Domain Model should be replaced

  • Reported: UML 2.0 — Wed, 27 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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 Super/ Classes / issue with Property::isComposite

  • Key: UML25-625
  • Legacy Issue Number: 7881
  • Status: closed  
  • Source: Malina Software Corp. ( Bran Selic)
  • Summary:

    There is a serious inconcistency in the specification with respect to Property::isComposite.

    In the description of Association, it states that "Composition is represented by the isComposite attribute on the part end of the association being set to true".

    But in the discussion of structured classifier parts or the discussion of profile extensions it implies the opposite. isComposite should be true for the end that is owned by the whole.

    This will have a serious impact on interchange (among other things) if different implementations put the "black diamond" on different ends of the composition...

  • Reported: UML 1.4.2 — Tue, 26 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

"Class" should read "Classifier" in Generalization subsection for Behaviore

  • Key: UML25-623
  • Legacy Issue Number: 7876
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Reference to the October 2005 UML 2 Superstructure Specification as delivered out of the FTF.

    Issue name: "Class" should read "Classifier" in Generalization subsection for BehavioredClassifier.

    Description:

    BehavioredClassifier text specification on page 468 lists generalization as Class (from Kernel)

    However, the syntax diagram Figure 311 on page 459 shows the generalization of BehavioredClassifer as Classifier(from Kernel)

    Figure 314 shows Class as a specialization, not a generalization, for Behaviored Classifier.

    I suspect 'Generalization Class (from Kernel)' on page 468 is an error in the text and it should read 'Generalization Classifier' (from Kernel).

  • Reported: UML 1.4.2 — Tue, 19 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

Associations section of InteractionUse

  • Key: UML25-624
  • Legacy Issue Number: 7879
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Tim Weilkiens)
  • Summary:

    Associations section of InteractionUse: Type of argument must be Action instead of InputPin. Add Property string

    {ordered}

    .

  • Reported: UML 2.0 — Sun, 24 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

15.3.14 Transition (from BehaviorStateMachines)

  • Key: UML25-620
  • Legacy Issue Number: 7864
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. Association:

    /redefinitionContext : Classifier [1]

    Must redefine RedefinableElement::redefinitionContext (different multiplicity).

    2.

    container [1]

    Defined without type (but (wonder?) with multiplicity!). J

    3.

    Generalizations: from NamedElement (from Kernel, Dependencies) and from RedefinableElement (from Kernel).

    But RedefinableElement inherited from NamedElement. What deep sense of this double inheritance from NamedElement?

  • Reported: XMI 1.0 — Tue, 7 Sep 1999 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

inconsistent Generalization subsections in spec format

  • Key: UML25-622
  • Legacy Issue Number: 7875
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    Reviewing of the new "generalization" subsections in the UML 2 spec, some are pointing down the inheritance hiearchy and some are pointing up.

    Section 6.5.1 Specification format says these sections are supposed to list the direct generalizations of a concept (see page 14, all the concepts "immediately above" in the hierarchy), yet I find many examples where metaclasses listed in Generalization subsections are the specializations of the concept.

    For example, Section 7.3.3 for Association correctly lists Classifier among its Generalizations, but 7.3.6 BehavioredClassifier(from Interfaces) lists BehavioredClassifier(from BasicBehaviors) thereby pointing down the hierarchy.

    Other examples are too numerous to list. The issue reported below may be another instance of this broader issue.

  • Reported: UML 1.4.2 — Tue, 19 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

15.3.10 Region (from BehaviorStateMachines)

  • Key: UML25-619
  • Legacy Issue Number: 7863
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.3.10 Region (from BehaviorStateMachines)

    Association:

    /redefinitionContext : Classifier [1]

    Must redefine RedefinableElement::redefinitionContext (they have different multiplicity).

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

notational standard for {subsets x} in textual contexts

  • Key: UML25-621
  • Legacy Issue Number: 7865
  • Status: closed  
  • Source: Capability Measurement ( Karl Frank)
  • Summary:

    The text of the UML 2 Finalized Superstructure spec randomly uses dots and doubled-colons, as separator characters, in specifying the metaattribute of a metaassociation end,

    {subsets <x>}


    It also randomly uses or does not use (a) capitalization, as in 'Subsets' and 'subsets', and (b) curly braces. These issues may seem trivial to some human readers but are of consequence wrt any attempt to programmatically navigate structured text..

    Details:

    The dot sometimes used as a navigation path separator, as is correct for OCL, and in other contexts the UML namespace separator, the double-colon, is used.

    Instances of the usage of the dot are at 7.3.5 BehavioralFeature, Association, ownedParameter (which also shows random variation, in not including the curly braces that sometimes set off the subsets property in the textual spec), and of the doubled-colons, at 17.2.1 InformationFlow, Associations target:NamedElement[ ]

    {Subsets DirectedRelationship::target}

    which also shows the occasional use of the curly braces.

    It seems that, since subsets is a relationship between the sets of instances that can qualify for occupying an end of an association, the dot notation, which is used for instance navigation in OCL and in familiar OO programming languages, is correct.

    Another reason for thinking the dot is correct is that the namespace separator implies that the named association end is part of the namespace of the Classifier at the other end, and that seems to imply that the end is navigable. There are some instances in the spec where the namespace separator is used, but wrt a non-navigable end.

    Question:
    what is the "standard" notation in the context of text outside of diagrams?
    Proposal:
    Revise the notation section for Association to make it explicit that the notational standards given there apply in both diagrams and text, and revise the text for consistency. The problem may be that the notational standard does not say whether it applies to text, diagrams, or both.

  • Reported: UML 1.4.2 — Fri, 15 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

15.3.8 Pseudostate (from BehaviorStateMachines)

  • Key: UML25-618
  • Legacy Issue Number: 7861
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.3.8 Pseudostate (from BehaviorStateMachines)

    Associations:

    stateMachine : Statemachine [0..1] – subsets Element::owner

    Like above: must be “subsets Vertex::container”.
    Type of stateMachine must be StateMachine (letter ‘M’ must be capital).

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

15.3.16 Vertex (from BehaviorStateMachines)

  • Key: UML25-617
  • Legacy Issue Number: 7860
  • Status: closed  
  • Source: Anonymous
  • Summary:

    15.3.16 Vertex (from BehaviorStateMachines)

    Associations:

    container : Region [0..1] – subsets Element::owner

    This is a mistake, because Element::owner is already subsetted in parent of Vertex – NamedElement::namespace.

    Must be “subsets NamedElement::namespace”

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

Artifact (from Artifacts)

  • Key: UML25-616
  • Legacy Issue Number: 7859
  • Status: closed  
  • Source: Anonymous
  • Summary:

    P#224 – Figure 127 – Artifact (from Artifacts)

    P#769 – Figure 467 – Artifact (from Artifacts)

    Must be “Artifact (from Artifacts, Nodes)” because there is no “Artifact (from Artifacts)” in this document.

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

9.3.6 Connector (from InternalStructures)

  • Key: UML25-612
  • Legacy Issue Number: 7855
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Association

    redefinedConnector : Connector [0..*] – subsets Element.redefinedElement

    Element has no redefinedElement association. Change to RedefinableElement::redefinedElement

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

.3.44 Property (from Kernel)

  • Key: UML25-614
  • Legacy Issue Number: 7857
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Attribute:

    isReadOnly : Boolean

    This is redundant. Superclass of Property – StructuralFeature (from Kernel) has the same attribute with same default value. I think member isReadOnly can be inherited from StructuralFeature, and no needs define it in the Property.

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 15781

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

8.3.1 Component (from BasicComponents, PackagingComponents)

  • Key: UML25-613
  • Legacy Issue Number: 7856
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Association:

    ownedMember : PackageableElement [*]

    Conflicts with Namespace :: ownedMember. Perhaps add a word about redefine?

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

9.3.11 Port (from Ports)

  • Key: UML25-615
  • Legacy Issue Number: 7858
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A. All associations here are defined without multiplicity

    the multiplicity is given in the syntax diagram as * so [*] should be added to the text spec.

    B. redefinedPort : Port – subsets Element.redefinedElement.
    Element does not have member ‘redefinedElement’, must changed to be RedefinableElement::redefinedElement or (better yet) Property::redefinedProperty

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

7.3.24 Interface (from Interfaces)

  • Key: UML25-611
  • Legacy Issue Number: 7854
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A.

    Association:

    redefinedInterface : Interface – subsets Element :: redefinedElement

    Element does not have member redefinedElement. Must be: “RedefinableElement :: redefinedElement”.
    Or better yet, change to “Classifier :: redefinedClassifier”.

    B.

    Association:

    ownedAttribute : Property – subsets Namespace.ownedMember and Classifier.feature

    instead of Classifier.feature, ownedAttribute subsets Classifier.attribute. See Figure 9 where Classifier.attribute:Property is annotated as

    {subsets feature}

  • Reported: UML 1.4.2 — Thu, 14 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

UML2 super/CommonBehavior/Opaque behavior : bad OO modelling

  • Key: UML25-610
  • Legacy Issue Number: 7850
  • Status: closed  
  • Source: Softeam ( Philippe Desfray)
  • Summary:

    When we see the attributes of OpaqueBehavior :
    • body : String [1..*] Specifies the behavior in one or more languages.
    • language : String [*] Languages the body strings use in the same order as
    the body strings.

    We can state that this is bad modelling practice : two attributes are sets,
    which elements have to be related 2 by 2 according to an ordering rule. This
    is even bad database modeling practice (violation of the 1st normal form
    rule).

    Proposition :
    Create an additional class "Language expression", having 2 attributes :
    Language and Body, and relate it to "OpaqueBehavior" instead of these two
    guilty attributes.

  • Reported: UML 1.4.2 — Wed, 13 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    The proposed change may be better OO modeling practice, but it would cause a significant backward incompatibility
    for model interchange. Note that the patter of parallel body and language attributes is used not only for OpaqueBehavior,
    but also for OpaqueExpression and OpaqueAction. The cost of making such a change in all these cases does
    not seem worth the benefit of a marginal improvement in modeling practice.
    Disposition: Closed - No Change

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

Dependency associations

  • Key: UML25-608
  • Legacy Issue Number: 7847
  • Status: closed  
  • Source: Borland corp. ( Oleg Smirnov)
  • Summary:

    I think, that Dependency associations must subset (or specialize?): Dependency::client - DirectedRelationship::source Dependency::supplier - DirectedRelationship::target

  • Reported: UML 2.0 — Fri, 8 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

Deployment (from ComponentDeployments, Nodes)

  • Key: UML25-609
  • Legacy Issue Number: 7848
  • Status: closed  
  • Source: Borland corp. ( Oleg Smirnov)
  • Summary:

    Deployment (from ComponentDeployments, Nodes): Associatons: • configuration : deploymentSpecification [*] The specification of properties that parameterize the deployment and execution of one or more Artifacts. This association is specialized from the ownedMember association. There is no "ownedMember" association in inheritance hierarchy of Deployment.

  • Reported: UML 2.0 — Fri, 8 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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 Superstructure -Incompatible use of term link

  • Key: UML25-606
  • Legacy Issue Number: 7825
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    The Semantics of Association says:

    "An association declares that there can be links between instances of the
    associated types. A link is a tuple with one value for
    each end of the assocaition, where each value is an instance of the type of
    the end."

    but in Semantics of Connector the spec states:

    "Specifies a link that enables communication between two or more instances.
    This link may be an instance of an association, or
    it may represent the possibility of the instances being able to communicate
    because their identities are known by virtue of
    being passed in as parameters, held in variables or slots, or because the
    communicating instances are the same instance."

    The small issue is that link is used in incompatible ways which is
    confusing. The bigger issue is that Connectors may be typed by Associations
    and even if there is no actual type, one is "inferred". I would have thought
    that an instance of a Connector (a link) typed by an Association would have
    to be an Association Instance; one possible interpretation of this is that
    an instance of a Connector is only an Association Instance if it has a
    "non-inferred" type, although the value of "inferring" a type seems dubious
    if that is the case. The spec should clarify the situation.

  • Reported: UML 1.4.2 — Thu, 30 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

Associations between interfaces

  • Key: UML25-602
  • Legacy Issue Number: 7777
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    The caption of Figure 63 of the FAS (Figure 56 of the 040814 PDF) shows
    an association between example interfaces IAlarm, ISensor, and has this
    caption:

    IAlarm is the required interface for any classifier implementing
    Isensor; conversely, Isensor is the required interface for any
    classifier implementing IAlarm.

    The text description says:

    A set of interfaces constituting a protocol may be depicted as
    interfaces with associations between them

    Is this just notation, or are associations really in the model?

    • If it is just notation, what is the model?
    • If it is the model, isn't it overly restrictive? The modeler's
      intention might be that these are both required interfaces,
      declaring that the two support classes will include an association
      between them. I thought interface were extended in UML 2 to include
      associations generally.
  • Reported: UML 1.4.2 — Fri, 27 Aug 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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 Super/Templates/Inconsistent organization

  • Key: UML25-607
  • Legacy Issue Number: 7831
  • Status: closed  
  • Source: Malina Software Corp. ( Bran Selic)
  • Summary:

    The section describing Templates is organized in a completely different way than all the other chapters in the spec. It should be made consistent with the rest of the spec

  • Reported: UML 1.4.2 — Fri, 1 Oct 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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

CollaborationOccurence

  • Key: UML25-603
  • Legacy Issue Number: 7778
  • Status: closed  
  • Source: Silogic ( Yves BERNARD)
  • Summary:

    The ability for a CollaborationOccurence to be owned by an operation is stated in the CollaborationOccurence semantics but doesn't appear in the metamodel (c.f. Figure 100). More I think that the constraints specified for a CollaborationOccurence should be clarified to to take into account that the owner may be an operation.

  • Reported: UML 2.0 — Tue, 21 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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 Superstructure - cross-hair notation for nested classes

  • Key: UML25-605
  • Legacy Issue Number: 7784
  • Status: closed  
  • Source: The MathWorks ( Alan Moore)
  • Summary:

    The cross-hair notation is specified as an alternate notation for showing
    the containment of classifiers in packages, but there is no mention of the
    use of this notation for nesting classifiers within classes - this notation
    was present in UML 1.4 and so for backwards compatibility reasons should be
    in 2.0 also. I also note that the cross-hair notation does not appear in the
    diagrams section of Classes.

  • Reported: UML 1.4.2 — Fri, 24 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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.0 Issue: Semantics of Provided and Required Interfaces

  • Key: UML25-604
  • Legacy Issue Number: 7779
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In your presentation in Bertinoro you had
    a figure representing the mapping of the classic 'lollipop-notation' for
    provided and required interfaces into stereotyped dependencies between
    the port and the interfaces. I would like to propose that a similar
    picture be included in the specification to make the intent of the
    specification clearer. A good place for this figure would probably be
    9.3.11, Notation, just after Figure 110 (based on ptc/03-08-02).

  • Reported: UML 1.4.2 — Tue, 21 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    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 Super and Infra/ defualt property of Parameter::effect

  • Key: UML25-601
  • Legacy Issue Number: 7758
  • Status: closed  
  • Source: Malina Software Corp. ( Bran Selic)
  • Summary:

    I think it makes sense that the default value of Parameter::effect be 'read' (currently it is not specified).

  • Reported: UML 1.4.2 — Sun, 19 Sep 2004 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Discussion
    There is no need for any default value because Parameter::effect is 0..1.
    Disposition: Closed - No Change

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

Incomplete sentence

  • Key: UML25-673
  • Legacy Issue Number: 19419
  • Status: closed  
  • Source: toshiba-tsip.com ( VIRESH MOHAN)
  • Summary:

    In Section 9.6.3 Operations block, there is an incomplete sentence in one of the paragraphs.
    "
    Different type-conformance systems adopt different schemes for how the types of parameters and results may vary when an Operation is redefined in a specialization. When the type may not vary, it is called invariance. When the parameter type may be specialized in a specialized type, it is called covariance. When the parameter type may be generalized in a specialized type, it is called contravariance. In UML, s"

    As you can see the last sentence in the above paragraph is incomplete.

  • Reported: UML 2.5b1 — Tue, 20 May 2014 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

TestIdentityAction for datatypes

  • Key: UML25-674
  • Legacy Issue Number: 14989
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    In UML, TestIdentityAction does not currently apply to datatypes. The
    introduction and description of TestIdentityAction say
    "TestIdentifyAction is an action that tests if two values are identical
    objects. This action returns true if the two input values are the same
    identity, false if they are not." Data type values are not objects and
    do not have identity (that is, you cannot tell one data type value from
    another).

    If it is decided that the execution engine should not reflect the above
    semantics, the semantics of TestIdentityAction needs to be extended for
    unstructured datatype values to test whether the values are the same.
    For structured values, such as strings, the values and their contents
    would need to be the same, recursively if they contain more datatype
    values.

  • Reported: FUML 1.0b2 — Tue, 19 Jan 2010 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is obsolete. The specification of the semantics of TestIdentityAction in the UML 2.5 beta specification, in
    Subclause 16.4.3, under “Test Identity Actions”, covers the testing of instances of data types.
    Disposition: Closed - No Change

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

Problems with OCL definition of Package::makesVisible

  • Key: UML25-672
  • Legacy Issue Number: 19069
  • Status: closed  
  • Source: Dassault Systemes ( Tomas Juknevicius)
  • Summary:

    Looking at the UML2.5 specification draft (I have the document UML25AfterBallot9.pdf - not sure if this is the newest one)
    I see problems with definition of Package::makesVisible - which is expressed in OCL.:

    makesVisible(el : NamedElement) : Boolean
    The query makesVisible() defines whether a Package makes an element visible outside itself. Elements with no visibility and elements with public visibility are made visible.
    pre: member->includes(el)
    body: ownedMember->includes(el) or
    (elementImport->select(ei|ei.importedElement = VisibilityKind::public)>collect(importedElement.oclAsType(NamedElement))>includes(el)) or
    (packageImport->select(visibility = VisibilityKind::public)>collect(importedPackage.member>includes(el))->notEmpty())

    Actually those problems carry on from the previous versions of UML;
    but since in previous versions even the OCL syntax was wrong (carried over from the pre-OCL2.0 times)
    I assumed this section is old/abandoned and did not pay much attention to it.

    But now with UML2.5 somebody took it seriously to update the syntax of the OCLs (kudos for that brave soul ), so we have an updated variant.
    But while the raw syntax problems were fixed, semantic problems were carried form the old revision verbatim.
    If we are updating OCLs anyway, I think it would be a good time to also correct those.

    So here goes:

    --------------------------------------------------------------------------------
    Problem #1

    the following comparison is nonsensical (the case handling ElementImports, line #2 of the body):

    ei.importedElement = VisibilityKind::public

    The OCL here tries to compare the model element (at the end of ElementImport relationship) with the enumeration literal - VisibilityKind::public, which is not what we want
    I think this passage should be restated as follows:

    ei.visibility= VisibilityKind::public

    i.e. we want to test whether element import has visibility set to public, just as in the other case - with package imports - one line below.

    Also the whole case handling element imports could be rewritten to simplify it:
    elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el)
    This does not change the semantics, but is much better readable/understandable: we are iterating through all (public) element imports
    checking whether imported element matches the element el.

    --------------------------------------------------------------------------------
    Problem #2
    the case handling package imports (line #3 of the body) is also borked:

    packageImport->select(visibility = VisibilityKind::public)>collect(importedPackage.member>includes(el))->notEmpty()

    Here the first part of the expression is OK; we take all package import relationships and filter them - accept only public ones:

    packageImport->select(visibility = VisibilityKind::public)
    But the next part again makes no sense

    ...>collect(importedPackage.member>includes(el))->notEmpty()
    here expression part

    importedPackage.member->includes(el)

    produces a boolean - whether element el is included among the members of the package being imported.
    So the result of the expression part

    ...>collect(importedPackage.member>includes(el))...
    is a collection of booleans (of the form:

    {false, false, true, false, true}

    ),
    where each boolean signifies whether element is among the members of each particular imported package.

    Then it makes no sense to test that for emptiness:

    ->notEmpty()
    this produces true if there is at least one item (does not matter true, or false) in that bag of booleans.
    So that part produces true if there is at least 1 public package import ( it does not matter what package is imported).

    I think this passage should be restated as follows:

    packageImport->select(visibility = VisibilityKind::public)>exists(importedPackage.member>includes(el))
    I.e. we are iterating through all (public) package imports and checking whether element el appears among members
    of at least one of the imported packages.

    --------------------------------------------------------------------------------

    So the final OCL of makesVisible could be (also getting rid of some unnecessary parentheses, and further simplification):

    pre: member->includes(el)
    body:
    ownedMember->includes(el) or
    elementImport->exists(ei|ei.visibility = VisibilityKind::public and ei.importedElement = el) or
    packageImport->exists(pi|pi.visibility = VisibilityKind::public and pi.importedPackage.member->includes(el))

  • Reported: UML 2.5b1 — Wed, 25 Sep 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

Modeling sent messages in State Machines

  • Key: UML25-675
  • Legacy Issue Number: 15145
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Adrian Noguero)
  • Summary:

    Currently it is not possible to define formally in a state machine diagram that a behavior linked to a transition/state triggers a message to be sent through a port.
    I think that being able to formally describe this would in fact make this kind of diagrams very valuable for compositional verification of state machine diagrams. See "Towards the Compositional Verification of Real-Time UML Designs" by Holger Giese et al. for reference

  • Reported: UML 2.3b1 — Wed, 24 Mar 2010 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This issue is not entirely clear, but it would seem that the desired capability is available by using an InvocationAction
    with onPort, as now described more fully in the UML 2.5 beta specification in Subclause 16.3.3, under “Invocation
    Actions and Ports”.
    Disposition: Closed - No Change

  • Updated: Fri, 6 Mar 2015 20:59 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 ( Nicolas 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

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

Surplus classifier field serialized in Superstructure.xmi

  • Key: UML25-667
  • Legacy Issue Number: 17507
  • Status: closed  
  • Source: Dassault Systemes ( 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

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

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

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

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

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

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

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

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

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

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

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

how to instantiate associations between stereotypes

  • Key: UML25-654
  • Legacy Issue Number: 17160
  • Status: closed  
  • Source: Model Driven Solutions ( 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

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

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

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

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

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

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

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

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

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

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

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

"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

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

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

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

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

{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

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

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

EnumerationLiterals in the XMI

  • Key: UML25-631
  • Legacy Issue Number: 16584
  • Status: closed  
  • Source: agnos.ai UK Ltd ( 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

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

Activity::structuredNode is incorrectly marked as readOnly = true

  • Key: UML25-554
  • Legacy Issue Number: 18948
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Activity::structuredNode is incorrectly marked as readOnly = true

  • Reported: UML 2.5b1 — Fri, 20 Sep 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This appears to be a throwback to 2.4, in which it was also marked as derived - it got marked as not derived
    by the resolution to urgent issue 16232. In 2.4 it was readonly and derived; in 2.4.1 it was neither (which
    means that readonly was removed when the issue was applied, even though the issue did not call for that);
    in 2.5 it has for some reason become readonly again. The only explanation I might offer for this is that
    somebody noticed while applying 16232 that readonly needed to be removed and did it, but this change did
    not get checked in.
    The resolution is to set readOnly to false. The only impact on the specification document is figure 16.45,
    which needs to be changed. The generated classifier descriptions do not contain the

    {readOnly}

    annotation

    • this is a separate issue which will need to be addressed in the future but is too disruptive to address at
      the time of writing. The consequence is that no change is needed to the generated classifier description for
      Activity::structuredNode.
  • Updated: Fri, 6 Mar 2015 20:59 GMT

misleading omission

  • Key: UML25-553
  • Legacy Issue Number: 18947
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The text in 6.1 and Annex E describing the serialization compatibility between 2.4.1 and 2.5 omits to mention that the clientDependency attribute needs to be present in 2.4.1 and absent in 2.5 for all NamedElements that are the clients of a Dependency. This omission is misleading

  • Reported: UML 2.5b1 — Fri, 20 Sep 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Include wording in 6.1 and Annex E to explain this change. Also point out that ordering may have been
    either added or removed from some properties for semantic consistency

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

Validation errors in UML metamodel

  • Key: UML25-552
  • Legacy Issue Number: 18873
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    A body condition is specified for operation '<<oMGIssueTag>> <Operation> clientDependency () : Dependency [0..*]', but it is not a query.

    A body condition is specified for operation '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean', but it is not a query.

    Derived union '<<oMGIssueTag>> <Property> / action : Action [0..1]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / action : Action [0..1]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / classifier : Classifier [0..1]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / directedRelationship : DirectedRelationship [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / directedRelationship : DirectedRelationship [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / memberNamespace : Namespace [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / relationship : Relationship [0..*]' is not read only.

    Derived union '<<oMGIssueTag>> <Property> / structuredClassifier : StructuredClassifier [0..*]' is not read only.

    IRJA0273E "<Package> Activities" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> Actions."

    IRJA0273E "<Package> CommonBehavior" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    IRJA0273E "<Package> Deployments" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers."

    IRJA0273E "<Package> InformationFlows" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers, <Package> UseCases."

    IRJA0273E "<Package> Interactions" has one or more package import cycles involving "<Package> Classification, <Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure."

    IRJA0273E "<Package> SimpleClassifiers" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    IRJA0273E "<Package> StateMachines" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    IRJA0273E "<Package> UML" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> Actions."

    IRJA0273E "<Package> UseCases" has one or more package import cycles involving "<Package> Packages, <Package> CommonStructure, <Package> Classification, <Package> StructuredClassifiers."

    IRJA0273E "<Package> Values" has one or more package import cycles involving "<Package> StructuredClassifiers, <Package> Packages, <Package> CommonStructure, <Package> Classification."

    Redefining element '<<oMGIssueTag>> <Operation> isDistinguishableFrom (n : NamedElement, ns : Namespace) : Boolean' is not consistent with redefined element '<Operation> isDistinguishableFrom (n : NamedElement, ns : Namespace) : Boolean'. UML::Interactions::Gate::isDistinguishableFrom Model Validation Problem

    Redefining element '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean' is not consistent with redefined element '<Operation> isConsistentWith (redefinee : RedefinableElement) : Boolean'. UML::Activities::ActivityNode::isConsistentWith Model Validation Problem

    Redefining element '<Property> region : Region [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_region::region Model Validation Problem

    Redefining element '<Property> state : State [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_state::state Model Validation Problem

    Redefining element '<Property> structuredClassifier : StructuredClassifier [0..1]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / structuredClassifier : StructuredClassifier [0..*]'. UML::StructuredClassifiers::A_ownedAttribute_structuredClassifier::structuredClassifier Model Validation Problem

    Redefining element '<Property> transition : Transition [0..*]' is not consistent with redefined element '<<oMGIssueTag>> <Property> / redefinableElement : RedefinableElement [0..*]'. UML::StateMachines::A_redefinitionContext_transition::transition Model Validation Problem

  • Reported: UML 2.5b1 — Wed, 14 Aug 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The operations with bodies definitely need to be marked as queries.
    The derived unions definitely need to be marked as readonly. Cyclic package imports are not invalid.
    Three of the redefinitions are in fact invalid:
    region : Region [0..*]’ is not consistent with redefinableElement : RedefinableElement [0..*]
    state : State [0..*]’ is not consistent with redefined element redefinableElement : RedefinableElement [0..*]
    transition : Transition [0..*]’ is not consistent with redefined element redefinableElement : RedefinableElement
    [0..*]’.
    They appear in figure 14.35. The navigable ends of these associations are derived to mean “the nearest
    containing”. The non-navigable ends should be subsets (e.g. “the subset of elements redefined in this
    context that happen to be states”), not redefinitions.
    The remainder are not errors.

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

UML 2.5 issue: subsettingContext() has incorrect logic

  • Key: UML25-551
  • Legacy Issue Number: 18859
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The current logic says

    if association <> null then association.endType->excluding(type)

    But if the association has many ends of the same type, this is the wrong logic. Note this is independent of the fact that endType is a set – if it were a bag or sequence all occurrences of the type would be removed.

    It needs to work directly with the memberEnds – remove the current property from the memberEnds and collect the remaining types.

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 18788

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

Annex E lacks sub-clauses for the XMI details for StandardProfile and UMLDI

  • Key: UML25-548
  • Legacy Issue Number: 18837
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Provide sub-clauses like the resolution for issue 18831

  • Reported: UML 2.5b1 — Wed, 31 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    This resolution depends on 18831.
    The nsPrefixes are taken from the UML 2.5 Beta1 XMI artifacts

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

Headed composite and not ownedElement

  • Key: UML25-550
  • Legacy Issue Number: 18858
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    In Figure B.3 (UML Diagrams and Diagram Elements) the heading property is composite, but not an ownedElement.

  • Reported: UML 2.5b1 — Wed, 7 Aug 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The heading property is just to identify the label that should conform to the heading syntax given in Annex
    A. It is not necessary for it to be composite. Heading labels will be owned by the diagram element they are
    nested in, like other labels

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

Assocation display options too narrow

  • Key: UML25-549
  • Legacy Issue Number: 18848
  • Status: closed  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    The options on class and composite diagrams for how associations are displayed (with/without dots, etc) apply to other diagrams, such as package and object diagrams.

  • Reported: UML 2.5b1 — Thu, 1 Aug 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Introduce a class for the association options that generalizes the classes for structure diagrams and use case
    diagrams.

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

PrimitiveTypes::UnlimitedNatural lacks an XML-compatible serialization for the 'unbounded' value

  • Key: UML25-547
  • Legacy Issue Number: 18831
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    Some tools serialize 'unbounded' as '*' as shown in the UML spec, other tools serialize 'unbounded' as '-1'.
    The UML spec needs a clear specification for the serialization of 'unbounded' to ensure interchange across tools.

  • Reported: UML 2.5b1 — Thu, 25 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The W3 XML Schema 1.1 DataTypes specification includes an example of a definition of a datatype that is
    conceptually equivalent to that of PrimitiveTypes::UnlimitedLiteral in clause 2.4.1.3 of the XML Schema
    1.1 DataTypes specification: http://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#atomic-vs-list
    2.4.1.3 Union datatypes
    Union types may be defined in either of two ways. When a union type is ’constructed’ by ’union’, its
    ’value space’, ’lexical space’, and ’lexical mapping’ are the “ordered unions” of the ’value spaces’, ’lexical
    spaces’, and ’lexical mappings’ of its ’member types’. It will be observed that the ’lexical mapping’ of a
    union, so defined, is not necessarily a function: a given ’literal’ may map to one value or to several values
    of different ’primitive’ datatypes, and it may be indeterminate which value is to be preferred in a particular
    context. When the datatypes defined here are used in the context of [XSD 1.1 Part 1: Structures], the xsi:type
    attribute defined by that specification in section xsi:type can be used to indicate which value a ’literal’ which
    is the content of an element should map to. In other contexts, other rules (such as type coercion rules) may
    be employed to determine which value is to be used. When a union type is defined by ’restricting’ another
    ’union’, its ’value space’, ’lexical space’, and ’lexical mapping’ are subsets of the ’value spaces’, ’lexical
    spaces’, and ’lexical mappings’ of its ’base type’. ’Union’ datatypes are always ’constructed’ from other
    datatypes; they are never ’primitive’. Currently, there are no ’built-in’ ’union’ datatypes.
    Example
    A prototypical example of a ’union’ type is the maxOccurs attribute on the element element in XML Schema
    itself: it is a union of nonNegativeInteger and an enumeration with the single member, the string “unbounded”,
    as shown below.
    <attributeGroup name="occurs">
    <attribute name="minOccurs" type="nonNegativeInteger"
    use="optional" default="1"/>
    <attribute name="maxOccurs"use="optional" default="1">
    <simpleType>
    <union>
    <simpleType>
    <restriction base=’nonNegativeInteger’/>
    </simpleType>
    <simpleType>
    <restriction base=’string’>
    <enumeration value=’unbounded’/>
    </restriction>
    </simpleType>
    </union>
    </simpleType>
    </attribute>
    </attributeGroup>
    It is not possible to follow the above example because theMOF/XMI restricts a schemaType to be a datatype
    defined in the XML Schema DataType specification

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

Wording corrections in Behavior Diagrams and Activity Diagram Labels

  • Key: UML25-546
  • Legacy Issue Number: 18823
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Clause B.4.2 (Behavior Diagrams), second bullet, UseCase => Actor.

    Clause B.4.3 (Activity Diagram Labels), second bullet, UMLObjectNodes with ActivityParameterNodes => UMLShapes with ActivityParameterNodes as modelElements

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Make the suggested edits

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

Template parameter rectangles

  • Key: UML25-544
  • Legacy Issue Number: 18820
  • Status: closed  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    Annex B should explain how template parameter rectangles are modeled

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify that the template signature rectangles have template signatures as modelElements

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

Ownership of property qualifier rectangles

  • Key: UML25-543
  • Legacy Issue Number: 18819
  • Status: closed  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    Annex B should explain the ownership of property qualifier rectangles

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add that the UMLShape for property qualifier rectangles is owned by the UMLEdge for the association
    being qualified

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

Labels for generalization sets in UML DI

  • Key: UML25-545
  • Legacy Issue Number: 18821
  • Status: closed  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    Annex B should explain how to model labels of generalization sets.

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add that generalization set constraint text are modeled as UMLLabels with generalization sets as modelElements,
    and that these labels and the ones for power types are owned by their generalization or generalization
    set edges. Also add that generalization set lines are modeled as UMLShapes with generalization sets as
    modelElements.

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

Dependencies with more than two ends in UML DI

  • Key: UML25-542
  • Legacy Issue Number: 18818
  • Status: closed  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    Annex B should explain how dependency lines with more than two ends are modeled

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify that a UMLShape is used as the central point of the arrows.

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

Dashed interaction lifelines in UML DI

  • Key: UML25-540
  • Legacy Issue Number: 18816
  • Status: closed  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    Interaction lifelines can be dashed, but the model in Annex B cannot express this.

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Add property to UMLInteractionDiagram to specify whether lifelines are dashed

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

Classifier and state annotations in UML DI

  • Key: UML25-541
  • Legacy Issue Number: 18817
  • Status: closed  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    Annex B should explain how the

    {abstract}

    annotations in UMLClassifierShapes and the

    {extended}

    and

    {final}

    annotations in UMLStateShapes are modeled.

  • Reported: UML 2.5b1 — Wed, 17 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clarify that these are direct instances of UMLLabel containing the text as specified by UML

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

Avoid covariant parameters in metamodel operation redefinition

  • Key: UML25-539
  • Legacy Issue Number: 18810
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The vast majority of operation redefinitions in the metamodel have invariant parameters, but four operations inconsistently use covariant parameter redefinition. MOF actually says nothing about whether covariant redefinition is allowed, but for consistency and type-safety the UML spec should avoid it. This can be done using a precondition that requires the parameter to be of the right type.

    Region::isRedefinitionContextValid(), State::isRedefinitionContextValid(), StateMachine::isRedefinitionContextValid(), and Classifer::conformsTo().

  • Reported: UML 2.5b1 — Thu, 11 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The operations that do not have covariant parameters are isCompatibleWith(p), isDistinguishableFrom(n,
    ns), and isConsistentWith(redefinee).
    The implementations of isCompatibleWith explicitly check the type of the parameter as part of the test:
    p.oclisKindOf(self.oclType()).
    The implementations of isDistinguishableFrom explicitly check the type of the parameter.
    The implementations of isConsistentWith call isRedefinitionContextValid() as a precondition. The truth of
    this precondition is a consequence of well-formedness rules.
    Rather than using a precondition as suggested in the issue, it is safer to make the operations explicitly check
    the parameter type in their logic.

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

Clarification of use of BNF for textual notations

  • Key: UML25-538
  • Legacy Issue Number: 18802
  • Status: closed  
  • Source: Model Driven Solutions ( Ed Seidewitz)
  • Summary:

    In a number of places, the UML specification uses BNF to specify textual notations. However, as for all UML surface syntax, UML textual notations are generally for presentation. There is no requirement that such notations be unambiguously parsable – for example, a modeler may use arbitrary characters like “/” and “:” in a property name, even though these are used as special punctuation in the BNF for property textual notation. This can be confusing to some readers, since BNF is commonly used to specify parsable programming language text. Therefore, it may be worth providing a general clarification of this up front, perhaps in Clause 6 of the specification.

  • Reported: UML 2.5b1 — Tue, 9 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Make such a clarification in 6.4.1

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

The resolution to issue 18415 contains invalid OCL

  • Key: UML25-535
  • Legacy Issue Number: 18792
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    18415 was applied in Ballot 6. The revised OCL for sources_and_targets_kind contains the expressions self.informationSource.classifier and self.informationTarget.classifier, which are not well-typed. The first subexpression gives a NamedElement which in general does not have a classifier. The correct OCL should check if it is an InstanceSpecification, cast to InstanceSpecification and then check its classifier.

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Revise the OCL and text related to sources_and_targets_kind, bearing in mind that an InstanceSpecification
    may in general have several classifiers

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

ActivityParameterNode notation

  • Key: UML25-537
  • Legacy Issue Number: 18801
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    Customers are constantly asking for the ability to show parameter direction on ActivityParameterNode symbol.

    UML spec says:
    An ActivityParameterNode is notated as an ObjectNode, except that the full textual specification of the associated Parameter (see sub clause 9.4) may be used to label the ActivityParameterNode instead of the normal name/type label.

    However, I can't find Parameter BNF.

    Could you please help me to find/define a "standard" notation and don't you think it should be clarified in the spec?

  • Reported: UML 2.5b1 — Thu, 4 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In 9.4.4 it says “There is no general notation for Parameter. Specific subclasses of BehavioralFeature define
    notation for their Parameters.”
    There are two subclasses of BehavioralFeature, Operation and Reception. Operation defines a notation for
    Parameter within its BNF. Reception says “Receptions are shown in the receptions compartment using the
    same notation as for Operations with the keyword «signal».”
    So there is only one notation for Parameter, and it should be defined there, so that ActivityParameterNode
    can refer to it.
    The notation for ParameterSet is incorrectly specified in the same way.
    This also resolves 17906.

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

The resolution to Issue 18528 contains incorrect OCL and operation names

  • Key: UML25-536
  • Legacy Issue Number: 18793
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    In the resolution to 18528, the operation getOperand() should have the type InteractionOperand, not InteractionFragment. Also the name getGateName() should be getName() throughout the revised text.

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Change the type of Gate::getOperand(), and fix the names

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

The resolution to 18697 contains errors

  • Key: UML25-533
  • Legacy Issue Number: 18790
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The definition for the new operation allRoles() contains no textual documentation. Also the OCL is wrong; it should read:

    allFeatures()>select(oclIsKindOf(ConnectableElement))>collect(oclAsType(ConnectableElement))->asSet()

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Provide a textual documentation and change the OCL

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

Improve documentation of how derived properties are calculated

  • Key: UML25-534
  • Legacy Issue Number: 18791
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Summary: Clause 6.4 needs to explain that derived properties are calculated by having an operation with the same name and return type.

  • Reported: UML 2.5b1 — Tue, 25 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Improve 6.4 to explain this.

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

Association::endType() is inconsistent

  • Key: UML25-531
  • Legacy Issue Number: 18788
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The operation Association::endType() is inconsistent in multiplicity and ordering with the derived property endType which it is intended to calculate – the property is [1..*, ordered, unique} and the operation is

    {0..*, ordered, nonunique}

    . We think that the property is correct and the operation should be changed to match.

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    In fact

    {ordered}

    is meaningless and unnecessary. Change both to be 1..*, unordered, unique. Introduce
    a constraint to ensure that all ends have a type, as stated in the semantics text in 11.5.3. Also change the
    definition of Property::subsettingContext which currently uses this property incorrectly.
    This resolves also 18859.

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

Action operation redefinition is invalid

  • Key: UML25-532
  • Legacy Issue Number: 18789
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The operation Action::allOwnedNodes() redefines Action::allActions(). That must surely be wrong.

  • Reported: UML 2.5b1 — Tue, 2 Jul 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    yes, this is wrong

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

UML 2.5 FTF Receptions may not have a method

  • Key: UML25-530
  • Legacy Issue Number: 18777
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    According to the semantics of reception it seems that there should be a constraint implying that no method is specified for a reception.

    context Reception
    inv: self.method->isEmpty()

    What do you think?

  • Reported: UML 2.5b1 — Wed, 12 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    No Data Available

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

actors of a use case express the requirements of its subject(s) regarding its/their environment.

  • Key: UML25-529
  • Legacy Issue Number: 18760
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    Quoted from §18.1.3, p686: “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. Actors may represent roles played by human users, external hardware, or other systems.”

    There are common cases where some actors (i.e. entities interaction with the subject) have no real needs (or requirements) by themselves for being part of a use case. Instead, the modeler use the specification of actors to defined what is not under the system responsibility. This seems a little odd to me to speak about “actor’s needs/requirements” in such a case. I would rather say that the actors of a use case express the requirements of its subject(s) regarding its/their environment.

  • Reported: UML 2.5b1 — Thu, 6 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Delete the contentious sentence (not actually mentioned in the issue, but the earlier sentence in 18.1.1 which
    talks about the “needs” of Actors) which adds no value to the spec.

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

UML 2.5: Clarification of semantics for CreateLinkAction and DestroyLinkAction

  • Key: UML25-527
  • Legacy Issue Number: 18756
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    Semantics for DestroyLinkAction, and possibly CreateLinkAction, need clarification for the case of hybrid associations, i.e. associations which mix unique and non-unique ends. For example, what does DestroyLinkAction do for the case of a unique end where one or more other ends are non-unique and there is more than one outgoing link for the same value at the unique end?

  • Reported: UML 2.5b1 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 9013

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

Behavior after exceptions are encountered

  • Key: UML25-525
  • Legacy Issue Number: 18753
  • Status: closed  
  • Source: Malina Software Corp. ( Bran Selic)
  • Summary:

    In the discussion of OpaqueBehaviors in caluse 13, it is mentioned that a Behavior may be "abandoned" after it has raised an exception. The semantics of "abandonment" following exceptions are not defined, except (it seems) for the specific case of ExecutableNodes in activities.

    So, is there something general that we can say in Common Behaviors about the state of a Behavior after it has encountered an exception? For example, in case of a state machine: is it meaningful for the state machine to handle an exception event after it has encountered an exception? (if so, what state is it in following an exception?)

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is referencing the following sentence in Subclause 13.2.3: “A FunctionBehavior may raise exceptions
    for certain input values, in which case the computation is abandoned.” It is rather odd to only mention
    exceptions in the specific case of FunctionBehaviors, since exceptions can potentially be raised by any kind
    of Behavior. This would be better explained more generally.

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

UML: Parameter Direction and Effect

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

    The rules on Parameter Direction and Effect, seem overly weak.

    It doesn't seem to make sense to have a formal "inout" to also have the formal effect "delete", because it would be clearer to say "in"

    It doesn't seem to make sense to a formal "inout" to also have the formal effect "create", because it would be clearer to say "out"

    And Conrad says:
    Seems like we could change the modeling constraints to prevent inouts for create and delete, if we didn't mind the backward incompatibility.

    But Ed Seidewitz says
    The object passed out in on inout parameter doesn't have to be the same one that was passed in.

    For a "create" effect, the text says "Objects passed out of executions of the behavior as values of the parameter do not exist before those executions start." It doesn't say anything about objects passed in. Therefore, you could pass a non-null value into an inout parameter with the "create" effect, as long as the object passed out is a different, new object.

    The wording for "delete" is a little less clear, but I think it is reasonable to assume that it means that the object passed in on an inout parameter is destroyed, but that some other object could be passed out.

    Indeed, conceptually, an inout parameter could conceptually be both "delete" AND "create", meaning you pass in an object that gets destroyed and then get out a newly created object. However, the abstract syntax only allows at most one effect on a parameter

    So, we have at least different suggestions for changes to this material.

  • Reported: UML 2.5b1 — Wed, 5 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Merged with 17891

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

Completion events disambiguation

  • Key: UML25-524
  • Legacy Issue Number: 18752
  • Status: closed  
  • Source: Malina Software Corp. ( Bran Selic)
  • Summary:

    Section 13.2.3 (Behaviors) refers to a "completion event" for Behaviors as does the StateMachines section. It appears that these are different two concepts that share the same name; the former seems to represent the termination of a Behavior whereas the latter specifies completion of one or more behaviors associated with a State (possibly one with multiple Regions). To avoid confusion between the two concepts, it would be useful to provide a clear specification of what is meant by a "completion event" in the CommonBehaviors semantics description. Also, it might be useful to choose a different name for this type of completion event to avoid confusion with the one in state machines (that particular term has been around since the original version of UML, so changing it would probably be more confusing).

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed

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

Event pools for passive objects

  • Key: UML25-526
  • Legacy Issue Number: 18754
  • Status: closed  
  • Source: Malina Software Corp. ( Bran Selic)
  • Summary:

    There does not seem to be any constraint that prevents a passive object from owning an event pool. Perhaps this is by design, but, if so, it is not clear how such an event pool is serviced. It looks like this should be clarified or perhaps a constraint preventing passive objects from having event pools should be introduced.

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Currently, the only constraint related to Class:isActive is the passive_class constraint that “Only an active Class may
    own Receptions and have a classifierBehavior.” This means that a passive class may still have ownedBehaviors (including
    methods of operations), and these may service the event pool of instances of the class. (Note also that a passive
    object may receive Signal instances into its event pool, even though its Class does not have receptions.)
    Disposition: Closed - No Change

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

UML 2.5 Issue: specification for qualified association ends is in wrong clause

  • Key: UML25-523
  • Legacy Issue Number: 18750
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The specification and examples for qualified association ends is currently in clause 9 but really ought to be in clause 11, where it should take into account the specification of multiplicity for association ends marked as unique.

  • Reported: UML 2.5b1 — Tue, 4 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Move the text fragments to the right place. The comment about unique ends has already been taken into
    account in 11.5.3.

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

The current criteria used in UML for BehavioralFeature::isDistinguishable() is insufficient in practice

  • Key: UML25-520
  • Legacy Issue Number: 18727
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    The current criteria only looks at the ordered collection of owned parameter types as a key for distinguishing behavioral features.
    For example, it means that, for UML, the following pairs of operations of the same name are not distinguishable:

    // difference in the parameter direction
    op1(String)
    op1():String

    // difference in the parameter effect
    op2(update String)
    op2(delete String)

    // difference in the parameter exception
    op3(Throwable)
    op3() throws Throwable

    // difference in the parameter collection characteristics
    op4(Set(String))
    op4(String[1])

    This means that UML is not able to represent some well-known programming languages where the above characteristics contribute to the signature of distinguishable operations (e.g., C, C++, Java, C#, …)

    This can be easily fixed.

    In the OCL for BehavioralFeature::isDistinguishableFrom(), replace:

    ...>isUnique(ownedParameter>collect(type))

    With:

    …>isUnique(ownedParameter>collect(p|Tuple

    {name=p.name, type=p.type,effect=p.effect,direction=p.direction,isException=p.isException,isStream=p.isStream,isOrdered=p.isOrdered,isUnique=p.isUnique,lower=p.lower,upper=p.upper}

    ))

    Since BehavioralFeature::ownedParameter is an ordered collection, the current definition constructs an ordered collection of the owned parameter types as a key for distinguishing BehavioralFeatures.

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

    agreed

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

UseCases editorial change

  • Key: UML25-521
  • Legacy Issue Number: 18730
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    In the sentence “The individual fragments are executed as the corresponding ExtensionPoints of the extending UseCase are reached”, “extending” should read “extended”.

  • Reported: UML 2.5b1 — Thu, 23 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    indeed it should

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

UML 2.5 class_name

  • Key: UML25-522
  • Legacy Issue Number: 18748
  • Status: closed  
  • Source: Sparx Systems Pty Ltd ( J.D. Baker)
  • Summary:

    In section 17.3.4 <class_name> appears on the right hand side of the BNF but it is not defined in any other BNF statement. This is the only place in the spec where <class_name> appears. <class-name> appears in the text following the BNF. <class_name> in the BNF should be changed to <class-name>.

    Recommend that we add the following statement to the BNF

    <class-name>::=<Variable> | <Parameter> | <Property>

  • Reported: UML 2.5b1 — Mon, 3 Jun 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The Interactions working group agreed during the Berlin meeting that class_name is not optimal. In fact,
    the non-terminal symbol class_name does not reflect what it actually represents, i.e., the name of the Type
    that the ConnectableElement, which is represented by the Lifeline, is typed with.
    In addition, the font style of the non-terminal symbols has to be set to italics.

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

About UseCase description

  • Key: UML25-519
  • Legacy Issue Number: 18726
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Sebastien Gerard)
  • Summary:

    The description of a UseCase is: “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.”.

    However, UseCase may have no subjects. What happen in that case?

  • Reported: UML 2.5b1 — Tue, 21 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Clause 18 is inconsistent in using “subject” in the singular in many places. Clarify that a UseCase may refer
    to many subjects or none.

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

UML2.5 clause 17 keyword inconsistency

  • Key: UML25-516
  • Legacy Issue Number: 18702
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    The notation for ConsiderIgnoreFragment incorrectly refers to ‘consider’ and ‘ignore’ as keywords. These should be fixed in a similar manner to issue 18454.

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

    agreed

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

Annex B summary table

  • Key: UML25-518
  • Legacy Issue Number: 18717
  • Status: closed  
  • Source: NIST ( Raphael Barbau)
  • Summary:

    It would probably help implementers of Annex B if it had something like the tables in BPMN's DI that show example graphics, the metaclasses involved, and some notes on how they're used, see the BPMN spec (http://www.omg.org/spec/BPMN/2.0/PDF), starting at Table 12.8 (Depiction Resolution for Loop Compensation Marker) in Section 12.3 (Notational Depiction Library and Abstract Element Resolutions).

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

    This issue is addressed by adding a table to the end of Annex B. This table shows example UML notations,
    and how they are represented in DI. The table refers the clauses and their figures, as well as Annex B clauses.

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

Clarify that stereotypes can be applied to UML DI

  • Key: UML25-517
  • Legacy Issue Number: 18715
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    [From Ed S in http://www.omg.org/archives/uml25-ftf/msg00357.html] Perhaps we can clarify this by simply adding some text to Annex B explicitly saying that stereotypes can be applied to UML DI elements and that a conforming tool is to interpret such stereotype application per 12.3.3 – that is, with the MOF equivalent semantics and XMI serialization. This would simply become part of the requirement for UML diagram interchange conformance. It seems like a useful capability to me.

  • Reported: UML 2.5b1 — Tue, 14 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    clarify as suggested

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

UML 2.5's Collaboration semantics is inconsistent with Collaboration::collaborationRole

  • Key: UML25-515
  • Legacy Issue Number: 18699
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    In UML 2.5 section 11.7.3 Collaboration Semantics says:

    Collaborations may be specialized from other Collaborations. If a role is extended in the specialization, its type in the specialized Collaboration must conform to its type in the general Collaboration. The specialization of the types of the roles does not imply corresponding specialization of the Classifiers that realize those roles. It is sufficient that they conform to the constraints defined by those roles.

    A specialized Collaboration can redefine some roles of its parent Collaborations but it should be possible to reuse them without redefining them.
    Unfortunately, this is not possible:

    Collaboration::collaborationRole subsets StructuredClassifier::/role, which is a derived union subsetted only by StructuredClassifier::ownedAttribute.

    That is, the inherited roles of a parent Collaboration are not roles of its specializing Collaborations.

    Currently, Collaboration::collaborationRole : ConnectableElement[*] subsets StructuredClassifier::role.
    That is, it is up to the discretion of the modeler to decide which subset of a Collaboration's roles are to be the Collaboration's collaborationRoles as well.

    It seems that the subset constraint is too strong; that is, it seems it should be relaxed such that a modeler could pick a subset of a Collaboration's roles and Collaboration's inherited roles as its collaborationRoles.
    That is, I suggest replacing:

    Collaboration::collaborationRole : ConnectableElement[*]

    {subsets StructuredClassifier::role}

    with:

    Collaboration::collaborationRole : ConnectableElement[*]

    { subsets Classifier::inheritedMember}

  • Reported: UML 2.5b1 — Tue, 7 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is based on a misunderstanding. In fact the modeler chooses some ConnectableElements to be collaborationRoles,
    and /role is derived from that.
    Disposition: Closed - No Change

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

UML2.5's Connector role constraint excludes inherited roles

  • Key: UML25-514
  • Legacy Issue Number: 18697
  • Status: closed  
  • Source: NASA ( Nicolas Rouquette)
  • Summary:

    UML 2.5, section 11.8 provides an OCL encoding of the following role constraint on a Connector:

    [3] 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))

    Inherited roles are excluded because StructuredClassifier::/role is a derived union that is subsetted only once by StructuredClassifier::ownedAttribute

    In 17.7.3, Collaboration Semantics, the UML spec uses the term 'role' in a way that clearly suggests a broader intent than a subset of owned attributes:

    Neither all Features nor all contents of the participating instances nor all links between these instances are always required in a particular Collaboration. Therefore, a Collaboration is often defined in terms of roles typed by Interfaces.

    Collaborations may be specialized from other Collaborations. If a role is extended in the specialization, its type in the specialized Collaboration must conform to its type in the general Collaboration. The specialization of the types of the roles does not imply corresponding specialization of the Classifiers that realize those roles. It is sufficient that they conform to the constraints defined by those roles.

    In 17.7.3 CollaborationUses semantics, the UML spec uses the term 'role' in a way that could not legitimately restricted to a subset of owned attributes but instead include inherited attributes:

    The roleBindings are implemented using Dependencies owned by the CollaborationUse. Each role in the Collaboration is bound by a distinct Dependency and is its supplier. The client of the Dependency is a ConnectableElement that relates in some way to the context Classifier: it may be a direct role of the context Classifier, or an element reachable by some set of references from the context Classifier. These roleBindings indicate which ConnectableElement from the context Classifier plays which role in the Collaboration.

    One of the CollaborationUses owned by a Classifier may be singled out as representing the Behavior of the Classifier as a whole. This is called the Classifier’s representation. The Collaboration that is related to the Classifier by its representation shows how the instances corresponding to the StructuralFeatures of this Classifier (e.g., its attributes and parts) interact to generate the overall Behavior of the Classifier. The representing Collaboration may be used to provide a description of the Behavior of the Classifier at a different level of abstraction than is offered by the internal structure of the Classifier. The Properties of the Classifier are mapped to roles in the Collaboration by the role bindings of the CollaborationUse.

    I suggest replacing the term 'role' in chapter 11 and 17 with 'all roles' or 'owned an inherited roles' where applicable.

    I also suggest introducing a query:

    StructuredClassifier::allRoles() : ConnectableElement[*]
    body: allFeatures()>select(oclAsKind(ConnectableElement))>collect(oclAsType(ConnectableElement))->asSet()

    Then the roles constraint on Connector in 11.8 should read:

    [3] The ConnectableElements attached as roles to each ConnectorEnd owned by a Connector must be owned or inherited roles of the Classifier
    that owned the Connector, or they must be ports of such roles.

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

  • Reported: UML 2.5b1 — Tue, 7 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Accept the suggestions in the issue. For the Collaborations clause, avoid using “role” at all and use “collaborationRole”
    instead, which is defined for that purpose.
    This also resolves 7416.

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

parts should be allowed to show their interfaces

  • Key: UML25-513
  • Legacy Issue Number: 18695
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Axel Scheithauer)
  • Summary:

    The specification allows ports on parts to also show the interfaces of the type of the port:

    page 202: "Lollipop and socket symbols may optionally be shown to indicate the provided and required interfaces of the Port, using the same notation as for the Port’s definition."

    The same thing is not allowed for parts. While it might be not all that important for parts, it makes the notation incoherent.

    Proposed Resolution:
    Add following sentence:

    "Lollipop and socket symbols may optionally be shown to indicate the provided and required interfaces of the Part, using the same notation as for the Part’s definition."

  • Reported: UML 2.5b1 — Fri, 3 May 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The issue is correct, and it is indeed inconsistent not to permit this option

  • 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 ( 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

UML 2.5 FTF] Editorial / §15.5.1 p429

  • Key: UML25-510
  • Legacy Issue Number: 18677
  • Status: closed  
  • Source: Airbus Group ( Yves Bernard)
  • Summary:

    I don’t know whether this has already been raised or corrected

    In §15.5.1 “Summary”, p429. The second sentence starts with: “Generally, tThe ControlNodes […]” => the double “t” has to be removed.

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

    This has already been corrected.
    Disposition: Closed - No Change

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

Forked association notation ill-formed

  • Key: UML25-511
  • Legacy Issue Number: 18684
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Description: Figure 11.34 (Composite aggregation sharing a source segment) shows three association lines sharing one end (window), implying the end is owned by three classes, which isn't possible. Even if the three classes redefine window using the same name, the "shared" end would actually be separate elements in the model, though they would appear notationally the same. If this is the intention, redefinition of window should be added to the figure, and the text should explain that the "shared" graphical elements refer to three underlying model elements, (Annex B should be updated also). The notation wasn't in 2.4.1 that I can find.

  • Reported: UML 2.5b1 — Wed, 24 Apr 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    The notation was in 2.4.1 and all earlier versions of UML. Quoting from UML 1.1 spec: “If there are two
    or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends
    into a single segment. This requires that all of the adornments on the aggregation ends be consistent. This
    is purely a presentation option; there are no additional semantics to it”. From UML 2.4.1: “If there are two
    or more aggregations to the same aggregate, they may be drawn as a tree by merging the aggregation ends
    into a single segment. Any adornments on that single segment apply to all of the aggregation ends.”
    Some clarification is in order, both with regard to this particular notation, and with regard to the general
    question of what adornments may be suppressed in the notation for an Association. In particular, there is
    a misleading note about the default values for uniqueness and ordering that implies that the absence of a
    prop-modifier on the diagram has a semantic consequence; whereas in fact it is just another adornment that
    may be suppressed.

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

Inheriting Connectors

  • Key: UML25-509
  • Legacy Issue Number: 18650
  • Status: closed  
  • Source: Dassault Systemes ( Nerijus Jankevicius)
  • Summary:

    If parts are redefined in a subclass, should connectors of original redefined parts be inherited? Or lost/hidden/redefined too as original part does not exist in a subclass anymore, so why connectors should?

    If inherited, how should they be represented? If inherited connector is shown attached to a new redefining part, it may look ambiguous as it is NOT attached to it in the model.

    See diagram attached

  • Reported: UML 2.5b1 — Wed, 10 Apr 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    There are two aspects to this issue. Firstly, it needs to be made clearer that redefinition causes the redefining
    feature to stand in for the redefined feature in all uses of the redefined feature, including referring to it. This
    applies in many circumstances including connectors, transitions and activity edges. Secondly, there needs
    to be a well-defined notation for inherited features (such as connectors) so that a diagram can depict an
    inherited connector connecting to a redefined part.
    In the case of provided interfaces there is already a notation using a forward slash. This seems ill-advised
    since forward slash normally means derived. Change this notation to be the caret, and make the forward
    slash a deprecated option.

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

UML 2.5 FTF 15.3.3 Page 406 decisionInputBehavior rather than decisionInput

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

    The semantics of DecisionNode consistently uses
    decisionInputBehavior. However the property is
    actually decisionInput. Similarly for the notation
    and the constraint two_input_parameters.

  • Reported: UML 2.5b1 — Tue, 19 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    agreed that this is incorrect

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

UML 2.5 FTF 14.2.3 Page 327 Typo

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

    Two examples of AnyReceivEvent rather than AnyReceiveEvent

  • Reported: UML 2.5b1 — Tue, 19 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Spelling error - Change “AnyReceivEvent” in section 14.2.3 to “AnyReceiveEvent”.

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

Incorrect text on state list notation interchange

  • Key: UML25-506
  • Legacy Issue Number: 18566
  • Status: closed  
  • Source: NIST ( Conrad Bock)
  • Summary:

    Under Figure 14.12 (Submachine Sate that uses an exit point), there is a NOTE saying the graphical notation for state lists cannot be exchanged normatively, but the interchange model for this given in the paragraph under Figure B.14 (State Shapes), starting at the third sentence.

  • Reported: UML 2.5b1 — Sun, 17 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    correct the statement cited

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

Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature

  • Key: UML25-505
  • Legacy Issue Number: 18545
  • Status: closed  
  • Source: Fraunhofer FOKUS ( Marc-Florian Wendland)
  • Summary:

    Message Constraint signature_is_Signal only merely refers to Signal.ownedAttributes as parameters of a Message signature. This is not sufficient, since a Signal may specialize other signals and, thus, the Message should also allow to specify arguments for inherited attributes. Of course, redefined attributes need to be sorted out.

  • Reported: UML 2.5b1 — Wed, 13 Mar 2013 04:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Instead of using the Signal.ownedAttributes directly in the OCL (let signalAttributes : OrderedSet(Property)
    = signature.oclAsType(Signal).ownedAttribute->asOrderedSet()) the inherited operation
    Classifier::inheritedMember():NamedElement[0..*] ought to be used in the let-statement. The operation
    filters redefined inherited elements and delivers the complete set of all inherited members, including the
    properties. These need to be extracted from the set of inherited members eventually. The resulting OCL
    would look like this:
    let signalAttributes : OrderedSet(Property) =
    signature.oclAsType(Signal).inheritedMember()->
    select(n:NamedElement | n.oclIsTypeOf(Property)->asOrderedSet()

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

Interactions needs to fix Gate name Distinguishability rules

  • Key: UML25-503
  • Legacy Issue Number: 18528
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The isDistingishableFrom() operation of NamedElement needs to be
    overridden for Gate class to cover the case of when the gate is used as
    a formalGate of an Interaction. The association end formalGate subsets
    ownedElement, and since the Gate name attribute is optional, it is
    allowed to have two formal gates without an explicit name, but having
    derived names which are distinct.

    Even though the gate matching rules do not use this operation, we need
    to override it to avoid problems.

    In addition to this fix, there is a also need to add constraints to the
    gate names used for Gates for the gate matching rules to work properly.
    In particular, there are cases in use of gates which require distinction
    for the gate matching rules to work.

    Thus there is still a need to add new constraints on gate Names (explicit
    or derived).

    Because Gates which do not have an explicity name attribute have derived
    names, any constraint must include the possibility of these derived
    names.

    There is an explicit operation getGateName() on Gate class which returns
    the name of the gate which is to be used in the gate matching rules. If
    a gate does not have an explicit name attribute, a gate name is derived
    from the name of the message the gate is attached to , and the direction
    of the message with respect to the gate (e.g, foo_in, foo_out). The
    direction "in" or "out" is considered with respect to the outer perimeter
    of the interaction fragment that the gate is attached to.

    UML 2.5 added Gate matching rules in OCL, using this getGateName()
    operation, however there are currently no gate name distinguishably
    constraints in the spec. Two gates in the same container may have
    duplicate derived names, just because they are attached to two different
    messages, with the same direction, which happen to have the same name.
    There are cases when the gate matching rules will not work unless at
    least one of these gates needs includes an explicit name attribute value
    contrived to avoid the collision of the getGateNames() operation.

    The association end formalGates of Interaction subset ownedMember, and,
    as already stated above, we have to override the isDistinguisableFrom()
    operator for gate class. However, If there were two formal Gates with
    the same gate name in an interaction, the gate matching rules would
    become invalid.

    The association ends actualGates of InteractionUse, and cFragmentGates
    of CombinedFragment, both subset ownedElement, not ownedMember. So they
    no not need to obey the isDistinguisableFrom test. However, even though
    not required for the UML namespace Rules, actual Gates for an
    InteractionUse should have distinguishable gate names, in order for the
    gate matching rules to work.

    For the same reason, If a cFragmentGate is outside the CombinedFragment,
    then it must be distinguishable from other outer cFragmentGates of that
    same CombinedFragment.

    For the same reason, any two inner cFragmentGates associated with the
    same InteractionOperator of a CombinedFragment must have distinguished
    gate names.

    Thus we need to add a set of four constraints (one for each kind of gate)
    to the Gate class. Adding these four constraints will ensure that the
    gate matching rules work correctly.

    Proposed Change:

    Override the isDistinguishableFrom() operation of Gate to always return
    true.

    Add the following four new constraints to the Gate class. These rely on
    the four existing boolean operators of the Gate class which are used to
    determine in which of the four contexts of association that the gate is
    an instance of.

    formal_gate_distinguishable
    isFormal() implies <test that no other formal
    gate of the parent Interaction returns the same getGateName() as returned
    for self>

    actual_gate_distinguishable
    isActual() implies <test that no other actual
    gate of the parent InteractionUse returns the same getGateName() as
    returned for self>

    outside_cf_gate_distinguishable
    isOutsideCF() implies <test that no other
    outside cf gate of the parent CombinedFragment returns the same
    getGateName() as returned for self>

    inside_cf_gate_distinguishable
    isInsideCF() implies <test that no other
    inside cf gate attached to a message with its other end in the same
    InteractionOperator as self returns the same getGateName() as returned
    for self>

    I leave the detailed OCL for the actual OCL to include within the < >
    for the actual resolution of this issue.

  • Reported: UML 2.5b1 — Tue, 5 Mar 2013 05:00 GMT
  • Disposition: Resolved — UML 2.5
  • Disposition Summary:

    Override the isDistinguishableFrom() operation of Gate to always return true.
    Fix a problem in the isInnerCF operation, to fix the other End Gate situation.
    Add the following four new constraints to the Gate class. These rely on the four existing boolean operators
    of the Gate class which are used to determine in which of the four contexts of association that the gate is an
    instance of.
    formal_gate_distinguishable isFormal() implies <test that no other formal gate of the parent Interaction
    returns the same getGateName() as returned for self>
    actual_gate_distinguishable isActual() implies <test that no other actual gate of the parent InteractionUse
    returns the same getGateName() as returned for self>
    outside_cf_gate_distinguishable isOutsideCF() implies <test that no other outside cf gate of the parent CombinedFragment
    returns the same getGateName() as returned for self>
    inside_cf_gate_distinguishable isInsideCF() implies <test that no other inside cf gate attached to a message
    with its other end in the same InteractionOperator as self returns the same getGateName() as returned for
    self>

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

Classifier operation inherit(NamedElement[*]) : NamedElement[*]

  • Key: UML25-504
  • Legacy Issue Number: 18544
  • Status: