The I-X Domain Editor, I-DE, now has facilities for building a simple object system and using this in the process models (refinements).
The object system has classes which have a name and can also have sub-classes and properties. Properties have a name and a syntax. Classes inherit properties from their super-classes.
To build the object system, use the Objects panel of the editor. When first using this panel, there will be a top-level object called Root. You can re-name this root class, but you cannot delete it. You can specify sub-classes and class properties. Classes can have more than one super-class (parent), but cycles should be avoided.
The syntax of properties is one of string, symbol, number, object, list, or default. For an explanation of those syntaxes, see the note on object classes. Currently, the syntax specifications are used only to guide I-X parsers, but in future I-DE may use the syntax specifications to check constraints in the models.
For domains that have activity specifications (refinements) but do not (yet) have an object model, I-DE has a facility to infer a simple object model based on relevant information in the activity specifications. This initial model can then be adapted by the modeller to produce a coherent object model.
Any simple pattern assignments in the conditions/effects of activity specifications are considered relevant and is therefore included in the automatically generated (corresponding) object model. A simple pattern assignment is of the form:
property ?variable = value
Simple pattern assignments that share variable names within an activity specification are assumed to refer to the same object and therefore used to infer information about the same object class.
Simple pattern assignments that use the keyword "type" or "class" as their property are interpreted as defining an object class. Other simple pattern assignments are used to provide property names of object classes. If no type constraints can be found for a variable that has other property constraints, an anonymous class is generated based on the variable name (the name may provide clues as to what the object class may be). This anonymous class is used to collect all properties referred to for that variable.
Once an object system is in place, it can be used to specify object constraints in an organised way. The variable declarations editor within I-DE's Activity panel is now an object constraint editor, as is the condition/effect editor.
This new editor has three components:Variable Declaration: an area for variable declarations. The variable declarations determine which variables can be used in the activity specification (none, any, or as given)
Variables Table: a table for variables and their classes
Properties Table: a table for constraints on properties of one variable. This is the main part of the editor where constraints on variables are specified.
In the second component, variables are listed that are currently used in the refinement. Each variable can have a class associated with it which makes the object referred to by the variable a member of the class. New variables can be added by typing into the empty row at the bottom of the variable table. Variable names and types can be edited in the table.
If a variable has a class, the class properties are available for specifying constraints on the variable's object. For this, the variable should be selected in the variables table. Any constraints on this variable will be shown in the properties table. New constraints can be specified using the empty row at the bottom of the table. Using the comboBox of the property cell, a property can be selected or a new one typed in. A new constraint is added, and a value for the constraint can be typed into the value cell. The Relation cell (condition/effect) can be used to specify which type of constraint is entered.
Note that for each variable, the editor will make sure that each property has at most one condition and one effect. Trying to add a second one will bring up a message asking you to deal with the problem.
The simple condition/effect editor is still used to edit previously specified conditions and effects, and it is available from the new editor (the long button at the bottom of the new editor); if you want to use the simple editor for specifying all your conditions and effects, change the preference "Use object constraint editor" via the Tools menu. The old variable declarations editor is no longer available.
The simple condition/effect editor notes each constraint into the activity specification as soon as it is defined. The new constraint editor does not do this. It will collect changes and add them to the activity specification when the editor's "Ok" button is clicked. To note edits in-between, a "Note Edits" button is provided.
Clicking the "Cancel" button, all constraints that have been specified since the last "Note Edits" will be discarded. Note, however, that any changes to the object system (i.e. new class properties that were added while editing constraints) will persist.
All specifications in the tables of the object constraint editor are translated into world-state conditions and effects.
Variable class specifications are translated into conditions of the form
(type ?var) = class-name
For example, (type ?v) = vehicle.
Property constraints are translated into conditions or effects of the form
(property ?var) = value
For example, (passenger-number ?v) = 3.