21.7. A CONCERN-MODEL EXAMPLEThis section provides an example of concern modeling based on the GPS cache, a general-purpose (software) cache that is intended to be reusable in a variety of applications [19]. The GPS cache is richly functioned and featured. It supports the usual functionality associated with a cache, and it has some less common features such object dependencies, logging, and statistics collection. It is also highly configurable, both statically and dynamically. The GPS cache has been used in web publishing [24] (including IBM web sites for major sports events) and in support of business rule evaluation [9]. We have been interested in the GPS cache as the potential prototype for a "component family," a collection of specialized caches with various, more or less overlapping combinations of features, functions, behaviors, and properties. Our approach to developing this family of caches was based on aspect-oriented ideas and tools. In particular, we wanted to allow a cache to be specified in terms of a particular set of desired concerns and then to enable a cache that addressed those concerns to be composed from reusable, concern-specific fragments of Java code. To achieve this, we used Cosmos for concern modeling and Hyper/J [16] for composition of Java units. This work is described at more length in [34]. Here, we consider our initial modeling of concerns for the GPS cache, primarily as it was programmed, but also including some obvious generalizations. This modeling served two purposes. First, it established a baseline for the concerns that a cache may address and provided a core around which we could organize conceptions and models of what a cache is and how it may be subject to variation [34]. Second, this modeling allowed us to see which concerns were addressed in which parts of the cache code. This provided a basis for decomposing the code into more specialized units that were suitable for recomposition into alternative variants. Examples of high-level concerns in the implementation of the GPS cache are outlined in Table 21-2, "Selected Concerns from the GPS Cache." (For discussion of relationships and predicates, see [36].)
According to the Cosmos model, concerns are organized as logical or physical, with logical concerns here including concern classes, instances, properties, and topics, and physical concerns including instances, collections, and properties. The top-level concern classes we distinguished included implementation object classes, functionality, behavior, state, properties, and Java units. Implementation-object classes are concerns in and of themselves and are also used to organize subclasses under other concern classes (such as functionality, behavior, and state). Under functionality, nine different functional areas are associated with the Cache class, grouping from one to eight methods (omitted for brevity). Methods in the "printing" group are also included under other groups as they print information relative to those groups. For the CachedObject class, existing methods fall into three groups, and additional groups (not initially used) can be identified by generalization from the Cache class; these can be populated later. Behaviors are grouped into those specific to operations, those aspectual to operations, and those not associated with operations. Behaviors in these groups may be related; for example, the behavior of specific operations to turn statistics logging on or off has an effect on the logging of collected statistics, a behavior that is not associated with any particular operation. A number of themes occur repeatedly under various kinds of concerns, such as "core," "logging," and others. Such crosscutting concerns represent other dimensions by which the concern space can be organized. For instance, object classes could occur under "core" and under "logging" instead of vice-versa. Topics are one way to represent such crosscutting concerns. In principle, there are many ways that a model of concerns in the cache might be organized and presented. Cosmos supports the modeling of multi-dimensional concern spaces, and concerns in the cache can indeed be described multi-dimensionally. That is, many elements in the cache can be assigned to concerns in multiple classifications, and any of several classifications might be distinguished as the basis of a view of the concern space. We continued our work on the cache product family by decomposing the cache implementation into small units focused on specific concerns. We then elaborated the concern model to include concerns of interest that were not addressed in the original cache, programming implementations for these. Using Hyper/J [16], and transforming the Cosmos concern-space model into the Hyper/J representations for a hyperspace specification and concern mapping, we composed about alternative versions of the cache. In these we added, deleted, and replaced methods; added, deleted, and replaced fields; changed the behaviors of methods; changed the methods to which particular behaviors were associated; changed aspects associated to methods; introduced and removed features; affected properties such as performance, size, and robustness; and substituted implementation structures. Using the same units, many additional cache variants could be composed to address additional combinations of concerns. |