This is a really nice MagicDraw/Cameo SysML tool modelling feature that is really worth knowing about. It helps you synchronise the ItemFlows on Connectors on IBDs with ObjectFlows in Activities, which are then related under-the-hood via the underlying 'realizingConnector' and 'realizingActivityEdge' of the synchronised ItemFlow, the 'conveyed' Classifier of which is then displayed on the ObjectFlow arrow symbol in the SysML Activity Diagram.
This process goes quite quickly, you don't have to know all the gory metamodel details to use it, and it can be done across an entire project to ensure consistency between the behavioural, structural, and flow models.
To add some spice to the example, the 'conveyed' Classifier (here a Signal) LoginRequest
is going to be a sub-type of the Request
, just for the sake of showing it can be done.
For this example we are going to have a SystemContext SC_WithFlow
as the 'subject' of the UseCase Process user request
(which is only one possible approach). The SC
has part properties for a block-based «actor» :User
and for the System (of Interest) :SoI
.
The UseCase carries a scenario Activity Process requests
. Normally one might use a more specific scenario name, but the name is chosen deliberately here because we are going to have a more general Request on the Pins, and the LoginRequest as the synchronised ItemFlow.
If you look at the Activity before synchronisation is performed (middle left), you can see that there is an ObjectFlow with Pins of type Request:
If you select the ObjectFlow, you can use the smart manipulator menu to bring up the Item Flow Manager (see the image for the manipulator icon used), and then select under Realize the detected ItemFlow, which conveys LoginRequest
.
After synchronising, the LoginRequest
displays much like an ItemFlow (it isn't though), and if you look at the specification dialog for the ItemFlow you'll see the synchronisation information that binds the ObjectFlow (an ActivityEdge) and the Connector via the'realizingConnector' and 'realizingActivityEdge' of the ItemFlow.
In the case where the type of the 'conveyed' Classifier and the Pins of the ObjectFlow are the same, you can just hide the type display on the Pins, but here in this contrived example they are different so the Pin type is left displayed.
The following related tips might help you if you wish to reproduce the example:
And remember always:Ever "lost" your ItemFlows but you know they are there somewhere?
ASIDE: SysMLv2 has even between integration between the behavioural model and the structural model, including for flows.