Hi experts,
re: Activity Diagrams: How to model actions sharing intermediate results
This is a cross post from another group. Apologies. Excuse: I need an an answer fast. Thought: The heaven;y gates of excuses are always very busy ...
Here goes... Scenario: In a UML/SysML activity diagram, I have two concurrent threads. In one thread there is Action X and in the second thread there is Action Y.
Action X shares its intermediate result data with Action Y, because Action Y needs the data for its own processing.
Similarly, Action Y shares its intermediate result data with Action X, because Action X needs the data for its own processing.
How would I show on an activity diagram these two flows (exchange of data)? The problem I am having is that in order for an action to output something, then the action must complete its processing. That is the way I understand SysML actions: there is no such thing as an action 'somehow magically outputting something' while still only half-way complete.
Seems to me that to model such a thing I am forced to add some detail inside the two actions X and Y.
Example diagram supplied, of what I want to do. But I don't think that this activity diagram does it.
Thanks,
Avraham
There are two ways to model intermediate computations being passed out of an activity before it completes: The first is to use <<stream>>. In the example shown, the action in the middle sends the object token to to the activity parameter as it completes, not as the activity completes.
The other way is to simply make the action from which you want intermediate output a separate Call Behavior (nested activity), so that it pipes out the value when the Call Behavior completes.
Approach #1 looks great. Thank you very much. I was sort of worrying that I had a need that "nobody had thought of yet". Hopefully I will get time soon to say more about the way this technique is to be used.
A clarification. The above is what *I* do. I think that stream should be a stereotype, as is <<rate>> and <<continuous>>. However, in the UML 2 spec, it is an *annotation*, which is basically a comment. I find that unsatisfying. I've attached the relevant part of the UML 2.5 spec
More ...
Although UML does define a property on activity parameters IsStreaming which by default is set to False; it also provides for a standard notation which nobody uses as far as I can tell.
Hi Bruce,
Thank you for sharing with me your thorough treatment of this.
>> "I think that stream should be a stereotype, as is <<rate>> and <<continuous>>. However, in the UML 2 spec, it is an *annotation*, which is basically a comment."
Re *annotations*: So I have just finished reading up on the precise meaning of "annotation" in the UML spec. (v2.5.1). As far as I understand, that is section 5.2, Annotations on Example Diagrams. Correct?
Yes, that is to say annotations are not part of the formal UML spec.
>> "Although UML does define a property on activity parameters IsStreaming which by default is set to False; it also provides for a standard notation" But the snippet you quote above from the spec says that the IsStreaming parameter is also (just) an "annotation".
Unless maybe you defined <<stream>> as a new profile (if that is the correct terminology).
By the way, I note that stream is also relevant in the subject of expansion regions, and there it is indeed a stereotype. (sec 16.14.21 in UML Spec 2.5.1: "enumeration type used to specify how an ExpansionRegion executes its contents", and Fig 16.52 which provides an example with <<parallel>> presented as a stereotype, as it seems to me.
To the overall point, it is perfectly reasonable to define stereotypes and assign them semantics when the base language doesn't do what you need in some circumstance. That's why stereotypes, tags, and profiles are in the formal UML language specification. You can, if you like, submit a proposed change (or what you see as a defect) the the UML RTF if you want the standard updated. For many people, this is unnecessary. Mostly, it's case of "be deliberate, be precise, and be consistent. "
Thanks