Notations

Class-Responsibility-Collaborator Cards

Class-Responsibility-Collaborators (CRC-) cards [BeCu89] help to identify and specify objects or components of an application in an informal way—especially in the early phases of software development.

A CRC-card describes a component, an object or a class of objects. The card consists of three fields that describe the name of the component, its responsibilities, and the names of other collaborating components. The use of the term ‘class’ is historical [Ree92], and we use CRC cards for other kinds of components or single objects as well.

Object Modeling Technique

The Object Modeling Technique (OMT) [RBPEL91] is a widely-used object-oriented analysis and design method. OMT consists of three models, the object model, the dynamic model and the functional model. We adopt the notation only for the object model, to show the static structure of interacting components. The object model describes objects or classes, their attributes, methods, and relationships. We also use the boxes that represent classes in OMT for other kinds of components. OMT represents association, aggregation, and inheritance relationships between components by lines that connect the components. The basic concepts of OMT’s object model notation are illustrated below:

Component

A rectangular box, denoting the name of the component and optionally its attributes and operations. Abstract components are labeled in italics as well as their corresponding abstract methods.

Methods

Method names are written in the component boxes. They denote the operations of components. We show abstract methods, that is, those that only provide the interface for polymorphism, in italics.

Attributes

Attribute names are written in the component boxes. They denote the data slots of a component.

Association

A line that connects components. Associations can be optional (shown with a hollow circle) or multiple (shown with a black circle). A number at the end of an association may denote its cardinality. Association of components is used to show any kind of component relationship except aggregation and inheritance. Transitive relationships are typically not drawn.

Aggregation

A diamond shape at the termination of an association line denotes that the partner component(s) at the other end of the association are contained within the component.

Inheritance

This relationship is denoted by a triangle in the middle of the association line. The apex of the triangle points to the superclass.

Object Message Sequence Charts

Message Sequence Charts (MSC) are a standard notation for designing and specifying protocols among concurrently-operating entities such as processes or hardware elements [GR92][GGR93]. The MSC notation is standardized in the telecommunication domain and integrated into the SDL language. It specifies a scenario that shows the signal flow between the entities of a given domain. We do not follow the SDL/MSC standard notation, however, and adapt the MSC notation to demonstrate object or component interaction among the participants of a pattern. We refer to this adaptation as Object Message Sequencing Chart notation (OMSC).

Object

An object or component in an OMSC is drawn as a rectangular box. The box is labeled with the name of the component in the pattern. An object that sends or receives messages in the OMSC has a vertical bar attached to the bottom of the box.

Time

Time flows from top to bottom. The time axis is not scaled.

Messages

Messages between objects are denoted by arrows. These arrows are labeled with the method name at the head, if applicable. To show the return of the control flow to the sender we extend the standard MSC notation by using arrows with a smaller head. Both types of arrows are combined to a single double-headed arrow if the activated method does not send other relevant messages.

Object Activity

To denote the activity of objects that perform a specific function, procedure, or method, rectangular boxes are placed on the vertical bar attached to the object. An object may also send messages to itself to activate other methods. This situation is represented by nested boxes offset slightly to the right.

Parameter

Parameters are only noted explicitly when they are necessary for the understanding of an OMSC. Parameters of a message are shown as a box on top of the arrow, and return parameters below the returning arrow. If responsibility for a parameter object is passed along the arrow the name of the object is shown in boldface. If only a reference to the object is passed as a parameter, its name is shown in italics.

Object Life cycle

In most cases we assume that all relevant objects already exist, and the corresponding boxes are drawn at the top of the OMSC. If an OMSC shows object creation, this is denoted by an unlabeled arrow to a box placed within the OMSC. If an object ceases to exist, this is denoted by a cross that terminates the vertical bar. This notation corresponds to the constructor and destructor calls in C++.

Address Space

A thick angled line shows an address space or process boundary. Messages that cross this boundary are transferred by a means of an IPC mechanism. Typically those messages are treated asynchronously and processing continues within the sending and the receiving object concurrently. Remote procedure calls across process boundaries that block the sender until the remote procedure returns are an exception to this.