Development and Deployment
G2 provides an incremental development environment. As development progresses, you can add capabilities to your KB at virtually any stage of the development cycle. Techniques and guidelines for G2 application development appear in the G2 Developer's Guide. For a detailed overview of the G2 development environment, see Chapter 2, The Developer's Environment.
To enable dynamic behavior, G2 lets you change the attributes of objects and relationships between objects while the KB is running.
G2 supports subsecond time. You can specify a subsecond time interval that affects the G2 clock and thus the scheduler, certain intervals, and history collection specifications. To allow subsecond timing, G2 represents time as a float, rather than an integer. For information about scheduling and time, see Chapter 46, Task Scheduling.
Modules
You can develop a large KB from smaller, more manageable pieces called modules. Each module contains a set of related items that together comprise a KB.
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.
Modules facilitate modular development and reusability. When several developers are working on a single application, each can work on a separate module These can later be combined to form the entire application. Class definitions and other knowledge can be saved in a single module and used across multiple applications.
Using modules you can:
For a complete description of using modules, see Chapter 5, Modules and Modularized KBs.
Compiler Optimization
Compilation occurs automatically within G2 each time you complete editing any compiled attribute, which includes all expressions, actions, and functions.
By default, all compiled attributes within a KB are optimized. Internal optimization code can routinely rearrange statements and eliminate redundant statements to improve computational efficiency.
Stable for Dependent Compilations
You can use configuration statements to declare certain items as stable-for-dependent-compilation. Declaring items this way informs G2 that certain parts of the item's knowledge will not change, letting G2 compile dependent items more efficiently. In large KBs, the more items you can declare as stable, the more performance will improve.
Profiling a KB
As KB development nears completion, you can use the KB profiling facility to collect and analyze data about its performance during execution. After you identify which parts of your KB can benefit from further optimization, you can apply compilation configurations to help G2 to compile those parts more efficiently.
A complete description of G2 compilation and profiling appears in Chapter 43, Profiling and KB Performance.
System Procedures
System procedures are a group of G2-provided procedures, contained in the sys-mod.kb file. G2 includes over 200 system procedures.
You use system procedures by merging in the sys-mod.kb file into your current KB, and then calling system procedures as needed from user-defined procedures and methods.
System procedures let you complete a variety of different tasks, and, in some cases, provide a programmatic access to items that is unavailable through expressions or actions.
Using system procedures, you can:
G2 system procedures are described in the G2 System Procedures Reference Manual, included as part of your G2 documentation set.
Copyright © 1997 Gensym Corporation, Inc.
