[Back][Next]up.gif (995 bytes)

Actions are useful as part of collaborations. Each action has participant and parameter objects, characterized by their types. A joint action has more than one interesting participant that affects, or is affected by, that action. For example, a buy_house action involving buyer, seller, and realtor. A joint action may have a distinguished initiator and receiver e.g. pay_invoice initiator: seller, receiver: buyer. A localized action has just one participant.

The actions in a collaboration may be permitted to happen only in certain sequences; so the collaboration may have a sequence constraint. The most explicit sequence constraints are in procedural code: things must happen in exactly the order prescribed, with no possibility even for intervening actions to take place. More abstract and "open" sequence constraints are useful when modeling.

A scenario is a sequence of action occurrences in a collaboration.

Most collaborations exist as refinements, to fulfill a more abstract action (pay_invoice + order + deliver was invented to really do purchase_stuff); or to maintain an invariant (notify_of_change, probe_state, update_cached_state might really only exist to maintain the invariant: cached state always in sync with source state).

The concept of action, with refinement, generalizes the concept of use case. The use-case construct combines:

an abstract action: purchase_stuff (with its specification)
a set of refined actions in a collaboration: order, deliver, pay_invoice
a refinement mapping a sequence of finer actions to the abstract ones
constructs to help structure this (<<extends>>, <<includes>>, etc.)

In fact, Grady Booch's new UML user-guide now defines a use case as:

"A set of sequences of actions" (perhaps influenced by Catalysis input into the UML standard, and a bit confusing with their earlier definition of "action").

However, Booch does not explain how (or if) those "actions" are themselves different from use cases.

In Catalysis, purchase_stuff and order, deliver, pay_invoice are all valid actions at different levels of abstraction. It is sometimes useful to write things in a "use-case form" which combines the abstraction with its realization and the sequencing information; but is often wise to separate them using refinement, since there may be many alternate ways of decomposing the abstract action and of sequencing the finer-grained ones.