This site contains older material on Eiffel. For the main Eiffel page, see http://www.eiffel.com.

Subclusters in Lace

Eiffel Power (TM) from ISE

ISE Eiffel 4 includes a new mechanism to define a nested architecture for a system's clusters.

The facility described is not just a technical addition to the ISE Eiffel environment; it addresses important issues of object-oriented system structuring, for which the Eiffel approach provides a flexible and scalable answer, especially important for large developments.

Overview

For a non-trivial system divided into coherent groups of classes, or "clusters", it is often useful to define a logical architecture for the clusters, independent of the physical location of clusters in the file system. In particular, a cluster may consist of subclusters.

This makes clusters a very general notion: a cluster can be a library, such as the EiffelVision and WEL graphical libraries of ISE Eiffel, each of which consists of many subclusters (WEL, the Windows Eiffel Library, itself being in fact a subset of EiffelVision, the cross-platform graphical library). But a cluster can also be just a subsystem, or a group of logically related classes.

The new subclustering mechanism of ISE Eiffel 4 provides the expressive power needed to describe such architectures.

Terminology and references

The overall structure of a program (better called a system) in ISE Eiffel is described by a file called an Ace (for Assembly of Classes in Eiffel), written in a simple Eiffel-like syntax known as Lace (Language for the Assembly of Classes in Eiffel).

A system is made of a number of "clusters", each consisting of a set of classes. In the absence of subclusters, all the classes of a cluster are stored in files of a certain directory associated with the cluster. By default these "class files" are the files with a .e extension in the cluster directory.

The Ace serves to specify the list of clusters making up the system and the name of the "root" class which will start execution. It is also used to indicate compilation options, names of external (e.g. C or C++) files to be linked, and other system properties.

Besides their technical role for storing the class files of a system, clusters are also a project management tool, and a system architecturing tool (starting at the level of analysis and design) as developed in particular in the BON method of O-O analysis and design.

References:

    Eiffel: The Language (Prentice Hall): appendix D describes Lace and its use. The extension discussed in the present note adds subclustering to this basic framework.

    Object Success (Prentice Hall), discusses project management issues and the role of clusters in the object-oriented software lifecycle, introducing the "cluster model" of the lifecycle.

    Seamless Object-Oriented Software Architecture by Kim Waldén and Jean-Marc Nerson (Prentice Hall) describes the BON analysis and design method and notation, which relies on clusters and subclusters.

Subclusters in Lace

Each cluster in ISE Eiffel is stored in a directory. The files with a .e extension in that directory are by default, as noted, the ones containing the cluster's classes.

Starting with ISE Eiffel 4 it is possible to define a notion of subcluster, supporting a nested structure for clusters, independent of the hierarchical structure of directories.

The advantages are:

    Ability to organize clusters as desired, and separate their physical location from their logical relations.

    Supporting BON's notion of subcluster, consistent with what is done in EiffelCase, ISE's object-oriented analysis, design and reverse-engineering workbench.

    Making it much easier to move clusters around in the directory structure: with good design, the Ace will have to be changed only slightly or not at all.

    Simplifying the writing of the Ace in the first place.

The new conventions

The Lace extensions are very simple:

    In a cluster specification (cluster clause), a cluster can appear not just as

      cluster_name

    (the only possible syntax in earlier versions, with cluster_name being the identifier denoting the cluster), but also as

      cluster_name (parent_cluster_name)

    where parent_cluster_name is the name of another cluster. This defines the new cluster as a subcluster of parent_cluster_name.

    To specify the directory of a cluster, appearing after a colon as in cluster_directory in the syntax

      cluster_name: cluster_directory

    the previously available possibilities include: using an absolute path, as in a\b\c; and using environment variables, as in $EIFFEL4\library\base\structures. It is now also possible to use the symbol $, denoting the directory of the parent cluster, if one has been specified. So the entry

      cluster_name (parent_cluster_name): "$\subdir"

    indicates that the directory for cluster_name is the subdirectory subdir of the directory for parent_cluster_name. Then if you move the parent directory the child will automatically follow. (The use of \ is Windows-specific; on Unix use /.)

An example

The following example Ace illustrates the new possibilities. It uses the Windows convention (backslash \) for paths.

      system
              app

      root 
              APPLICATION (root_cluster): "make"

      default
              assertion (all);

      cluster 

              root_cluster: ".";

              -- EiffelBase
              base:                      "$EIFFEL4\library\base\";

              kernel (base):             "$\kernel";
              support (base):            "$\support";

              structures (base):         "$\structures";

              access (structures):       "$\access";
              cursors (structures):      "$\cursors";
              cursor_trees (structures): "$\cursor_tree";
              dispenser (structures):    "$\dispenser";
              iteration (structures):    "$\iteration";
              list (structures):         "$\list";
              set (structures):          "$\set";
              sort (structures):         "$\sort";
              storage (structures):      "$\storage";
              table (structures):        "$\table";
              traversing (structures):   "$\traversing";
              tree (structures):         "$\tree";

      end -- system app

Without subclusters the same Ace would be significantly more complicated, and harder to adapt to changes.

Methodology note

It is considered good practice to put class files in leaf subclusters only. In other words a cluster should:

Either contain classes, in .e class files, but no subclusters.

Or contain subclusters (by default in subdirectories of the cluster directory, although you may prefer a different structure) but no classes of its own.