Start implementing a simple State class
Create a test suite for planning-related classes
Use `require_relative` instead of `require`
Correct the name of the state name attribute

When I changed the name of the test method I forgot to change the name
of the attribute accordingly.
Start implementing a simple Action class
Make State check if it satisfies simple condition
Merge branch 'master' into planning
Allow the definition of arbitrary state variables

This makes a state more convenient to use since arbitrary variables can
be defined on it directly instead of going through the `variables`
attribute.
Make conditions refer to state variables directly

Being able to refer to the state variables directly makes the conditions
less cluttered. Because State is an OpenStruct, using instance_eval to
implement State#satisfy? results in returning false if the condition
contains comparisons involving nonexistent state variables instead of
raising an exception.
Add callable effects to actions
Start implementing a simple Planner class

Currently, the planner solves trivial problems only. i.e., problems with
goals that can be achieved by calling a single action.

Note that the action effect block must take in the state as an argument
and manipulate its variables. Otherwise, [the block will be just setting
local variables instead of using the dynamically-added accessors of the
state][1]. In effect, the action will simply not affect the state.

[1]: http://stackoverflow.com/questions/4403973/
Enable states to apply effects to themselves

Again, the block containing the to-be-applied effects must take in the
state as an argument and manipulate its variables. Otherwise, the block
will be just setting local variables instead of using the
dynamically-added accessors of the state (that is, the effects will
simply not affect the state).
Refactor the (still trivial) Planner#solve method
Implement forward state-search planning algorithm

Now planners can solve non-trivial problems (i.e. problems the solution
of which consists of more than one action). This particular algorithm is
taken from _Automated Planning_ by Ghallab, Nau, and Traverso (Figure
4.1). Because the implementation is nondeterministic, Planner#solve may
return a redundant solution (i.e. one containing a proper subsequence
that is also a solution).
Initialize actions with names and parameters

Now, it takes fewer statements to create an action.
Modify DbcMethod in light of Action

The equivalence between DbC methods and automated planning actions is a
central idea of my thesis. Eventually, I plan to completely replace
Actions by DbcMethods, but to avoid breaking the planners, I made
"effect" an alias for "postcondition."
Remove unused methods from DbcMethod

DbC methods are not responsible for evaluating their conditions; States
are responsible for checking if they satisfy preconditions and for
applying postconditions to themselves.
Use DbcMethods instead of Actions for Planners
Delete Action class as it's replaced by DbcMethod
Start implementing a DbC-flavoured use case class

Currently, this DbC-flavoured use case class doesn't look that much
different from a regular one since use cases tend to contain
preconditions and postconditions anyway. Nevertheless, the class name is
prefixed with Dbc to keep it consistent with the other non-planning
classes.