3.4 Completing Interaction Diagrams

OCL expressions may also be used to complete UML interaction diagrams. The example used in this section is the diagram shown in Figure 3-5. In the R&L system, new transactions are introduced through an operation of LoyaltyProgram called addTransaction . This operation takes five parameters:

1. The number of the account for which the transaction was performed, called accNr of type Integer

2. The name of the program partner that delivered the service for which the transaction was performed, called pName of type String

3. The identification of the service, called servId of type Integer

4. The amount paid for the service, called amnt of type Real

5. The date on which the transaction took place, called d of type Date

Figure 3-5. OCL expressions in a sequence diagram

The addTransaction operation implements the following algorithm. First, the correct service is selected. This service calculates the points earned or burned by the transaction and creates a transaction object of the right type. This object is added to the service's association end transactions . Next, the correct account is selected. The newly created transaction is added to the transactions associated with this account, meanwhile adjusting the balance of the account. Finally, the correct card is selected and the new transaction is added to the transactions associated with this card. The algorithm is depicted in the sequence diagram.

As an elaborate example of an OCL postcondition, the addTransaction operation is also specified using a postcondition in the following OCL expression:

  context  LoyaltyProgram::addTransaction( accNr: Integer,                                         pName: String,                                         servId: Integer,                                         amnt: Real,                                         d: Date )  post: let  acc : LoyaltyAccount =                 Membership.account->select( a  a.number = accNr ),           newT : Transaction =                 partners-> select(p  p.name = pName)                    .deliveredServices                       ->select(s  s.serviceNr = servId)                         .transactions                            ->select( date = d and amount = amnt ),           card : CustomerCard =                 Membership->select( m                                m.account.number = accNr ).card  in  acc.points = acc.points@pre + newT.points            and          newT.oclIsNew()                                      and          amnt =  0 implies newT.oclIsTypeOf( Burning )        and          amnt >  0 implies newT.oclIsTypeOf( Earning )        and          acc.transactions - acc.transaction@pre = Set{ newT } and          card.transactions - card.transaction@pre = Set{ newT } 

3.4.1 Instances

In an interaction diagram, instances are shown. Because of our requirement that a model must be internally consistent, each instance shown must be of a type declared in another diagram in the model. Usually, the other diagram is a class diagram. Furthermore, although no rules in UML state this explicitly, the target of a message in an interaction diagram must be known and visible to the source of the message. This can be indicated in the diagram using the name by which the target is known to the source. Formally, this has no meaning at all, but the human reader will probably find it useful. Another way to express this is to use your own names for the instances, and accompany the diagram with OCL expressions that state the relation between the instances.

In Figure 3-5, you can see that the instance of LoyaltyAccount is named m.account , where m references the Membership instance in the diagram. To state the relationship between the other instances in the diagram, the following expressions can be used:

 lp.partners->includes(pp) and pp.name = pName pp.deliveredServices->includes( s ) and s.serviceNr = servId lp.Membership->includes( m ) and m.account.number = accNr 

3.4.2 Conditions

A part of the interactions in a sequence or collaboration diagram can have an attached condition that specifies in what circumstances the part is executed. This condition can be written as an OCL expression.

Because an interaction diagram is an instance diagram, the OCL expression is written in the context of an instance, not a type. This is a rare case; therefore, extra attention has to be paid to determine the contextual type and the contextual instance. The contextual instance is the instance on whose lifeline the condition is written, and the contextual type is the type of this instance.

An example can be found in Figure 3-6, which extends the sequence diagram in Figure 3-5. The service object s creates a transaction of the right type, depending on the amnt parameter of the addTransactions operation. The conditions are written as valid OCL expressions, given the fact that the diagram specifies an operation, and therefore the parameters of the operation can be used.

Figure 3-6. Extended interaction diagram

3.4.3 Actual Parameter Values

A message in an interaction diagram is not equivalent to the specification or definition of an operation or signal, but instead represents an operation call or the sending of a signal. Both operations and signals can take parameters. The parameters of a message are not the formal parameters but actual values. For instance, when an operation is defined, its name and the name and type of every parameter is given, as in setValue(i: Integer) . When an operation is called, its formal parameters are substituted by actual values, as in setValue(235) .

To specify the actual value of a parameter to a message, you may use an OCL expression. In the example shown in Figure 3-5, the value to be substituted for the parameters of operation addT is provided by newT , a reference to the newly created transaction instance.

Note that a message to an object in an interaction diagram must conform to an operation in the type of the target object, or to a signal that has been elsewhere defined. Conformance here means that the name of the operation is the same, and the parameters in the message are of the types indicated for the parameters of the operation. Likewise, the result message in an interaction diagram (a dotted arrow in the sequence diagram, or an assignment in the collaboration diagram) must be of the type indicated as the result type of the called operation.