| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (5 out of 9)

Creating a Module Hierarchy

Typically, for large applications, you will want to create a module hierarchy to organize your KB.

In general, a module hierarchy consists of one top-level module and multiple directly required modules below the top-level module, where each submodule can also directly require one or more modules.

For information on when one module must directly require another module, see The Module Hierarchy.

The general steps for creating a module hierarchy are:

  1. Create a top-level module.

  2. Create one or more additional modules.

  3. Declare the directly required modules for each module in the KB.

  4. Check for consistent modularization.

  5. Save the modularized KB into separate KB files.

The following headings outline these steps in detail.

Creating a Top-Level Module

The first step for creating a module hierarchy is to name the top-level module. This is described in Naming the Top-Level Module.

Naming the top-level module creates a single top-level module for the KB. The next step is to create additional modules in the current KB.

Creating a New Module

To create a module hierarchy, you must create additional modules in the current KB. Once you have created these modules, you can declared them to be directly required by the top-level module, as well as by other modules in the hierarchy.

Creating a New Module

You can create a new module interactively or programmatically.

To create a new module interactively:

  1. Select Main Menu > Miscellany > Create New Module.

G2 displays the Module Information system table for the new module:


  1. Enter the name of the new module in the Top-level-module attribute of the new Module Information system table.

Creating a New Module Programmatically

G2 includes a system procedure for creating a module programmatically.

To create a new module programmatically:

where module-name is the name of the module in your current KB that you wish to create programmatically.

The module-name cannot:

On successful execution, g2-create-module creates a set of system tables for the new module. The top-level-module attribute of the Module Information system table is module-name. All other attributes have default values.

The next procedure creates a new module based on the symbolic name passed as its argument, and assigns the kb-workspace to the new module:


System Tables Associated with a New Module

When you create a new module interactively or programmatically, G2 creates set of associated system tables for the new module. However, these system tables are not installed in the current KB; only the system tables of the top-level module are in effect for the current KB.

To display the system tables for all loaded modules:

Assuming that you just created a new module named classes in an otherwise empty current KB, Inspect displays a workspace like this:


Declaring Directly Required Modules

For each module that requires other modules, you must assign the name of the required module to the Directly-required-modules attribute in its associated Module Information system table. A module can directly require one or more other modules.

For example, suppose your current KB contains a top-level module named top, and suppose you create a new module named classes, which you want to be below the module top in the hierarchy.

To declare a directly required module of another module interactively:

  1. Open the Module Information system table for the module that requires another module, in this example, the top module.

  2. Enter the name of the directly required module in the Directly-required-modules attribute, in this example, classes:


To declare a directly required module of one or more modules programmatically:

Use this technique to create a module hierarchy with module branches, as shown in the figure in The Module Hierarchy.

Checking for Consistent Modularization

If the current KB contains one or more modules, those modules must conform to G2's rules for consistent modularization, as follows:

When G2 detects that the modules in the current KB violate any of the rules for consistent modularization, G2 signals an error and adds information to the Notes attributes of the nonconforming modules, nonconforming top-level workspaces, and so on, as shown in the previous figure.

Tip: As you develop the current KB's module hierarchy, you should regularly check the Notes attributes of your items.

G2 validates the consistency of modules in the current KB only. G2 does not compare the knowledge in the currently loaded modules with the knowledge stored in KB files that are not loaded. This means that if you load a KB file and another developer happens to save a change to the same KB file, G2 cannot detect whether that change affects its consistency with other modules until they are next loaded.

G2 does not evaluate the consistency and completeness of all references within the KB that cross module boundaries. For instance, G2 does not validate the existence of procedures and functions that are referenced but not contained in the same module. These and other execution linkage references play no role in how G2 validates the consistency of a module hierarchy.

Validating Consistent Modularization

G2 checks that the current KB is consistently modularized when you attempt to save the KB or any module in the KB. As you work with your current KB, you can also use an Inspect command, check for consistent modularization, to check for consistent modularization.

