Understanding Modules
A module identifies a set of items that represents a component of a larger KB.
You can work with modules in a flexible manner, as follows:
- Start by building an application without modules.
- Create modules and associate the items in the KB with those modules
- Save the KB into separate KB files, with one module per file.
For details about how to do this, see Creating, Populating, and Saving a Module.
For example, suppose you are developing two G2 applications. Assume that each application displays a schematic workspace that represents the behavior of a set of connected pumps.
You might begin to build these applications by populating an empty KB as shown at left. You might then organize the knowledge that pertains only to pumps into different modules: one module for class definitions, one module for pump instances, and one module for rules, procedures, and methods pertaining to pumps.
You can create a module and associate it with a set of items, regardless of whether the KB is reset, running, or paused.
Once you have modularized your KB and saved these modules into separate KB files, you can load individual modules, and merge other modules into the current KB. For information about loading and merging KBs, see Working with Modularized KBs.
For large applications, you typically create a module hierarchy by defining modules that directly require other modules. This is explained next.
The Module Hierarchy
To create a module hierarchy, you must have a top-level module, which is the root of the module hierarchy. To form the hierarchy, you define modules in the hierarchy to directly require one or more other modules.
Defining a module to directly require another module means that G2 automatically loads the directly required module before loading the module that depends on it. In this manner, you can load an entire application by loading a single top-level module.
The following diagram illustrates the relationships among the modules in a module hierarchy:
A module that directly requires another module can function independently from its directly required modules. However, you must define a module to directly require another module when:
In the figure above, for example, Mod-0 might contain items that are instances of classes defined in definitions assigned to Mod-1. In this case, you must define Mod-0 to directly require Mod-1.
A KB that includes a module hierarchy is called a modularized KB. When saving a modularized KB, you save the modules into separate files. If a KB is not consistently modularized according to the criteria outlined in Checking for Consistent Modularization, it is considered unmodularized. G2 saves unmodularized KB modules into a single KB file.
For more information about how to create and save a module hierarchy, see Creating a Module Hierarchy.
Modules and System Tables
Each module that you create or load has its own set of system tables. You define each module in the Module Information system table, including its name and its directly required modules.
When you load a KB, G2 installs the system tables associated with the module contained in the KB that you load. After loading is complete, the module defined in that KB becomes the top-level module of the current KB, and the system tables associated with that module are in effect for all modules in the current KB.
If you create a new module, G2 automatically creates a new set of system tables and associates them with the new module. If you delete a module from the current KB, G2 automatically deletes its associated system tables. When you save a module, G2 also saves its associated system tables in the KB file.
Modules and Items
You associate items in a KB with a module by assigning that module to one or more top-level workspaces in the KB. This causes that workspace, all items upon that workspace, and all items below them in the workspace hierarchy to be associated with that module.
For information on assigning items to a module, see Associating Items With a Module.
Copyright © 1997 Gensym Corporation, Inc.
