Jens
Jens

Reputation: 9406

Model data flow from (flow) port to UML activity diagram

One of the projects I am working on uses flow ports to model data flow between classes. We now started to model dynamic behavior using activity diagrams and state charts and are looking for a way to express that the data used in an activity diagram has been received on a specific port. Bascially, we want to create a connector between a flow port and e.g. an activity parameter node.

I think modelling data flow with ports is quite common especially in System Engineering, and there should be ways to link the data to activities. I can think of two some ways:

The first option would be ok, but our modelling tool Rhapsody 8.1 seems to not support ReadStructuralFeatureActions. The other two approaches have the drawback that there is no direct connector between the port and the activity in the model and it is not visually obvious, so I would like to have a better alternative.

I am wondering if there anybody knows of better approaches to achieve this, e.g. using SysML (1.3).

Upvotes: 4

Views: 994

Answers (1)

sim
sim

Reputation: 1168

The connections between the static and the dynamic views in UML and SysML are "hidden" in the less visible part of the model. I guess the reason is that the designers of UML wanted to separate these. So there are no graphical or otherwise very explicit connections.

Instead, the connections are quite natural, so you can just use it. Examples are the guards, triggers or actions on transitions in state charts or activity diagrams. This ReadStructuralFeatureAction is implemented implicitely by using the static element directly. You can modell them directly there. So they occur next to the edge that represents the state transition or control flow. A futher way is to use Receive Actions and set the property of the reception to an event or an triggered Operation. By using Send Actions you can trigger Events in the same structural element or others. When doing so in Rhapsody you need to specify the target Port and the target part.

Neither in UML/SysML or Rhapsody it is foreseen that you want to know via which port the call came or the attribute was changed, when you offer the interface of the Class/Block. But you can realize this by using full ports and implement the intended behaviour (which sould be distinctive - otherwise it would not be needed to know the source). So each full port has a state chart or activity and passes internal signals or events the object of your class. For calling operations from actions there are two ways, the more hidden one by just calling from the actions (or state on enter or leave) and the more visible one by using call operations.

The visibility of these connections have been changed in recent UML or SysML versions. So this will change significantly when updating to later Rhapsody versions; although I would really recommend to update to the latest Rhapsody version, as it brings better sysML support, far less bugs, a few new features and better usability.

Upvotes: 2

Related Questions