Configuring ConMan Loaders

ConMan is the component in the CME that manages the concern model. (The concern model, of course, is the central structure in the CME, the focus of visualization, querying, analysis, composition, and so on.) ConMan loaders are tools that load a concern model into ConMan. A concern model may represent various things: the Eclipse workspace and projects, artifacts of various types (such as Java classes or Ant files), a concern-modeling schema, specific concerns of interest, and so on.

The loading capabilities in the initial CME release were partly fixed and partly extensible. A more recent release makes the loading capabilities more extensible. These differences are reflected mainly in the architecture and operation of the user interface. This document describes generally how loading works and how it may be configured in the two versions of the user interface. It begins with some background information.

Background: Loaders, the Concern Space, and Loading

Technically, a loader is a Java class that implements the Loader interface (org.eclipse.cme.conman.Loader). The Loader interface is very simple, including just two methods. The main method is load(...), which takes an element description and a concern-model element and is interpreted as a request to load a representation of the described element into the given element. The element descriptions are strings and are otherwise unrestricted in form or content. Internally the behavior of a loader may be more or less complex. For instance, a loader may search the workspace to find a described element, parse the element in detail, create an elaborate representation for it in the concern model, and invoke further loaders to load related elements; or the loader may just create a simple unit in the concern model and be done; or it may do anything inbetween (or beyond).

Loaders can be invoked directly by clients of the CME. However, this is not the default mode of loader invocation in the CME. Rather, loaders are added to the concern space (the root of the concern model), and clients make load requests of the concern space. The concern space (org.eclipse.cme.conman.ConcernSpace) provides an interface analogous to that of Loader, and load requests of a concern space are delegated to its contained loaders.

It is also possible to build (or update) a concern model without using a loader, by directly accessing the concern space and the various types of concern model elements it contains (these types are defined in org.eclipse.cme.conman). This is how loaders build up a concen model.

In the CME UI, the concern model is built when the "Refresh View" button in the Concern Explorer view is pressed. Just how the concern model is built when this button is pressed depends on the particular version of the UI.

Loading in the Original User Interface

In the original user interface (UI), the UI directly loads the parts of the concern model that represent the workspace and its projects (but not their contents). Depending on the particular version of the UI, it may also load some distinguished predefined concerns. The original UI also creates project-specific instances of a predefined type of Java loader and adds these to the concern space. (These loaders load Java packages, classes, and members.) The original UI makes use of one extension point, artifactloaders, that allows for the addition of loaders for particular types of artifacts that may be found in the workspace. The UI traverses the directory structure under each project and attempts to load the various artifacts (files) that it finds there. All of these behaviors are hardcoded into the UI.

The original UI operates according to the following major phases:

The top levels of the concern model are constructed (including representations of the workspace, projects, and any predefined concerns)
Loaders that extend the artifactloaders extension point are retrieved and added to the concern space
Java loaders of a particular type are instantiated for each project and added to the concern space
The directory structure of each project is traversed and a request is made of the concern space to load each artifact found (those artifacts for which the concern space has loaders should actually be loaded)
User concerns (that is, concerns created by users through the UI in a previous session) are restored from their serialized form
Relationships among Java elements and associated concerns are inferred
Intensional concerns (that is, those concerns defined by a query) are reevaluated

In this way the original UI addresses several fundamental considerations for concern modeling in the CME: the original UI provides a basic representation of the workspace, it provides for the loading of an important artifact type (Java classes) and the computation of relationships significant for these artifacts; it allows for the addition of loaders for other types of artifacts; it handles the restoration (and serialization) of user-defined concerns; and it addresses the recomputation of intensional (query-defined) concerns.

However, the configurability of the original UI is limited in several important respects:

The representation of the top-levels of the workspace is hardcoded, so there is no way to vary how the workspace is loaded or represented
There are no loaders for any specific substructure in the workspace; that must be handled through "artifact" loaders
Consequently, artifact loaders must be based on appropriate and compatible assumptions about what that substructure may be (for example, that the place in a concern model into which a loader expects to load an element actually exists)
There is no way to substitute an alternative loader for Java artifacts
There is no way to add further "top-level" loaders, that is, loaders that will load elements other than the workspace, such as a concern-modeling schema or a specific concern model

Any of these sorts of changes require some degree of reimplementation of the original UI.

Loading in the Redesigned User Interface

To overcome limitations on loader configurability in the original CME UI, the UI has been redesigned. The principle changes are as follows:

The functionality that directly built parts of the concern model (for the workspace, projects, and special concerns) has been extracted. To keep this specific functionality available, it has been encapsulated in a loader (one that is now optional)
A new extension point automaticallyinvokedloaders has been added to the CME for use by the UI. This is intended to support the addition of loaders that are invoked whenever the concern model is built or rebuilt (that is, whenever a user presses the "Refresh View" button in the Concern Explorer)
A new type has been defined in the ConMan package, LoaderDriver (org.eclipse.cme.conman.LoaderDriver). It is actually LoaderDrivers that extend the automaticallyinvokedloaders extension point and invoke loaders

LoaderDrivers facilitate the decoupling of loading functionality from the UI. By definition of the Loader interface and semantics, loaders do not themselves encapsulate any knowledge about what to load and where in the concern model to load it. In the original UI, this information was provided by the UI. To decouple loading from the original UI, this information had to be removed from the UI, but it could not be added to the loaders. The LoaderDrivers provide a place to encapsulate this information; they have a generically invokable interface but can invoke a selected loader with specific information about what and where to load.

The redesigned UI operates as follows:

Loaders that extend the artifactloaders extension point are retrieved and added to the concern space
LoaderDrivers that extend the automaticallyinvokedloaders extension are retrieved and invoked; in turn, each loader driver invokes the loader (or loaders) that it drives, providing each loader with the appropriate parameters to indicate what should be loaded and where in the concern model it should be loaded
User concerns (that is, concerns created by users through the UI in a previous session) are restored from their serialized form
Intensional concerns (that is, those concerns defined by a query) are reevaluated

This redesign greatly enhances the configurability of the CME UI with respect to loaders. No loading behavior is built into the UI; any loading behavior can be added to it. So, with the redesigned UI, it is possible, for instance, to use alternative workspace loaders, to load artifacts from outside of the workspace, to load a concern-modeling schema, and to load specific concern models.

In addition to extensibility there are other important differences between the redesigned UI and the original UI. One is that the original UI traversed the workspace and attempted to load any artifacts found there, whereas the redesigned UI does not do this. This means that loaders added to the concern space through the artifactloaders extension point will not necessarily be invoked. Rather, they will be invoked only if some other loader (or other client of ConMan) requests the concern space to load an element to which the artifact loader applies. Another difference between the redesigned UI and the original UI is that the redesigned UI does not have a distinct phase of loading relationships. The loading of any relationships must be addressed within some other loader or through a separate loader that is driven in the same way as any other loader. There is no predefined order in which loader drivers are invoked in the redesigned UI, and there is no way through the UI to control the order of loader-driver invocation. Thus, there should be no order dependencies among the loaders that are invoked by different drivers. If it is important that two loaders be invoked in a particular order, then they should be invoked in the desired order from a single loader driver. Note that a particular loader may serve both as an artifact loader and as an automatically invoked loader (although there may be little point to exploiting this feature in a single configuration).

Last modified on 10 September 2005 (sms)