When you issue the check for consistent modularization command, Inspect displays an Inspect workspace and places on it any messages that describe why the current KB is not consistently modularized.

The following figure shows an Inspect workspace with two messages, produced after executing the check for consistent modularization command:


In this figure, the messages from Inspect report that the current KB contains at least one top-level KB workspace whose Module-assignment attribute has the value unspecified, and that at least one module exists in the KB that is not required by any other module.

To respond to these messages:

Saving the Module Hierarchy

 When saving a modularized KB, G2 saves each module in its own KB file. You can choose to save individual modules or all modules in the hierarchy, either interactively or programmatically.

To save an entire module hierarchy into separate KB files:

  1. Choose:

  2. Choose:

  3. In the save KB workspace, include the including all required modules statement in the Save module ... as command.

    For a description of the default module name and filename that G2 provides, as well as requirements for specifying the KB filename, see Specifying the Filename of a Saved Module.

    G2 displays a list of all the modules it will save with a confirmation message.

  4. Click OK to save the modules.

To save an individual module in a module hierarchy:

  1. Select Main Menu > Save KB.

  2. Edit the name of the module in the Save module ... as command that appears to specify the name of the module to save.

  3. Edit the associated filename to correspond to the module name you are saving.

To save a module hierarchy programmatically:

You can programmatically save a module, even while the current KB is running.

If any directly or indirectly required module was not loaded from an existing KB file, then when you specify the ,including all required modules phrase in the Save module ... as command, G2 creates new KB files with names based on the combination of:

Note: The module map file, if it exists, also determines how G2 saves modules into corresponding modularized KB files. See Using a Module Map File to Load and Save a KB for more information.

Specifying the Filename of a Saved Module

When saving a module that is directly required by other modules, you should save it to a filename that is the same as the module name. This allows G2 to find the directly required module's associated KB file by using G2's default search techniques.

If you choose to store the module in a KB file with a different name, then in order for G2 to locate that module's KB file when loading or merging it later as a directly required module, you must also create a module map file. The module map file associates a module name with either a directory path or a KB file path. See Using a Module Map File to Load and Save a KB.

When saving a module, G2 offers defaults as follows:

Saving an Inconsistently Modularized KB

 If the current KB is inconsistently modularized, you cannot save any of its modules into separate KB files. Instead, when you attempt to save the current KB, G2 displays a warning message, such as the following, and only permits you to save the entire KB into a single KB file.


By default, G2 stores this KB file in a file whose name begins with the ALL- prefix and ends with the name of the current KB's top-level module.

Deleting a Module

Deleting a module means removing the module, all its associated system tables, and all its associated items from the current KB. Recall that items are associated with a module based on the module assignment of the workspace on which the items reside. Deleting a module does not mean deleting the KB file in which a particular module is stored.

To delete a module from the current KB interactively:

  1. Choose:

  2. From the choose a module to delete menu, select a module to delete.

    G2 displays this dialog:


  3. In response to this dialog:

    1. Click the OK button to delete only the selected module and its associated set of system tables.

    2. Click the All button to delete the selected module, its associated set of system tables, and all KB workspaces assigned to that module.

Note: If you attempt to delete a module that is required by the KB, G2 displays an appropriate warning on the confirmation dialog.

To delete a module from the current KB programmatically:

Note: If you delete the top-level module from the current KB, G2 replaces all installed system tables with new system tables and initializes their attributes to system-defined default values.

Determining Programmatically Whether a Module is Loaded

You can use an if rule or an if statement in a procedure to determine whether a particular module exists in the current KB. This procedure accepts a module name as its argument to check whether it is the top-level-module:


| Prev | Next | Start of Chapter | End of Chapter | Contents | Glossary | Index | Comments | (5 out of 9)

Copyright © 1997 Gensym Corporation, Inc.