Determining Which Type of Processing to Use
The first step in determining which type of processing to use is choosing between rule-based and procedural processing. Rule-based processing and procedural processing have a number of similarities as well as some important differences.
Choosing Between Rules and Procedures
The basic factors in determining whether to use rule-based or procedural processing involve how the processing is initiated and how the actions execute. Follow these general guidelines:
Similarities Between Rules and Procedures
Rules and procedures support these similar syntactic constructs:
|
Rules
|
Methods and Procedures
|
|---|
Branching, using if rules
|
Branching, using if-then or case procedure statements
|
Event detection, using whenever rules or if rules
|
Event detection, using the wait until procedure statement
|
Generic references to object classes, using for prefix or by referring to object classes generically within a statement
|
Generic references to object classes, using for each ... do procedure statement
|
Iteration, using for prefix
|
Iteration, using for each ... do procedure statement and repeat statement
|
Local name declarations within statements
|
Local name assignments before procedure body
|
Method and procedure invocations, using start action
|
Method and procedure invocations, using call statement or start action
|
Allows periodic processing, using scanning
|
Allows periodic processing, using the repeat statement for polling
|
Differences Between Rules and Procedures
The ways in which rules and procedures execute, as well as the types of constructs they support, have subtle differences, which this table summarizes:
|
Rules
|
Methods and Procedures
|
|---|
Support only if-then control structures
|
Support all common control structures such as if-then-else, looping, repeating, branching, and recursion
|
Does not support arguments or return values
|
Supports arguments and return values
|
Actions execute simultaneously, by default; use in order for sequential processing
|
Actions and statements execute sequentially, by default; use do in parallel for simultaneous processing
|
Invocations are scheduled based on rule priorities or regular scan interval
|
Invocations can be immediate or scheduled, depending on whether you use the call statement or the start action, respectively
|
Invoked based on various types of events or forward chaining when a variable receives a value
|
Invoked explicitly by using a call statement from within another method or procedure, or by using the start action from within a rule, method, or procedure
|
Referencing a variable does a single implicit collect data statement
|
Referencing a variable requires a collect data statement each time you reference a variable, which guarantees that variable reference are executed synchronously
|
Creates a new process for each rule that is triggered, which implements multi-threaded processing
|
Creates a new process each time a procedure is explicitly invoked, using the start action
|
Syntactic Differences Between Rules and Procedures
In many ways, the syntax for rules and procedures is similar because each uses actions to process data. However, rules and procedures have significantly different structures, which result in a number of important syntactic differences at the statement level, which this table summarizes:
Emphasizing Procedural Processing
While most applications require some rules, you should only use them where appropriate in an application. Specifically, follow this guideline:
For maximum efficiency, maintainability, and testability of your code, emphasize procedural processing over rule-based processing; use rules primarily as event detectors.
Your application should use procedural processing for several important reasons:
- Maintainability - Methods and procedures are easier to test, trace, and maintain because the thread of execution is sequential and predictable. Rules are more difficult to trace because the threads of execution can occur at any time and in any order.
- Encapsulation - Procedural processing, in particular, methods, support encapsulation and object-oriented design principles much better than rules. Using methods, you encapsulate object behaviors with its class, and you initiate processing by explicitly invoking the method. With rules, behaviors are not directly associated with an object, and you initiate processing by waiting for the rule to detect an event.
- Efficiency - In general, statements within methods and procedures execute independently of the G2 scheduler and only when you explicitly invoke the method or procedure. Rules, on the other hand, execute solely based on the G2 scheduler and without explicit invocation. Thus, methods and procedures can be more efficient than rules.
- Validation - Because methods and procedures execute sequentially, you do not generally need to validate the state of the application before each new thread of execution occurs, unless the procedure introduces a wait state. Because each rule creates a new process, it is sometimes necessary to validate the system before the rule performs the actions in its consequent, depending on the outcome of the event. For example, if a triggering event invokes rule A and rule B, and rule B deletes an object for which rule A concludes a value, G2 generates an error unless rule A explicitly tests whether the object exists before concluding a value.
For detailed information about using methods and procedures, see Using Procedural Processing.
Copyright © 1997 Gensym Corporation, Inc.
