Download
1 / 7
70 likes | 71 Views
This article discusses the inconsistencies in UML2 Package Merge and proposes recognizing it as an operation instead of a relationship. It explores the concept of merging packages and the need for distinguishing pre- and post-application of PackageMerge. The article also argues for acknowledging PackageMerge as a transformation function in alignment with MDA.
E N D
UML2 Package Merge A Logically Inconsistent Construct Unless Recognized as an Operation not a Relationship Karl Frank Oct 4, 2003
Package merge is presented by Bran, Jim, and Ken as a function ranging over ordered pairs of packages, with a domain of packages. They do not use the term “function” but they describe PackageMerge in those terms, as does the language of the Final Adopted Spec: “This is a mechanism that should be used when …” More from the spec in support of this view are in the notes to this page
To review the terminology: • Merging Package, also called the Source • (the tail of the dashed arrow in the illegitimate “relationship” presentation) • Merged Package, also called the Target • (the head of dashed arrow) These are actually names for formal parameters in a meta-Operation: packageMerge(source: package, target: package): package
primitiveTypes <<import>> <<import>> basic constructs Post-merge-constructs <<merge>> Application of the operation creates a new package, distinct from both the merged and merging Source Merging Package (this is the package that is updated by the merge) Target Merged Package The blue arrow is to represent object flow from the application of a function, it is not a dependency relationship. Our argument is that the dependency relationship <<merge>> is bogus. As the IBM team argues, The PackageMerge results In a change, such that the Constructs package, after The update, is not the same As before the update.
So long as one views PackageMerge as a relationship, not an operation, UML 2 is inconsistent • Two packages in a model (at whatever level) either have or do not have a certain relationship. • For any package and model element in a model, the package either does or does not contain that model element • What is the extent of a “merging” package? No one answer until we distinguish Pre- or Post- application of the PackageMerge • If we view PackageMerge as a relationship, then • The merging package both does, and does not, contain the classifiers by which PackageMerge extends the merging package. • The resolution is to speak, as the IBM team and the spec do, of “before” and “after” applying the PackageMerge, which is to play verbal tricks to avoid confronting the contradiction directly.
As the IBM teams argues, one root of the problem is: • Redefinitions • They also are really functions that transform a model, masquerading as relationships within a model.
The proposed resolution is to admit that: • UML 2 Infrastructure has added a new concept • Functions that transform models into different models. • In particular, a PackageMerge function that maps an ordered pair of packages into a new package to extend, that is to say, to modify the model. • Functions to transform one model into another (extended) model, are used in the definition of UML 2’s 38 compliance points • Such functions are the “mechanisms” by which the kernel packages of the metamodel are extended to create the complete metamodel. • They are a problem so long as we try to handle them as relationships • By acknowledging PackageMerge for what it is, we will allign UML 2 with MDA: • Functions that transform models into different models are, in the MDA Guide, called 'transformations.'
