8.7 Package Composition

   This sub clause summarizes the meta-model composition mechanisms supported by the MOF Model and discusses their impact on M1-level semantics.

   Package nesting is the simplest of the MOF’s Package composition mechanisms. At the M2-level, Package nesting is expressed by making the outer Package the “container? of the nested Package. The definition of the Contains association in the MOF Model means that Package nesting is a strict composition relationship.

   The main intended function of Package nesting is information hiding. Placing a Class or DataType in an inner Package rather than an outer one notionally makes it less visible to other meta-models. When the MOF visibility rules are defined (in a future revision of this specification), this information hiding will be more strongly enforced.

   Nesting of Packages also affects the M1-level interfaces and implementations. The meaning of any element of a metamodel is potentially dependent on its context in a variety of ways. Thus, when the element is defined in a nested Package, its meaning may depend on the outer Package; for example, on Constraints or Classifiers declared therein. This means that anything that uses a nested element will also implicitly depend on the context. To avoid potential M1-level anomalies caused by this kind of dependency, the MOF Model does not allow a meta-model to import a nested Package or a Classifier defined within a nested Package.

   The M1-level semantics of Package nesting are as follows. The behavior of an M1-level instance of a Classifier declared in a nested Package depends on state in both its immediate Package, and its enclosing Packages. As a result, the M1-level instance of the nested Classifier is inextricably tied to other instances within the outermost enclosing Package extent; see 8.8.4, “Package Extents,? on page 147 .

   Package generalization allows an M2-level Package to reuse all of the definitions of another M2-level Package. Package generalization is expressed at the M2-level by connecting the super-Package and sub-Package using a Generalizes link. (The MOF Model’s Constraints mean that Generalization is effectively an aggregation in the UML sense.)

   The M1-level semantics of Package generalization are as follows. The behavior of M1-level instances of the elements of an M2-level Package typically depends on M1-level behavior for M2-level super-Package elements. Indeed, an M1-level Package “instance? is substitutable for M1-level Package instances for M2-level super-Packages.

   Package inheritance does not create any relationship between an instance of the super-Package and an instance of the sub- Package. Therefore an M1-level Package extent is not related to M1-level super- or sub-Package extents; see 8.8.4, “Package Extents,? on page 147 .

   Package importing allows an M2-level Package to selectively reuse definitions from other M2-level Packages. Package importation is expressed at the M2-level by placing an Import in the importing Package that is related to the imported Package by an Aliases link. In this case, the M2-level Import object has its “isClustered? attribute set to false. Since Package importation can be cyclic, it is neither an aggregation or a composition in the UML sense.

   NOTE: The MOF Model’s Constraints make it illegal for a Package to import itself, or for any Package to import a nested Package. Furthermore, while the MOF Model allows Package importation to be cyclic, the preconditions for the MOF Model to IDL mapping disallow most dependency cycles, including those between Packages that result from cyclic importation.

   The M1-level semantics of Package importation are minimal. No substitutability or state relationships exist between the M1-level instances of an importing or imported Package, or between their respective extents. Indeed, an importing Package will typically not even share implementation code with the imported Package.

   Package clustering allows an M2-level Package to selectively reuse definitions from other M2-level Packages, and also share M1-level implementation infrastructure. The M2-level expression of Package clustering is similar to that for Package importation; see above. The difference is that the Import object has “isClustered? set to true.

   The M1-level semantics of Package clustering are similar to those of Package nesting because a cluster Package instance has its clustered Package instances as its components. However, unlike nested Packages, it is still possible to have a freestanding M1-level instance of such a Package whose extent is unrelated to any extent of a cluster Package.