Other Domain Patterns

Elaborations of many of the following patterns are left as exercises.

Accountability

The accountability pattern explores the relationship Role X is accountable to Role Y:

Combine this pattern with Rules and Assertions, Types as Objects, and Actor-Role to build an interesting composite pattern.

A closely related pattern explores the relationship between an organization (Corporation, Division, Office, League, Conference, Battalion, Platoon, etc,) and its subsidiaries:

Rules and Assertions

Assertion about a domain can be seen as instances of more general rules.

For example, the assertion that "Private Smith is accountable to Sergeant Jones" is an instance of the rule "Privates are accountable to Sergeants".

We can represent rules and assertions explicitly using the Types as Object Pattern:

Quantities

In scientific and business domains it is important to associate values with units.

Quantities are values bound to units such as 100: Kilometers, 6.6: Miles, or 3.14: USDollars.

Quantities can be added. For example, adding 1: Kilometers to 20: Meters produces 1020: Meters. The reverse, adding 20: Meters to 1: Kilometers, produces 1.02: Kilometers. Adding 2: Miles to 3: Euros throws an exception.

Quantities are a special case of the Types as Object pattern:

Observations

Observations made in hospitals and labs must be recorded.

An observation has a subject, an observer, a time, a place, and a result.

The type of an observation is a phenomenon, such as temperature, weight, or blood type.

Observations can be measurements or categorizations.

The result of a measurement is a quantity.

The result of a categorization (such as blood type) is a category (A, B, AB, O).

Accounts

An account is a container where valuables can be stored. Examples of accounts include bank accounts, inventories, and wallets.

Valuables can be withdrawn from a source account and deposited into a target account.

An account has a statement that keeps track of all transactions involving the account.

A transaction records the valuables withdrawn and the target accounts they were withdrawn to or the valuables deposited and the source accounts they came from. A transaction also has a date.

An account has an owner.

An account manager manages a collection of accounts, insuring that valuables simply don't disappear.

An account manager represents external accounts by internal proxy accounts.

Activities

An activity can be a simple activity (called an action) or a composite activity, called a procedure, process, plan, or workflow. The steps of a procedure can be actions or sub-procedures.

We can model activities using the Composite Design Pattern:

An activity is executed in a context (such as an office) by a processor (such as a salesman).

The same activity may occur in multiple procedures.

Activity A occurring in procedure P1 may have different successors and predecessors than its occurrence in procedure P2. For example, the activity "give patient Smith an enema" may have "take patient Jones' temperature" as its successor when occurring in Nurse Betty's workflow, but it may have "X-ray patient Smith" as the next step in Dr. Doolittle's treatment plan.

To allow for this we represent links between a procedure and its steps as instances of a Transition class. A transition object can keep track of the predecessor and successor activities relative to the procedure.

Note that a transition can have a guard that must be true in order for the successors to be executed. An example of a guard might be "resources available".

Note that an activity can have more than one successor. The successors can be conditionally executed or executed in parallel depending on the type of the transition.

An activity can be blocked until all successor activities have been completed.

Activities are explicitly represented by UML activity diagrams.

Some activities are themselves patterns called Role Models.