Whether you do this, and to what degree, depends upon the intended users of your KB. For instance, you might develop a set of KBs for use only by other G2 developers; whereas, another G2 developer might develop a set of KBs that are intended to work together as a complete application. The features that another G2 developer requires (such as editing procedures, changing the definitions of classes, and so on) are probably inappropriate to deliver to users of most applications.
However, your application will also benefit from your taking a more disciplined, engineering-oriented approach to your application development project. For instance, developing a robust class hierarchy, with the associated data servers, methods, rules, and configurations that support the application's objects, can consume a significant portion of a project's time and effort.
Thus, while designing your application's user interface, you must determine how to use workspaces to display the KB's knowledge to the application's users. For instance, your KB might be designed to contain static workspaces: workspaces of fixed sizes and with more or less fixed relationships to each other. The application uses these workspaces as the areas within with to display the KB's knowledge and within which to allow user interaction.
Alternatively, you could design your KB to create and display workspaces and their contents dynamically. That is, the stored KB that you deliver as the application might not include any static, user-visible workspaces at all. Rather, at run-time the application creates the workspaces that the user must see based only on run-time conditions.
One approach is to create objects that display their primary knowledge graphically and directly. For many kinds of applications, you can create objects with which the user interacts directly, without the need for selecting commands from menus.
For example, assume that you have developed a class of objects that can be the target of three operations:
move this object, create a copy of this object, and delete this object. You can use G2 actions and configurations to accomplish this, without requiring the use of a menu-based interface. That is, you can configure the objects to respond to these user actions:
Move this object operation: When the user clicks the mouse pointer over an object, attach that object to the mouse pointer. Drop the object upon the workspace where the user next clicks the mouse.
Create a copy of this object operation: When the user clicks the mouse pointer over an object while also holding down the Shift key, create a copy of that object and attach it to the mouse pointer. Drop the new object upon the workspace where the user next clicks the mouse. The workspace (or workspace location) where the user drops the object can also signify a particular operation.
Delete this object operation: When the user clicks the mouse pointer over an object while also holding down the Control key, delete that object.
Variables can have either internal or external data servers. External data service is a more complex task for your KB to perform than internal data service. For this reason, determining the minimum number of variables that must use an external data server is also a key design decision.
For more information about variables, see Chapter 15, Variables and Parameters.
Using Internal Data Servers
G2's internal data servers are the G2 inference engine and the G2 Simulator. If a variable's data server is the inference engine, G2 allows the variable to receive a new value via conclude actions (including those that result from chaining among rules) and from specific formula objects. If a variable receives data service from the simulator, G2 associates the variable with a simulation formula, which provides its value.
Using External Data Servers
G2's external data servers are other G2 processes, G2 Gateway bridge applications, and GFI files. If a variable receives external data service, your KB cannot dynamically change its data service. However, your KB can conclude the value of an internally data-served variable from another variable that is externally data-served.
Using Timekeeping Features
Keeping time is central to how G2 performs its tasks. As shown in the figure Computational Features of G2, G2 has awareness of three streams of time: real-time, scheduled time, and simulated time.
Querying the Real Time
After G2 starts and as long as it runs, G2 has awareness of the real time. G2 has this awareness by querying your computer's own clock. G2 uses the capabilities of your computer's operating system to perform these queries. G2 has as precise a grasp of the real time as your computer and its operating system provide. Scheduling G2's Work
G2 schedules its own work, and the work it performs when running the current KB, using a second time stream. You can adjust the granularity of this time stream in the Minimum-scheduling-interval attribute of your KB's Timing Parameters system table. Its granularity determines how often G2 checks whether there is more work for it to do.
You can also adjust the rate at which this second time stream elapses. The
Scheduler-mode attribute of the Timing Parameters system table contains this setting. Specifically, this determines whether G2 waits for the entire minimum scheduling interval to elapse, before moving on to its set of tasks that are scheduled for the next interval. Use this feature to cause G2 to run your KB unconstrained by the granularity of the minimum scheduling interval. For a KB whose processing does not depend, or depends only minimally, upon the occurrence of events upon which G2 must wait an entire minimum scheduling interval, setting the KB to run in the
as fast as possible scheduler mode allows G2 to move from minimum scheduling interval to interval (and thereby increment the G2 clock) as fast as G2 can perform its scheduled work without waiting for real-time based events. For more information about the G2 scheduler and the G2 clock, see Chapter 46, Task Scheduling.
Establishing Simulated Time
G2 can also maintain a distinct time stream for each simulation model object defined in the KB. Your KB can establish a distinct current time for each simulation model, to allow the G2 Simulator to represent the occurrence of events independently of the real time. You use G2 system procedures to set and manipulate the time streams of simulation models. Default-simulation-time-increment attribute of the Simulation Parameters system table. The rate at which G2 allows this time stream to elapse is determined by the Scheduler-mode attribute of the Timing Parameters system table.
Establishing Naming Conventions
As for applications coded in other programming languages, you must assign names and identifiers to many entities in your KB, and you should establish conventions for how you derive and assign those names. Considering Natural Language Support
As you use G2 to implement an application, you can configure G2's developer's environment to display G2's default menu choices and to display the default text of buttons in the Text Editor and other G2 facilities, using a particular natural language.
You can also use ASCII characters to signify any character in any natural language that G2 supports. This scheme for signifying non-English characters is defined as the Gensym character set, which is described in Chapter 40, G2 Character Support. Use the Gensym character set to specify text outside of G2 that must be input to G2, and to translate text containing non-English characters that G2 outputs for use by other applications.
Also, Telewindows users can connect to G2 and can operate its current KB such that each displayed Telewindow displays its menu text and G2's system-defined text in a distinct G2-supported natural language. This feature is described in Chapter 8, G2-Windows, and in Chapter 50, Telewindows Support.