Section 3.4. INSTANTIATION

3.4. INSTANTIATION

To use this artifact model, one must instantiate it for particular artifact development formalisms. Instantiation entails determining which notational constructs map to units and modules, deciding how to represent hyperslices, and providing support for composition of hyperslices. The mapping to units is especially important, as it significantly affects how well the hypermodules will achieve various software engineering goals and properties. This section briefly describes some of the issues involved. A fuller discussion appears in [18].

3.4.1. Mapping to Units and Modules

Units: Choosing "units" from the set of artifact formalism constructs requires an instantiator to decide the level of granularity at which it is appropriate, in the given formalism, to separate and integrate concepts. We illustrate this by example, using the Java language. Java defines both declarator constructs (e.g., packages, interfaces, classes, methods) and statements. Some subset of these constructs must be treated as units. A decision in favor of fine granularity might include all declarators and statements as units. This potentially provides the flexibility to compose any pieces of Java source, but it has all of the concomitant problems of determining how to match and reconcile different statements and of trying to analyze the properties of the result. Using a coarser level of granularity might result in treating only a subset of declarators (e.g., classes and their members) as units, which simplifies composition and understanding of the composed result, at the cost of generality.

The selection of units has significant ramifications for some important software engineering properties of artifacts [18], including effects on evolution and modular development. If the set of units includes entities that are typically "hidden," such as method implementation code, composition rules and their results become sensitive to "hidden" changes. Modular development relies on important properties of individual modules being preserved by composition. If composition can occur at too fine-grained a level, such properties might not be preserved, and must be re-examined afresh in the context of each composition.

Data and functionality are fundamental and ubiquitous concepts in software. They are frequently the concepts that are described by artifacts, and the concepts that span hyperslices and artifacts. Formalisms generally have constructs for declaring or defining them. For example, UML has boxes representing classes, and entries within class boxes representing instance variable and method declarations. Java has classes, interfaces, instance variable declarations and methods. We believe that constructs related to data and functionality are excellent candidates for units, and hypothesize that they might, in general, be the best choices.

Modules: The selection of formalism constructs to map to modules is somewhat simpler than the choice of units. Essentially, it requires examining the particular modularization constructs the formalism provides in light of the set of units chosen. For example, suppose we choose Java methods, instance variable declarations, classes, and interfaces as units. Instance variable declarations and methods are grouped together into classes and interfaces, which in turn are grouped together into packages. We would therefore choose to map Java classes, interfaces, and packages to modules in our model. An obvious choice for UML is to map classes and package diagrams to modules.

3.4.2. Representation of Hyperslices

Hyperslices are sets of modules. They need not occur explicitly in any given artifact formalisms, though some formalisms may provide a construct to which it is convenient to map hyperslices. For example, C++'s namespace construct, which represents arbitrary collections of program units, Java's package construct, which represents collections of classes and interfaces, and UML's package diagram, which represents collections of packages and classes, may be used to model hyperslices. For formalisms that do not have such constructs, it is necessary either to enhance them or to provide a separate hyperslice-specification mechanism, such as named lists of modules.

3.4.3. Support for Composition

To provide support for composing hyperslices, it is necessary to define a means for specifying composition rulesa language, an interactive tool, or bothand to build a compositor that is able to apply the rules to hyperslices. Composition by hand is conceptually possible, but totally unrealistic for actual development.

Providing this support is a large job. That is a powerful reason to make mapping decisions based on formalism, not on content, to avoid the need for project-specific compositors. Compositors specialized to understand particular semantic dimensions may be useful in some circumstances, however, as demonstrated by recent work on aspect-oriented programming [10].