The I-X Domain Editor, I-DE, now has facilities for building a simple
object system and using this in the process models (refinements).


I-DE Object Models
-------------------

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, default}. Currently, the syntax specifications are only used
guide I-X parsers, but in future I-DE may use the syntax
specifications to check constraints in the models.


Inferring Object 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. 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.  

The 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 (for clues as to what the object class may
be). This anonymous class is used to collect all properties referred
to for that variable.


Using Object Models in Activity Models (Refinements)
----------------------------------------------------

Once an object system is in place, it can be used to specify object
constraints in an organised way. The variables 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: 

1. 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) 

2. Variables Table: a table for variables and their classes 

3. Properties Table: a table for constraints on properties of one
   variable.

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.


Previous Editors
----------------

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.


Noting Specifications
---------------------

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) = className, 
	 e.g. (type ?v) = Vehicle. 
Property constraints are translated into conditions or effects of the form 
	 (property ?var) = value, 
	 e.g. (passengerNumber ?v) = 3.


Main Benefits
-------------

consistency in constraint specifications (property names), 

number of conditions and effects is controlled to make sense

object-oriented view of conditions and effects is more intuitive.

Some support for making changes in variable names take effect


Known Problems (to be sorted as soon as possible)
-------------------------------------------------

- If there are conflicting definitions of a property in different
  parents of a class, things may go wrong.

- there is no simple facility for finding and removing orphan classes.

- when a variable name is edited, what should happen to references to
  the old name in pattern/node/issue specifications of the activity?
  (currently they keep the old name)

- when a variable type changes, what should happen to constraints on
  properties that are not in the new class? (currently they are kept
  but do not appear in the object constraints editor)

- when property specifications change in a class (name change,
  removing properties), this is not reflected in the activity
  constraints. How should the editor deal with this? (currently,
  constraints referring to the old property are kept but will not
  appear in the constraints editor; the Object panel does not support
  changing property names).

- when a refinement changes while the object constraint editor is
  open, changes made in the editor are lost.

- when adding children to an object class, empty rows may appear in
  the object tree. Use the "Refresh" menu item to get rid of them.


Wishlist
--------

- graphical object system editor?

- variables in expansions "inherit" types from "parent" refinement

please email j.stader at ed.ac.uk with additional problems you are
aware of.
