Hi Bruce
How are you doing.
I have a question on SysML Activity diagrams.
For a System S, there is a Product P, which contains Process P1 and Process P2.
Process X takes input and processes it and keeps the results internally.
Later on in the System processing cycle, Process P2 reads P1's stored results and it (P2) outputs them.
What is the SysML philosophy for presenting this? FYi, I have to try to keep my diagrams/model simple bc my corporation is still at the outset of using MBSE.
Can I present the above in one activity diagram? I.e. , show two time event elements T1 and T2, where T2 fires and reads the stored results and then outputs them? And maybe each of P1 and P2 should be after its own 'Activity Start' , because really each of process P1 and process P2 are separate activities / threads.
Further, in general, is what I have described - P1 and P2 - really two activities? Maybe they are really just two threads in one activity?
Thanks
Avi
The short answer is "you don't". The longer answer is more involved. A thread is a concurrency unit and the way you model those in UML/SysML is as active classes. Each active class manages its own event queue and it - and all of its parts - execute in the context of that owned thread. Active classes are shown with a double vertical line border on the class/block symbol.
Having said that, you can create an activity and represent active blocks as activity partitions on that activity diagram. See the attached figure. On the right, you see a BDD with the two active blocks shown (note the double line border on the vertical sides). In the body of the activity diagram, you see activity partitions, one for each of these blocks. Just for fun, I threw in a thread rendezvous to show what that might look like.
I would create such a view only if I wanted to depict a thread rendezvous; in most cases, I would create separate activity diagrams for each block as its classifier behavior, and make the blocks active so that the activities would execute in different threads.
Note that if the two blocks are NOT active, then there are these pseudo-concurrent regions between the forks and joins (although forks are joins are really required in most cases), but they would all execute in a single thread.
I hope this helps.
- b