ProtocolCharts: An Introduction by Examples

by Doug Lea.

ProtocolCharts are a graphical notation for describing statefull interactions among objects. To a first approximation, they combine most of the properties of StateCharts that have beed adapted into standard OOA/D notations, along with those of Interaction Diagrams.

ProtocolCharts grew out of work on PSL (see ECOOP 95 paper and Sun Technical Report), a more formal specification system for open distributed object systems geared especially for CORBA. However, the version described here can be applied to nearly any OO notation system. I'll illustrate using a hacked-OMT similar to that used in the ``Gang of Four'' Design Patterns book.

Example 1: Subject/Observer

In the Subject/Observer pattern, Subjects maintain some kind of representation of the state of something they are modeling, along with operations to reveal and change this state. Observers somehow display (or otherwise use) the state represented by Subjects. The basic idea in Subject/Observer is that when a Subject's state is changed, it merely informs one or more observers that it has changed. Observers are responsible for determining the nature of the changes, and whether, for example, they require re-display.

The version illustrated here is one of the variants described in Design Patterns. Here, the Subject sends a reference to itself as an argument to notifywhen it is changed; the Observer uses this reference to probe for values, and performs a redisplay only if the state actually differs from that held in a cache.

Structure

There are two main views of Subject/Observer, structural and dynamic. The structure can be described in terms of hacked-OMT interface diagrams:

A few minor differences in convention from those in Design Patterns make ProtocolCharts simpler to construct:

  1. Attributes are taken as purely abstract. As a convention, they are capitalized. There is no commitment that, for example Subjects ``directly'' hold the bits necessary to maintain Val. Concrete classes might for example implement attributes via methods that interact with yet other objects maintaining the representation. In fact, it is sometimes possible for an implementation not to represent an attribute at all -- an attribute might hold of an object without it ``knowing'' that it does. In keeping with this view, attributes are referenced using ``function notation''. For example, the state value of some Subject s is referenced as Val(s). Also, as a convenience, reference-style attributes are represented redundantly. They show both the links to the classes they can refer to, as well as pidgin-C++ textual declarations. (Of course, it is equally possible to use Pidgin-Smalltalk or Pidgin-Java or whatever for a base syntax.)
  2. As in Design Patterns, operations are listed in pidgin C++, but with the addition of CORBA IDL oneway qualifiers indicating asynchronous operations that do not bear replies (not even void). These are useful even in non-distributed applications when describing operations that are ``logically'' asynchronous in that callers don't care when they complete.

Dynamics

In words, the main motification protocol is that when a Subject s receives a changeVal request, for each Observer o in its set of Observers, it makes sure that its abstract state Val(s) has been set, sends a notify message to the observer, and then replies to whoever called changeVal. When the Observer o receives the notification, it ``probes'' s by asking for its currentVal. If the returned value differs from the value recorded as CachedState, the Observer sends itself a display request. The details of what happens when an Observer receives that display request aren't important to this aspect of the protocol.

The associated ProtocolChart is:

The basic properties of ProtocolCharts are as follows. (More detailed and formal descriptions of semantics are contained in the PSL papers).

Nodes

Nodes represent situations -- States of affairs with respect to one or more entities. Situations can include:
  1. Declarations giving names to entities or expression values. These are listed in pidgin C++, but may also include ``on the fly'' declarations embedded in other expressions.
  2. Expressions describing attribute values of one or more entities, listed in pidgin C++.
  3. Expressions of the form in(...) describing the fact that certain messages have been received.
  4. Expressions of the form out(...) describing the fact that certain messages have been issued.

One important difference between situation nodes and the nodes used in normal state diagrams is that message issuance/reception is listed as as an aspect of a situation itself, not as a part of a transition.

Messages may be given names (by convention all uppercase). Messages are listed in pidgin C++ surrounded by angle-brackets. A reply to another message M is listed as reply[M](return-val). Similarly, an exception reply is listed as throw[M](excptn). An in(...) or out(...) expression can optionally contain a by (...) suffix to indicate or emphasize which entity receives or issues the message.

In principle, a situation node can list any mixture of descriptions mentioning any number of entities. However, in practice, they nearly always describe the abstract state and/or actions of a single object. In this case, it is a good idea to color-code them, so like-colored nodes all include descriptions of the same entity.

As with StateCharts, situations in ProtocolCharts can be nested to indicate alternative subconditions. An implict (or explicit) default subsituation can indicate cases in which none of the listed alternatives apply.

Two or more instances (realizations) of the same situation may occur ``simultanously''. For example, in the above Subject/Observer protocol, as many instances of the very first situation occur as there are Observers in Obs(s). The ProtocolChart allows (but does not mandate) that each instance can proceed concurrently.

Links

Directed links between nodes indicate the followed-by relation. When one situation is indicated as following another, instances of the second occur no later than the first. All but the initial node(s) of a ProtocolChart have incoming links. The symbols at the bases of the links tell you the sense in which the followed-by relation holds between two situations A and B:
  1. A |> B (triangle) means that ALL A's are followed by B's, but not necessarily vice-versa. Triangles are mainly used to link a situation in which one object is obligated to issue a particular message as part of another operation, but may issue it at other times as well.
  2. A [] B (square) means that ALL B's are preceeded by A's, but not necessarily vice versa. Squares are mainly used for situations with incoming event receptions, indicating that a situation describes only one possible effect of its predecessor.
  3. A <> B (diamond) means that both relations hold, thus that A's and B's are necessarily paired across time. Diamonds are mainly used to link situations listing reception of procedural requests with with those listing the issuance of replies.

Unlike raw code descriptions, these links do NOT represent pure one-step-at-a-time flow -- any amount of time and any number of other nonconflicting actions may occur between the listed situations. ProtocolCharts describe the minimal required actions of participants, but do not rule out the existence of other compatible actions in implementations. In fact, there is no notion of an ``atomic transition'' at all in ProtocolCharts. Any number of other (nonconflicting) situations may occur in between those that are listed. Among other things, this permits refinement of protocols in subclasses. (The lack of a clear basis for splicing in other unlisted actions etc., in refinements or implementations is a bug in most state and interaction notations as applied to OO.)

Scopes ``grow'' across the links of a protocol. This mirrors the fact that protocols accumulate state across time. Any situation expression may refer to any name declared in any of its predecessors. So the flow of links across nodes should not loop. (More technically, there are no implicit ``fixed point'' conventions. These would add complexity without adding usability.)

Last update Tue May 9 06:17:30 1995 Doug Lea (dl at gee)