20. Planning and Action
Actions
We often need to represent important actions that take place in the application domain such as transactions and observations. It is often important to keep track of when and where an action took place. It is also important to keep track of who participated in the action.
Actions can be represented using state diagrams:
Plans
Some actions consist of a sequence of subactions. For example, "drive to work" might involve the sequence of subactions: "start the car", "turn right at Main", "turn left at Elm", "park the car", etc. A sequence of actions is called a plan. A routine plan is called a process or workflow.
We could simply model a plan as both an aggregation of Action and a specialization of Action:
Action References
This isn't such a great idea, because each action needs to keep track of the actions it depends on (dependants) and the actions that depend on it (consequences). However, the same action might appear in many plans. In each of these plans it may have different dependants and consequences. For example, a doctor might devise a treatment plan for a patient:
1. measure Smith's white cell count
2. administer anti-biotic to Smith
3. wait 24 hours and repeat if necessary
Action 2 might also appear in a nurse's workflow:
1. administer seditive to Jones
2. administer anti-biotic to Smith
3. administer analgesic to Johnson
We can solve this problem by introducing an association class between Plan and Action:
A Possible C++ Implementation
class Plan
{
list<ActionRef*> actions;
// etc.
};
class Action
{
list<ActionRef*> plans; // i.e., the plans I am part of
// etc.
};
class ActionRef
{
Plan* myPlan;
Action* myAction;
list<ActionRef*> dependants, consequences;
// etc.
};