Source: oose Innovative Informatik eG ( Axel Scheithauer)
There are a number of problems with the notation shown in Figure 17.20
1. In the list of parameters the type should follow the name (x:Integer)
2. The asynchroneous message s1 cannot be sent to a non active Class (better use a synchroneous message)
3. The return value assignment of the InteractionUse has an unusual format (:xx.xc). The specification doesn’t define the format, however I would suggest to use notation from common object oriented programming languages. To do this, the property referenced by the left lifeline should have a name (e.g. xx1). Then the notation would be xx1.xc.
4. The argument for the inout parameter w should be prefixed with out (according to the specification, even though it is probably unambiguous even without it).
5. Sending asynchroneous messages to an Integer value is not possible (DataTypes cannot be active).
6. Sending a message to an Integer value to set this value is not possible (put(xc)…). This would mean to ask Integer Value “2” to put Value “9”. The object owning the parameter that has this value is responsible for setting it. If w would be an attribute, it could be done with a AddStructuralFeatureValueAction called by an ActionExecutionSpecification of lifeline :xx (see Figure 17.16). If the value is read from the object, a getter could be used and the return value could get assigned to the parameter or attribute (w=get_xc()). This works with out-parameters as w as well (but not for setting a parameter to a constant as a_op_b). However since both elements w and a_op_b are out-parameters of the Interaction, a more natural way would be to model the reply-message with the respective out values (a_op_b(w:xc):fail). In any case, the lifelines w and a_op_b are no longer needed.
Reported: UML 2.5 — Wed, 5 Apr 2017 14:15 GMT
Updated: Wed, 5 Apr 2017 14:15 GMT