Page-1 [Next]up.gif (995 bytes)

Objects can be used to model and help conceptualize, understand, and clarify at many levels:

Business operations: "and then order-fulfillment informs shipment about ..."

General problem domains: "production capacity is determined by available machines and load ..."

Software requirements: "and the scheduling system must do the following ..."

Architecture: "we will always use typed event channels ..."

Designs: "if your class does this, and her class does that, then we can ..."

... and, of course, code.

An object may be or do many different things. Typically, we want to describe some interesting aspects of that object; that partial, and abstract view of the object is called a Type. A type describes the behavior of an object by describing:

The abstract state of the object using attributes: "the order has some priority"; or "the communication channel has a source and sink port", or "the factory has a load and a set of available machines"
The actions that object participates in and their effect on its attributes: "the order gets cancelled", or "the communication channel gets closed", or "a new machine is installed in the factory".

An action is most useful and interesting in the context of other related actions; in combination they define a collaboration that accomplishes some goal. The place_order action is useful in a collaboration involving take_order, fulfil_order, send_shipment, receive_shipment, invoice, pay, which together accomplish the goal represented by the more abstract action buy_stuff.