UML22 — Setting structural features of a data type

Document: Unified Modeling Language: Superstructure, Version 2.1.1 (formal/2007-02-03)
Sections: 11.3.12 (ClearStructuralFeatureAction) and 11.3.53 (WriteStructuralFeatureAction)

(This issue surfaced during work on the Semantics of a Foundational Subset for Executable UML Models submission.)

Background:

Use the term "structured" data type to refer to a data type that is not a primitive type or an enumeration. Such a data type may have attributes, which can be read and written by the read and write structural feature actions (for the purposes of this discussion, consider clear structural feature action to be a kind of write structural feature action).

Semantically, the main difference between a data value that is an instance of a structured data type and an object that is an instance of a class is that a data value is passed "by value" while an object is passed "by reference". That is, a data value is itself a true value that can be passed as a parameter value to behavior and can flow on "object" flow edges ("object flow" really isn't a better name than "data flow", but the way...). On the other hand, an object exists with its own identity in the extent of their class at a specific locus, and only references to an object can be passed as values.

Thus, there may be many references all to the same object. As a result of this, any change to the attributes of an object via one reference will be reflected in future reads of that attribute via different references to that object.

In the case of a structured data value, however, a change to one of its attributes will only be reflected in the value actually being acted on. If that value is not then itself passed on, this change will not be visible in any other data value. Unfortunately, write structural feature actions do not have output pins. The assumption seems to be that such writes always happen "in place". This works for objects that have their own identity, but there is no clear "place" for which the change can happen for structured data values.

Note that this would still be an issue even if variables were allowed in fUML (and so it is an issue in full UML 2 with variables, too). To change a value in a variable, one needs to use a read variable action. If the value in the variable is a structured data value, then the read variable action will place a "by value" copy of the data value on the output pin of the action (since data values don't have identity or references, it can't really do anything else...). Therefore, a write structural value action acting on the output of a read variable action will make a change to this copy, not the value in the variable. But then, since the write structural value action has no output pin, there is no way to get the changed copy back into the variable (or use it in any other way, for that matter.)

Proposed resolution:

Add an output pin to write structural feature actions. If the "object" being acted on is really an object (that is, an instance of a class), then the input reference to that object is just place on the output pin. But if the "object" being acted on is a data value (that is, an instance of a structured data type), then the value placed on the output pin is a copy of the input data value, but with the given structural feature value appropriately updated.

(Note that the output pin is not strictly necessary for a true object update, but it seems simpler to always have the output pin. In the case of a write to an object, the output pin can simply be ignored – though it might sometimes be convenient even in this case for "chaining" actions on an object.)

No Data Available