Issue 15986: fUML 1.1 should be based on UML 2.4 (fuml-rtf) Source: Model Driven Solutions (Mr. Ed Seidewitz, ed-s(at)modeldriven.com) Nature: Uncategorized Issue Severity: Summary: Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 3 (ptc/10-03-14) Foundational UML (fUML) 1.0 as finalized is based on UML 2.3. With the completion of the UML 2.4 RTF, fUML should be moved to UML 2.4. This would be consistent with the recently adopted Alf action language specification, which will be finalized based on UML 2.4. Fortunately, nothing seems to have changed in UML 2.4 that would substantively effect the specification of the fUML abstract syntax subset. However, the fUML normative XMI should be regenerated consistent with UML 2.4/XMI 2.4. Further, UML 2.4 has separated the primitive type model into a separate XMI file with normative XMI IDs, and these should be used for referencing those types in the normative XMI for the fUML Foundational Model Library. Resolution: The following issues resolved in UML 2.4 and UML 2.4.1 have an impact on the fUML subset. • Issue 10831: “PackageableElement::visibility” uses “false” as default value • Issue 12583: OCL 2.0 8.2 Real • Issue 13718: Section 12.3.48 on page 412 • Issue 13993: UML 2.2 Issue - availability of PrimitiveTypes for UML models • Issue 14631: All enumeration literals in the model have their "classifier" collections empty • Issue 14632: Associations with same name that live in different packages violate unique name constraint • Issue 14926: is composite, but does not subset ownedElement • Issue 14931: remove BehavioredClassifier::ownedTrigger • Issue 14977: Matching subsettting across association ends • Issue 15369: UML 2.4: Add Property::isId • Issue 15370: UML 2.4: Add Package::URI • Issue 15526: Missing subsetting of redefinitionContext by Property::owningAssociation • Issue 15664: Property::isID should not be optional • Issue 16232: No unambiguous way in UML 2.4 to serialize StructuredActivityNode Further, comparison if the fUML 1.0 abstract syntax model with that of UML 2.4.1 identifies the following additional corrections need to fUML. • Remove Class::isAbstract attribute (this is already inherited from Classifier). • Add default of true for Generalization::isSubstitutable. • Note exclusion of Parameter::defaultValue, Parameter::default and Property::default. • Add default of “in” for Parameter::direction. See also the resolution to Issue 15987 “The fUML Foundational Model Library should support the new UML 2.4 Real primitive type”. For simplicity, all revisions related to the new Real type are handled in that resolution. Revised Text: Clause 3 Normative References Replace the content of the clause with: The following normative documents contain provisions that, through reference in this text, constitute provisions of this specification. The following OMG standards provided the source for the foundational subset. • UML 2.4.1 Infrastructure Specification (formal/11-08-05) • UML 2.4.1 Superstructure Specification (formal/11-08-06) • MOF 2.4.1 Core Specification (formal/11-08-07) • OCL 2.0 Specification (formal/06-05-01) XML Metadata Interchange (XMI) provides a syntactic interchange mechanism for models. It is expected that models conforming to this specification will be interchanged using XMI. • MOF 2.4.1 XMI Mapping Specification (formal/11-08-09)? Subclause 7.2 Classes In Subclause 7.2.2.1 Overview, after the existing bullet under “From Features (see Figure 7.9)”, add: • Parameter::defaultValue. Implicitly computing a default value for a behavioral feature (or behavior) would require coordination of multiple UML actions, since call actions always require explicit inputs or outputs to be provided. • Parameter::default. This is excluded because default values for parameters are not included in fUML. After the first bullet under “From Classes (see Figure 7.11)”, add: • Property::default. This is excluded because default values for properties are not included in fUML. In Figure 7.5 Namespaces, in the symbol for PackageableElement shown immediately, under NamedElement, add the attribute • + visibility : VisibilityKind = public {redefines visibility} In Figure 7.8 Classifiers, • In the specification for the attribute Generalization::isSubstitutable, add “ = true”. • In the annotations to the association end attribute, add “subsets redefinableFeature, subsets feature”. • Add the annotation “{subsets redefinitionContext, subsets featuringClassifier}” to the association end classifier opposite to attribute. • Add the annotation “{subsets memberNamespace}” to the association end classifier opposite to inheritedMember. • Add the annotation “{readOnly, union}” to the association end redefinedElement. In Figure 7.9 Features, • In the specification for the attribute Parameter::direction, add “ = in”. • In the annotation for the association end feature add the annotations “union, subsets member}”. • In the annotations for the association end featuringClassifier add “subsets memberNamespace”. In Figure 7.10 Operations, • Add the annotation “{subsets redefinedElement}” to the association end redefinedOperation. • Add the annotation “{subsets redefinableElement}” to the association end operation opposite redefinedOperation. • Replace the annotation “{subsets namespace}” on the association end operation opposite to ownedParameter with “{subsets ownerFormalParam}”. • Add the annotation “{readOnly} to the association end “type”. In Figure 7.11 Classes, • Remove the attribute isAbstract from class Class. • In class Property, add the attribute o + isId : Boolean = false • Add the annotation “{redefines general}” to the association end superclass. • Add the annotation “{subsets classifier}” to the association end class opposite to superclass. • In the annotation for the association end ownedOperation, add the annotation “subsets redefinableElement”. • In the annotation for the association end class opposite to ownedOperation, add the annotation “subsets redefinitionContext”. • In the annotation for the association end class opposite to ownedAttribute, remove the annotation “subsets featuringClassifier”. • In the annotation for the association end memberEnd, replace “subsets ownedMember” with “subsets member”. • Add the annotation “{subsets memberNamespace}” to the association end association opposite to memberEnd. • Add the annotation “{subsets owningAssociation}” to the association end association opposite to navigableOwnedEnd. In Figure 7.12 Data Types, • In the annotation for association end datatype opposite to ownedAttribute, remove “subsets featuringClassifier”. • Add a unidirectional association from EnumerationLiteral to Enumeration with association ends: o enumerationLiteral * {redefines instanceSpecificiation} o /classifier 1 {redefines classifier} In Figure 7.13 Packages, • In class Package, add the attribute o + URI : String [0..1] {id} • Replace the annotation “{subsets namespace}” for the association end package with “{subsets owningPackage}”. • Replace the annotation “{subsets namespace}” for the association end nestingPackage with “{subsets owningPackage}”. In Subclause 7.2.2.3 Class, under “Attributes”, • Remove “isAbstract : Boolean = false” In Subclause 7.2.2.10 EnumerationLiteral, under “Attributes” • Before the existing bullet, add a bullet for “classifier : Enumeration”. • Change “enumeration : Enumeration [0..1]” to “enumeration : Enumeration” In Subclause 7.2.2.12 Generalization, under “Attributes”, • At the end of the bullet for “isSubstitutable", add “ = true” In Subclause 7.2.2.2.25 Package, under “Attributes”, replace “None” with • URI : String [0..1] {id} In Subclause 7.2.2.2.26 PackageableElement, under “Attributes”, replace “None” with • visibility : VisibilityKind = public In Subclause 7.2.2.2.28 Parameter, under “Attributes”, • At the end of the bullet for “direction”, add “ = in”. In Subclause 7.2.2.2.30 Property, under “Attributes”, after the bullet for “isDerivedUnion”, add: • isId : Boolean = false Subclause 7.3 Common Behaviors In Subclause 7.3.1 Overview, remove “From Triggers (see Figure 7.17)” and the following bullet. In Figure 7.15 Common Behavior, • Add the annotation “{subsets namespace}” to the association end behavioredClassifier opposite to ownedBehavior. • Add the annotation “{redefines behavioredClassifier}” to the association end behavioredClassifier opposite to classifierBehavior. • Add the annotation “{readOnly}” to the association end context. • Add the annotation “{subsets namespace}” to the association end behavior opposite to ownedParameter. In Figure 7.16 Reception, • Add the annotation “{subsets memberNamespace, subsets featuringClassifier}” to the association end ownedReception. Subclause 7.4 Activities In Figure 7.23 Flows, • Add the annotation “{subsets owner}” to the association end activityEdge. In Figure 7.24 StructuredNodes, • Add a symbol for the class Activity. • Add an association from Activity to StructuredActivityNode with the ends o +activity 0..1 {redefines activity} o +structuredActivityNode * {readOnly, subsets node} • Add the annotation “{subsets owner}” to the two inStructuredNode association ends and the conditionalNode association end opposite to clause. • Add the annotation “{subsets ownedElement}” to the association ends node, edge and clause. • Add the annotation “{subsets action}” to the two structuredActivityNode association ends. • Add the annotation “{subsets structuredActivityNode}” to the conditionalNode association end opposite to result and the two loopNode association ends opposite to loopVariableInput and result. Subclause 7.5 Actions In Figure 7.28 Basic Pins, • Add the annotation “{subsets owner}” to the two action association ends. In Figure 7.29 Basic Invocation Actions, • Add the annotation “{subsets action}” to the end of every composition association whose opposite end is an InputPin or OutputPin. In Figure 7.30 Object Actions, • Add the annotation “{subsets action}” to the end of every composition association whose opposite end is an InputPin or OutputPin. • Add the annotation “{subsets ownedElement}” to the value association end. • Add the annotation “{subsets owner}” to the valueSpecificationAction association end opposite to value. In Figure 7.31 Structural Feature Actions, • Add the annotation “{subsets action}” to the end of every composition association whose opposite end is an InputPin or OutputPin. In Figure 7.32 Link Identification, • Add the annotation “{subsets action}” to the linkAction association end opposite to inputValue. • Add the annotation “{subsets ownedElement}” to the endData association end. • Add the annotation “{subsets owner}” to the linkAction association end opposite to endData. In Figure 7.33 Read Link Action, • Add the annotation “{subsets action}” to the readlinkAction association end. In Figure 7.34 Write Link Actions, • Add the annotation “{subsets action}” to the clearAssociationAction association end. • Add the annotation “{redefines linkAction}” to the createLinkAction and destroyLinkAction association ends. In Figure 7.35 Accept Event Actions, • Add the annotation “{subsets ownedElement}” to the trigger association end. • Add the annotation “{subsets owner}” to the acceptEventAction association end opposite to trigger. • Add the annotation “{subsets action}” to the acceptEventAction association end opposite to result. In Figure 7.36 Object Lifecycle Actions, • Add the annotation “{subsets action}” to the end of every composition association whose opposite end is an InputPin or OutputPin. Clause 9 Foundational Model Library In Figure 9.1, replace the package UML::AuxiliaryConstructs::PrimitiveTypes package with PrimitiveTypes. In Subclause 9.1, first paragraph, • In the first sentence, replace “…AuxiliaryConstructs::PrimitiveTypes package from the UML 2 metamodel (see sub clause 17.4 of the UML 2 Superstructure Specification).” with “…PrimitiveTypes package from the UML 2 infrastructure (see sub clause 13.1 of the UML 2.4.1 Infrastructure Specification).” • In the last sentence, replace “AuxiliaryConstructs::PrimitiveTypes” with “PrimitiveTypes”. fUML_Syntax.xmi In the normative XMI, change the names of the following associations: • IntermediateActivities::A_outgoing_source to A_outgoing_source_node • IntermediateActivities::A_incoming_target to A_incoming_target_node Actions taken: January 26, 2011: received issue January 7, 2013: closed issue Discussion: End of Annotations:===== ubject: fUML 1.1 should be based on UML 2.4 Date: Wed, 26 Jan 2011 11:58:03 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: fUML 1.1 should be based on UML 2.4 thread-index: Acu9ejIPQPv4JoPKR0aJQYj4k/clUA== From: "Ed Seidewitz" To: Specification: Semantics of a Foundational Subset for Executable UML Models, FTF Beta 3 (ptc/10-03-14) Foundational UML (fUML) 1.0 as finalized is based on UML 2.3. With the completion of the UML 2.4 RTF, fUML should be moved to UML 2.4. This would be consistent with the recently adopted Alf action language specification, which will be finalized based on UML 2.4. Fortunately, nothing seems to have changed in UML 2.4 that would substantively effect the specification of the fUML abstract syntax subset. However, the fUML normative XMI should be regenerated consistent with UML 2.4/XMI 2.4. Further, UML 2.4 has separated the primitive type model into a separate XMI file with normative XMI IDs, and these should be used for referencing those types in the normative XMI for the fUML Foundational Model Library.