How it is and How it Should be

Changes and refactoring are an intrinsive part of evolution of any software. There is a lot of changes needed in Crackpot (code in trunk). Some of the changes are small - like renaming certain classes/functions and others are large - like architecture changes. Also see another list of needed changes in (crackpot_directory)/TODO.txt.

I am labelling the changes with severity labels of low, medium and high.

Objects and Attributes

Severity: Medium

Each ObjectType can have a "self" attribute which refers to the object itself. This will allow the existing framework of attributes to extend to include object references. For example, to refer to ObjectInstance a1, we can say "a1.self". (In the current implementation, a1 will be a ValueInstance. This is more of a hack.).

Severity: Medium

Formal ObjectInstance should be renamed as ObjectInstancePlaceHolder.

Actions

Severity: Medium

Right now contributions and conditions are connected with ActionType, while actually they should be connected to ActionTaskType.

Domain definition

Severity: Low

Right now all the information about the domain are read into a class called DomainPackage, which maintains repositories or objecttypes, objectinstances, attributetypes, actiontypes and so on. This has made DomainPackage class too large to the extent that it is exploding now.

In the future, we should have separate classes ObjectTypeRepository, ActionTypeRepository, and ObjectInstanceRepository. These repositories should handle name-based queries also like getObjectInstanceWithNameOfType(). ObjectTypes can contain its list of AttributeTypes and ActionResourceTypes. (Optional) Small factories like ObjectTypeFactory can be introduced; this has the logic to build ObjectTypes. ObjectInstanceRepository can contain the map from ObjectType to its ObjectInstances.

Finally, all the queries regarding the domain (and asked by heuristics) will be handled by PlanStructure class. So it can be something like:

class DomainQueryHandler
{
// all get and set functions related to domain
// implements facade that hides the various domain related repositories
};

class PlanStructure: public DomainQueryHandler {
// ...
};

Directory Structure
Update: Our colleague, Sima, completed the refactoring into the new directory structure.

Severity: Medium

As per Planning Group meetings, the directory structure has to evolve into something like this (this structure is not finalized, but will be soon):

PlanManager
PlanStructure
|- Object
|- Action
CostManager
CostStructure
CostCenter
|- Heuristics

Types and Instances

We can form a convention that functions to create instance will be a member function of type. For example, a ConditionType has a member to create ConditionInstance.

Complex Actions

Severity: Medium

Sometimes the further course of plan depends on result of performing an action. For example, try to open the door. If door is locked, it won't open. Then the agent must look for the key. This can be encoded as a monitoring ActionTask in the OpenDoor action: [If (monitor(door) == door-locked) insert look-for-key action into plan]. We need to develop/reuse a logic for this purpose. Further there may be monitoring loops within actions, like [while (monitor(water-boiling) == false) {}].

Using Description Logic

Severity: Medium

Our rich-world description should be based on a formalized logic. This helps in interfacing with other tools, communication with other groups and reusability in other situations. Description Logic is one such logic. Description Logic is the basis for several semantic web constructs. We can use Description Logic constructs for objects, actions, plans and goals.

Implementation of More Examples

Severity: Medium

Both domain independent and domain dependent techniques can be used, for example for Settlers domain: http://planning.cis.strath.ac.uk/competition/ .

Implementation: Build Related

We need to normalize the build process across compile time options, include directories, etc. See http://stackoverflow.com/questions/222827/how-do-you-organize-your-version-control-repository/304036#304036 for a good build strategy.

Use of Templates

We should move to using templates in a greater manner - namely for all types that do not need run-time polymorphism. The benefits of using templates are:
- policy-based class design helps to prepare more reusable components
- being purely syntactic entities they are also minimally intrusive to other class

I'm sure there is more to come. I expect this entry to be updated frequently.