Tags and keywords
StateMachine approach (left)
This approach is in some ways easier and cleaner, and requires less synchronisation. The only tricky part is that there MUST be an intermediary MergeNode for the looping control flow (shown in green), which is also entered here from the InitialNode.
Activity approach (right)
This approach requires some careful synchronisation. In addition to having an intermediary MergeNode for the looping control flow (shown in green), the control within the structured activity node has to fork then join (shown in blue).
Applicable to both
They both use the ReadLine Activity from the fUML_Library.mdzip, which you can load via Use Project > Use Local Project then select under <install.root>/modelLibraries. A 'choice' String value entered via a CLI in the simulation console is tested for '1', which triggers Signal Event1, otherwise Signal Event2 is triggered. Groovy println is used via OpaqueBehaviors to echo the received events to the console. These could be replaced with Activities to handle the events (such as for Signals with attributes).
The use of a structured activity node (shown in magenta) in each is optional, but it helps make the control flow clearer and also aids the modelling and helps keep the diagrams tidy. It can be upgraded to a dedicated Activity for a CallBehaviorAction to make it more explicit.
Learn SysML for MBSE with the Webel IT Australia Live Online web seminar or On-Site course!
