Section 29.2. CROSSCUTTING CONCERNS IN OBJECT-ORIENTED DATABASE SYSTEMS


29.2. CROSSCUTTING CONCERNS IN OBJECT-ORIENTED DATABASE SYSTEMS

The various concerns in an object-oriented database system are illustrated in Figure 29-1. Usually, an object database programmer or maintainer writes code in an object-oriented programming language for persistent objects and their class/type definitions in the same fashion as transient objects and classes/types. The exception to this style is that operations on persistent objects are encapsulated within transaction boundaries. The DBMS-level concerns are responsible for keeping the persistent and transient space consistent, both during database operation and its maintenance and evolution, in a fashion that is transparent to the application.

Figure 29-1. Concerns at the DBMS level and database level in an object-oriented database system.


The concerns in Figure 29-1 are divided into two levels, driven by the desire to separate data management concerns from the data itself. Some concerns such as distribution and security have been omitted for simplification:

  • DBMS-level concerns: Pertaining to software components for managing data and meta-data (e.g., the schema) stored in the database. These concerns differ from concerns in other domains as they operate on both transient and persistent elements.

  • Database-level concerns: The data and meta-data (e.g., the schema) residing in the database. These concerns differ from crosscutting concerns in other domains because they are spread across persistent entities (objects, classes, metaclasses, etc.) and, hence, are persistent in nature. This persistent nature is their distinguishing characteristic and needs to be taken into account by techniques used to modularize them. They also require an appropriate representation at the meta-level within the database to enforce necessary typing constraints.

Figure 29-1 also illustrates the intertwined nature of concerns at the two levels. The crosscutting relationship between the concerns tends to be multi-dimensional in nature. For instance, the evolution model cuts across the instance adaptation approach, the transaction model, and the version management policy. At the same time, the instance adaptation approach crosscuts the evolution model, the version management policy, and the locking scheme. Furthermore, at times, there is a dependency between the two levels (shown by the dashed lines in Figure 29-1) with a crosscutting concern at one level influencing its counterparts at the other level.

29.2.1. Crosscutting Concerns at the DBMS Level

Evolution of object databases imposes its own set of crosscutting concerns. The evolution problems are amplified by the close integration of object databases with object-oriented programming languages and the existence of complex user-defined data types. Changes to a class definition can invalidate not only its own objects but also definitions of its subclasses, their instances, and application behavior bound to the older class definition. Let us consider two examples of crosscutting evolution concerns at the DBMS level in detail: instance adaptation during object database evolution and the evolution model itself.

29.2.1.1 Instance Adaptation Approach

Instance adaptation is the process of simulated or physical object conversion across compatible class definitions on schema evolution. Instance adaptation is a crosscutting concern at both the DBMS level and the database level. It is essential to distinguish the instance adaptation approach from an instance adaptation routine. The former exists at the DBMS level. It is the code that bears a close relationship with the schema evolution model and defines the instance adaptation strategy for the system. The latter exists at the database level. It is the code specific to a particular class or its historical representation (depending on whether the evolution model supports change histories) and defines adaptation semantics for instances of the particular class definition. It can be an error handler [33], an update or backdate method [19], or a transformation function [20]. In other words, the instance adaptation approach identifies the type of routines to be used for instance adaptation and, on detection of interface mismatch between the accessed object and the class definition, invokes the appropriate routine with the correct set of parameters.

Figure 29-2 shows the various elements in an object-oriented database system over which the instance adaptation approach needs to quantify (i.e., interface mismatch messages from the objects) and those with which it is tightly integrated (i.e., the evolution model, the version management approach, and the instance adaptation routines). This illustrates the crosscutting nature of the instance adaptation approach and how parts of it, for example, the detection of interface mismatches, are scattered across other concerns.

Figure 29-2. Sequence of operations leading to instance adaptation in an object-oriented database.


An instance adaptation approach simulating object conversion might be suitable for one system, while one that physically converts objects might be more appropriate for another [32]. At times, a hybrid approach might be desirable. However, the closely knit relationship with the evolution model and the instance adaptation routines (refer to Figure 29-2) results in a "fixed" instance adaptation approach whose customization or replacement by a new approach to suit local needs is expensive because

  • Such a change can have a large ripple effect on the evolution model, as it is tangled with the instance adaptation approach.

  • At the database level, corresponding instance adaptation routines exist within each class definition or each historical representation of a class (see Section 29.2.2.1). Consequently, customization of the instance adaptation approach at the DBMS level can trigger the need for changes to all or a large number of classes or their historical representations.

29.2.1.2 Evolution Model

