Goals and scope

Design: open architecture

Galicia has been designed as an open platform
and its implementation in Java insures a high portability of the entire system.

Architecture overview

A particular attention has been paid to the architectural design of the platform in order to achieve the desirable features of adaptability, extensibility and reusability. The architecture of Galicia is a traditional layered architecture, with a lower most level composed by the Java environment and the upper one dedicated to interaction with the users of the platform.

Two intermediate levels have been identified, the kernel of the platform and the tool layer (see Figure 1). The kernel is in charge of all low-level services related to the representation and manipulation of contexts and ordered structures. These services are exported toward the tool layer where the implementation of high-level FCA methods are located.

The architecture of the second highest layer of Galicia follows the partition of the platform's functions into phases of the lattice life-cycle whereby the most important ones are data processing, partial order construction and partial order visualization. Thus, three main components make up this layer (see Figure 2):

Main tools

  • Structure extractor: responsible for the construction and/or maintenance of lattices and related posets from a context. A set of alternative methods are implemented. These are further organized into subcomponents with respect to the exact kind of structure manipulation they are aimed at. Thus, the Constructor subcomponent provide services of pure construction from data, either batch or incremental. In contrast, methods for assembly and decomposition of lattices are located in Assembler/Slicer. Finally, the Updater is responsible for maintaining incrementally the lattice when attribute, object or (object, attribute) pair is added or deleted to the corresponding context.
  • Lattice viewer: provides all the necessary facilities for the visualization and browsing of partial orders. Two modes for lattice representation are available : 2D and 3D. For complex lattices, a nested line diagram engine (still in progress) enables gradual exploration through navigation of such lattices
  • Contexts designer: offers the necessary environment for interactive creation of several kinds of contexts and for relational context families.
  • Import/Export engine: insures the input/output flow of data and results for the entire platform.
Figure 1: Architectural layers of the Galicia platform and dependencies between components.

Data exchange

Thanks to the specific design of Galicia's architecture, the tools
of the layer two achieve a high degree of integration. On the one hand, they rely on the same low-level services provided by the kernel which simplifies the communication and data exchange among tools. On the other hand, they are addressed via an integrated GUI which eases their joint utilization.

Detailed design

The modular architecture of Galicia facilitates modifications, both in the set of available algorithmic methods, i.e., in the tool layer, and in the specific data structures used in the kernel.

First, the high level of genericity within the platform results from the strict use of abstract data types for the various structures related to the FCA domain: concept intents, concepts, lattices, etc. For each of them, a collection of primitives is specified and assigned to a particular abstract class or interface (as in Java). This reduces the dependency of client tools on the particular implementation of the data structure. Moreover, alternative implementations may be used whenever particular feature of the resulting services have to be favored (e.g., efficiency, low memory consumption, etc.). For example, the concept lattice data type is represented as an abstract class whose services include concept retrieval, add/remove of concepts, etc.

 A similar approach has been applied to the design of the structure extracting services. Instead of representing alternative algorithms as software methods of the same class, these have been reified in the design model of the platform. Thus, each algorithm is represented by a class, classes being further factorized into super-classes with respect of the task that is to be achieved: construction, update, assembly, etc.

For example, the algorithm described in [15], is modeled by a class which inherits from the class of all incremental algorithms that is itself a subclass of the class of all lattice construction algorithms. In this context, a particular execution of an algorithm requested by a user creates an object in the class of the algorithm and stores in it any relevant data.

Such a design allows new algorithmic procedures to be integrated into the respective tool easily. Indeed, any new algorithm inherits the available related information from its most specific category while benefiting from the whole range of services offered by the lower layers of the platform.

Figure 2: The architecture of the tool layer in Galicia.