A.2 Introduction to Class Diagrams

This architecture document uses class diagrams to describe logical data models and domain models of the OOI CI system. This section explains the meaning of the graphical notation that will be used here. This notation is based on UML class diagram notation [UML]

Class

A class picture (Figure A.2-1) represents a type (class) of a system entity; it can be a logical or a physical entity. In the real system there might be multiple instances of one class. In this way, all these instances share the characteristics of the class. Example for a class is "Sensor". Instances then are all the different sensors in the system: "CTD_Pioneer_1", "Seismometer_3", "Hydrophone_2".

Figure A.2-1 UML Class
Figure A.2-2 UML Package

Package

A package is a container that organizes elements in the domain model. One package can contain other packages (sub-packages) and entities (Classes, Associations, and Generalizations). Typically, packages are created to group entities by topic and structure them hierarchically.

Block

Blocks (or colored boxes) are group entities with similar characteristics. They include a textual description and stress a component view of the system. An entity can be part of various blocks in different views of the system, but an entity is part of only one package.

Figure A.2-3 UML Block

Association

An association is represented by a solid line between two classes. It establishes a relationship between these two entities. It can be directed, indicated by an arrow, or undirected (Figure A.2-4).

Figure A.2-4 UML Undirected (left) and directed (right) associations

Associations can have names, indicated by labels along the solid line and a multiplicity on both ends of the line (Figure A.2-5). In case of a directed association, the name is interpreted in the direction of the arrow.

Figure A.2-5 UML Named, directed association with multiplicities

The multiplicity of an association determines the number of instances of the given entity at each end of the line. In Figure A.2-5, for example, exactly one instance of Class1 refers to 0 or more instances of Class2. Possible values of multiplicity are:

• Exactly one instance is required.
• 0..1 At most one instance is allowed.
• 1..* One or more instances are required.
• * An arbitrary number of instances are allowed.

One particular type of association is the aggregation association (Figure A.2-6). It is a directed association with a white diamond on one side and an arrow on the other. The arrow can be omitted. It denotes that the class next to the arrow is part of the class next to the diamond. In most cases, this expresses a "has-a" relation.

Figure A.2-6 UML Aggregation association

Generalization

Generalization is a graphical notation used to describe hierarchical types. The meaning of Figure A.2-7 is that Class1 is a specialization of Class2. Therefore Class1 has inherited all the relationships and attributes of Class2 and an instance of Class1 can be used where one of Class2 is required. In words, this expresses an "is-a" relation. Class2 is a special case of Class1.

Figure A.2-7 UML Generalization

A.3 Introduction to Message Sequence Charts

Message Sequence Charts (MSCs) provide a rich graphical notation for capturing interaction patterns. MSCs have emerged as a means for specifying communication protocols in telecommunication systems. They have also found their way into the new UML 2.0 standard, which significantly improves the role of interaction models within the UML.

We use the MSC notation to describe the interaction patterns defining services. MSCs come in two flavors (basic and High-Level MSCs) and have a number of operators. In this appendix, we briefly introduce the notations of MSCs used in the diagrams presented in this document, namely the basic MSCs and the LOOP, PAR, ALT operators.

Basic MSCs consist of a set of axes, each labeled with the name of a system entity. An axis represents a certain segment of the behavior displayed by the entity it references. Arrows in MSCs denote communication. An arrow starts at the axis of the sender; the axis at which the head of the arrow ends designates the recipient. Intuitively, the order in which the arrows occur (from top to bottom) within an MSC defines possible sequences of interactions among the depicted entities.

We exemplify the MSC constructs by showing different interaction patterns between a client and a server. In the MSC from Figure A.3-1, the client enters the start state, sends request message to the server, receives response message from server, and enters the done state, in the order specified from top down. States are represented in MSCs as labeled hexagons.

The MSC from Figure A.3-2 uses a LOOP construct to represent the repetition of an interaction pattern: the client repeatedly sends request to and receives response from the server in that order. The asterisk at the top left corner of the LOOP box indicates there can be any finite number of repetitions.

Figure A.3-1 MSC basic constructs
Figure A.3-2 MSC with LOOP operator

The MSC from A.3-3 shows the use of an ALT construct to indicate alternative paths in an interaction pattern: the client performs the same sequence of operations as in Figure A.3-1, except that the client may receive an alternative message reject from the server rather than response, depending on server's decision.

The MSC from Figure A.3-4 shows the PAR operator. After the server receives request, it sends messages response_1 and response_2 in parallel: the order in which the messages response_1 and response_2 occur is left unspecified; both must arrive before the client enters the done state.

Figure A.3-3 MSC with ALT operator
Figure A.3-4: MSC with PAR operator