The second example of a crosscutting concern at the DBMS level is the evolution model. An object-oriented database system can employ one of several different evolution models:

  • Schema modification [3, 10], where the database has one logical schema to which all changes are applied. No historical representations of class definitions are kept.

  • Schema versioning [14, 21], which allows several versions of one logical schema to be created and manipulated independently. Change histories are maintained at a coarse granularity.

  • Class versioning [19, 33], which keeps different versions of each type and binds instances to a specific version of the type. Change histories are maintained at a fine granularity.

  • Other models such as context versioning [2], which are based on versioning partial, subjective views of the schema, or on superimposing one model on another (e.g., [24]).

Similarly to the requirements for instance adaptation, organizations can have highly specialized needs for evolution models. For one organization, it might be inefficient to keep track of change histories, hence making schema modification ideal. For another, maintenance of change histories and their granularity might be critical. The requirements can be specialized to the extent that custom variations of existing approaches might be needed. As shown in Figures 29-1 and 29-2, the schema evolution model is intertwined with other concerns, for instance, the instance adaptation approach and the version management mechanism. This makes such customizations virtually impossible. Even if the evolution model were decoupled from the instance adaptation approach and other overlapping concerns, most database system regard the schema evolution model and the schema implementation model as being mutually integral. Consequently, there is no clear distinction between the two. Customization of the evolution model can invalidate the whole schema and, in fact, the whole database.

29.2.2. Crosscutting Concerns at the Database Level

Analysis of two crosscutting concerns at the database level, instance adaptation routines and links among persistent entities, illustrates how lack of modularization can adversely affect the customizability, maintainability, and extensibility of a database system.

29.2.2.1 Instance Adaptation Routines

Consider the instance adaptation routines in an object database evolution system that employs a class versioning model for evolution and a simulation-based instance adaptation approach. This is the approach taken by the ENCORE system [33]. As illustrated in Figure 29-3, all the versions of a class are members of a version set. When the addition of an attribute or method generates a new class version, error handlers are introduced into all the previous class versions in the version set. These error handlers are triggered when an interface mismatch is detected between an object instantiated using an older class version (e.g., Person_V1) but accessed using a newer definition (e.g., Person_V3). The handlers simulate a conversion by returning a default value. Now consider the scenario where the behavior of the address handler in Figure 29-3 (c) needs to be modified. Since the handlers are introduced into the class versions directly, such a change impacts both Person_V1 and Person_V2.

Figure 29-3. Crosscutting instance adaptation routines at the database level: (a) Initial class version; (b, c) Derivation of new class versions due to additive changes.


The example in Figure 29-3 presents a very simple scenario that does not take inheritance of handlers from versions of superclasses into account. The situation is complicated by the fact that a large number of hierarchically related class versions can come into existence over the lifetime of the database. Let us assume that the instance adaptation approach at the DBMS level can be customized, for example, to use update/backdate methods [19] that physically convert the objects to bring them in line with schema changes. Such transitions produce a large ripple effect on the version sets of all classes as the handlers are removed and update/backdate methods introduced.

29.2.2.2 Links Among Persistent Entities

Another example of crosscutting concerns at the database level is that of links among persistent entities. Examples of such links are association and aggregation relationships among objects, version derivation links among object or class versions, inheritance relationships among classes (or their versions), and scoping relationships between classes and their members. Traditionally, information about links is embedded within the entities themselves. For example, following the database evolution theme, consider the meta-class that defines the structure and behavior of class objects in an object-oriented database. As shown in Figure 29-4 (a), the inheritance links are implemented as collections of references to superclass and subclass objects. Figure 29-4 (b) shows a simplified schema evolution scenario from a case study of a database central to the functioning of an adult education organization [23]. Prior to evolution, the class Person has two subclasses: Tutor and Principal. The subclasses collection in the Person class object contains references to the two subclass objects, while the superclasses collections in the subclass objects include references to the Person class object. When a new non-leaf class Staff is introduced, we must

  • Remove all the references to subclass objects from the Person class object.

  • Update all subclass objects to remove the reference to the Person class in their respective collections of superclass references.

  • Add a reference to the Person class object to the superclasses collection in the Staff class object.

  • Add references to older subclasses of Person to the subclasses collection in the Staff class object.

  • Add a reference to Staff to the subclasses collection (not shown in Figure 29-4 (b)) in Person and to the superclasses collection in each of its former subclasses.

Figure 29-4. (a) Traditional structure of a meta-class in an object database. (b) Modification of inheritance links in a schema evolution scenario.


The number of entities affected on modification of a connection is m + n, where m and n represent the number of participating entities at each edge of the relationship (in this case, superclasses edge and subclasses edge). Consequently, introduction of new links or removal of existing links among entities (in the schema or otherwise) is expensive. Similarly, extensions to the set of metaclasses to include new types of entities in the system can also have a huge impact on existing data and meta-data, as metaclasses are often also linked using the same mechanism.



Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net