Issue 6279: PackageMerge (from Kernel) (uml2-superstructure-ftf) Source: Capability Measurement (Mr. Karl Frank, karl.karolus(at)gmail.com) Nature: Uncategorized Issue Severity: Summary: A package merge defines how one package extends another package by merging their contents. Description A package merge is a relationship between two packages, where the contents of the target package (the one pointed at) is merged with the contents of the source package through specialization and redefinition, where applicable. This is a mechanism that should be used when elements of the same name are intended to represent the same concept, regardless of the package in which they are defined. A merging package will take elements of the same kind with the same name from one or more packages and merge them together into a single element using generalization and redefinitions. It should be noted that a package merge can be viewed as a short-hand way of explicitly defining those generalizations and redefinitions. The merged packages are still available, and the elements in those packages can be separately qualified." The text implies that PackageMerge is an operation on an ordered pair of two packages (respectively the target package and the source package) to produce a third package, whose contents differs from the contents of the source package, differs from the contents of the target package, and differs from the union of the source and target (taking "union" in the set-theoretic sense, where the elements owned by a package are regarded as a set. This operation known as PackageMerge is performed when it is desired to produce new elements (with generalization relationships and redefinitions that did not exist "prior to" performing this operation) in a new package, which (to repeat myself) is distinct from either of the two packages one had to start with . This implication comes thru use of the English verb "to merge" , used to explain PackageMerge, and the characterization of PackageMerge as "a mechanism", and from the statement in the Associations subsection that "mergingPackage references the Package that is being extended…". After being extended, a package is not what it was prior to being extended. Further, it comes from the statement, in the Semantics subsection, that "A classifier from the target (merged) package is transformed into a classifier with the same name in the source (merging) package, unless the source package already contains a classifier of the same kind with the same name." Note in the sentence just quoted, the condition "unless the source package already [emphasis added] contains a classifier of the same kind with the same name. By saying this, the spec implies there is a distinction to be drawn between what th source package contains before the PackageMerge operation is performed, and what it contains afterwards . A reductio ad absurdum argument can be posed, as follows: Suppose for the sake of argument that a given package S, which plays the role of source (merged) package in a PackageMerge relationship, owns a classifier named E1 of kind K1, but does not own a Classifier named E2 of kind K2. Suppose further that another package T (for Target), not the same as S, does have a Classifier named E2 of kind K2, but none named E1 of kind K1. If S has a PackageMerge relationship with T, and PackageMerge is not an operation creating a third package distinct from S and from T, then S both does, and does not, have a Classifier named E3 of kind K2. Therefore, PackageMerge is either an inconsistent relationship between S and T, or it is an operation on S and T which produces a third package, X, distinct from S and T. Suggested resolution: rewrite the PackageMerge section to explicitly present it as an operation producing a new package distinct from both target and source. Resolution: see above Revised Text: Actions taken: September 29, 2003: received issue March 8, 2005: closed issue Discussion: The rules of package merge need to be clarified and made consistent across the MOF, Infrastructure, and Superstructure. Due to various implementation-related and similar concerns identified with the “define” form of package merge used to define the UML 2 metamodel (see issues 6186, 6188, 6189, 6190, 6191, 6194, 6198, 6246, 6253, 6471, 6517, 6642) the FTF decided to only support a single form of package merge: the “extend” form defined in the MOF specification. This not only reduces gratuitous complexity but also solves a number of implementation issues (particularly those related to mapping the merge notions to standard OO languages). Last but not least, if used in the right way, the “extend” type of package provides a very convenient solution to the definition of compliance levels (6187, 6196, 6197, 6248) such that tools that implement a higher level of compliance can easily import XMI of modeles defined at a lower level of compliance, without having to do any special conversion. However, even the “extend” version of package merge defined in the MOF spec needs to be upgraded and clarified, so that the handling of all possible merge situations is fully defined. The following resolution was worked out after long discussions among the FTF members and has been programmatically verified. The resolution proposes fixes to all three related specs: the MOF 2.0 spec, the UML Infrastructure spec, and the UML 2.0 Superstructure spec. The main definition of package merge is the same in all cases, but needs to be inserted in different parts of each document. In addition, there are several additional fixes that are specific to each document. The shared definition of package merge is captured in the attached PDF file in the form of a metaclass definition that needs to be inserted in the proper place in the Super and Infra documents in place of the current definitions. C:\mydata\ documents\external\Standards\OMG\UML2.0\FTF\Issues\PackageMergeModels\PackageMergeDefinition.040804.pdf Updates required to the Superstructre spec: 1. Replace the diagram in Figure 43 on page 99 with the following diagram that includes the following changes from the original: ?? The changed name for Package::ownedType (resolved by issue 6918) ?? Renaming of PackageMerge::mergingPackage to PackageMerge:receivingPackage (for clarity to match the text in the spec) PackageableElement Namespace DirectedRelationship PackageableElement PackageMerge Type Package 0..1 * +owningPackage {subsets namespace} +ownedMember {redefines ownedMember} 1 * +receivingPackage {subsets source, subsets owner} +packageMerge {subsets ownedElement} 1 +mergedPackage {subsets target} * 0..1 +nestedPackage {subsets ownedMember} +nestingPackage {subsets namespace} * 0..1 +/ownedType {subsets ownedMember} +package {subsets namespace} 2. Replace the entire PackageMerge description (section 7.3.12 of the Superstructure FAS) with the text in the embedded PDF file above. Updates required to the Infrastructure spec: 1. Replace the diagram in Figure 94 on page 152 with the following diagram that includes the following changes from the original: ?? Removal of the generalization from Package to Basic::Package, since this is no longer required due to the new rules for package merge defined in this resolution ?? Renaming of PackageMerge::mergingPackage to PackageMerge:receivingPackage (for clarity to match the text in the spec) Namespace PackageableElement PackageMerge Type Package * 0..1 ownedMember {redefines ownedMember} owningPackage {subsets namespace} * 0..1 nestedPackage {subsets ownedMember} nestingPackage {subsets namespace} * 1 packageMerge {subsets ownedElement} +receivingPackage {subsets source, subsets owner} 1 mergedPackage {subsets target} * 0..1 /ownedType {subsets ownedMember} package {subsets namespace} 2. Replace the entire PackageMerge description (section 11.8.3 of the Infrastructure FAS) with the text in the embedded PDF file above. Updates required for the MOF 2.0 spec: 1. Completely remove sections 14.1 and 14.2 that describe different kinds of merges, since the MOF will reuse the definition of merge that it gets from the infrastructure. 2. Replace all uses of the keyword <<combine>> by the keyword <<merge>> in figures 1, 6, and 14 and also in the text. 3. In section 8 on page 11, first paragraph, 2nd last sentence, remove “combine,” 4. In section 8.2 on page 11, remove the entire second paragraph that talks about the difference of package merges. 5. In the remaining paragraph of section 8.2, replace all references to the “merging” package by corresponding references to the “receiving” package. End of Annotations:===== ubject: UML2 super / kernel / PackageMerge Date: Mon, 29 Sep 2003 21:41:21 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-topic: UML2 super / kernel / PackageMerge Thread-index: AcOG8+kYQJVy8G8yTYuNPw+pJK7sLQ== From: "Karl Frank" To: X-OriginalArrivalTime: 30 Sep 2003 01:41:22.0045 (UTC) FILETIME=[F3B5AAD0:01C386F3] Closely related to an issue raised earlier by me as UML2 super/fig 141 p205 and 7.13.2 p101 / just what sort of relationship is <>? See attached word doc, or if it is easier to deal with the email, the text of the doc is pasted in below Karl Frank Borland Software Corporation cell: 978 853 3592 landline: 978 283 4656 15 Haskell Street Gloucester MA 01930 --------------------------- "PackageMerge (from Kernel) A package merge defines how one package extends another package by merging their contents. Description A package merge is a relationship between two packages, where the contents of the target package (the one pointed at) is merged with the contents of the source package through specialization and redefinition, where applicable. This is a mechanism that should be used when elements of the same name are intended to represent the same concept, regardless of the package in which they are defined. A merging package will take elements of the same kind with the same name from one or more packages and merge them together into a single element using generalization and redefinitions. It should be noted that a package merge can be viewed as a short-hand way of explicitly defining those generalizations and redefinitions. The merged packages are still available, and the elements in those packages can be separately qualified." The text implies that PackageMerge is an operation on an ordered pair of two packages (respectively the target package and the source package) to produce a third package, whose contents differs from the contents of the source package, differs from the contents of the target package, and differs from the union of the source and target (taking "union" in the set-theoretic sense, where the elements owned by a package are regarded as a set. This operation known as PackageMerge is performed when it is desired to produce new elements (with generalization relationships and redefinitions that did not exist "prior to" performing this operation) in a new package, which (to repeat myself) is distinct from either of the two packages one had to start with . This implication comes thru use of the English verb "to merge" , used to explain PackageMerge, and the characterization of PackageMerge as "a mechanism", and from the statement in the Associations subsection that "mergingPackage references the Package that is being extended…". After being extended, a package is not what it was prior to being extended. Further, it comes from the statement, in the Semantics subsection, that "A classifier from the target (merged) package is transformed into a classifier with the same name in the source (merging) package, unless the source package already contains a classifier of the same kind with the same name." Note in the sentence just quoted, the condition "unless the source package already [emphasis added] contains a classifier of the same kind with the same name. By saying this, the spec implies there is a distinction to be drawn between what th source package contains before the PackageMerge operation is performed, and what it contains afterwards . A reductio ad absurdum argument can be posed, as follows: Suppose for the sake of argument that a given package S, which plays the role of source (merged) package in a PackageMerge relationship, owns a classifier named E1 of kind K1, but does not own a Classifier named E2 of kind K2. Suppose further that another package T (for Target), not the same as S, does have a Classifier named E2 of kind K2, but none named E1 of kind K1. If S has a PackageMerge relationship with T, and PackageMerge is not an operation creating a third package distinct from S and from T, then S both does, and does not, have a Classifier named E3 of kind K2. Therefore, PackageMerge is either an inconsistent relationship between S and T, or it is an operation on S and T which produces a third package, X, distinct from S and T. Suggested resolution: rewrite the PackageMerge section to explicitly present it as an operation producing a new package distinct from both target and source. PackageMerge.doc