1
votes

I'm in the process of designing an activity diagram for a real-life card game and would like to know whether or not the use of a synchronization bar in the image attached is correct.

From my understanding, a synchronization bar can be used to separate flow into two or more activities. In my diagram, I've tried to illustrate two teams picking up a card from the set of cards they've been given. Team B's flow ends after picking up a card, this is because Team A must ask a question (found on the card) first.

enter image description here

2

2 Answers

1
votes

Basically your diagram is correct. Drawing of cards happens concurrently. However, there is an improvement you can do. I don't know out of which reason one of the players will ask a question and the other won't. So here I assume the fastest one will start (remembering a card game from Africa where both players draw cards as fast as possible with one hand and put them somewhere; no idea of the name and rules but it was fun to play). Anyhow, here's my suggestion:

enter image description here

Just put the drawing in an Interruptible Region and name it after whet ever causes the one player to be the first to ask. The flow final is not necessary as to UML rules (the token is swallowed since player B's action has no outgoing flow).

0
votes

I want to offer some improvements based on your explanation. (However as @ThomasKilian said, it is not so clear why one of the players will ask a question )

Case 1:
If both (TeamA and TeamB) should pick up the card and after that, you check the existence of question in selected cards: Your systems should wait for two players to pick up the card. So in this case, you should use Join Node after two pick a cards. (see my previous post about Join)

Case 2:
If the fastest Team should ask the question and there is no need to other team pick the card, there is an other improvement here:

You should use a Merge node with Decision after two pick a cards (see Merge with Decision explanation in this reference). (You can use a Merge node and after that a Decision Node too.)

So your decision is based on fastest team that pick the card. Then you should complete the model with following statement. If TeamA is fastest then TeamA should ask the question and TeamB should answer and if TeamB is fastest then TeamB should ask the question and so on.)

You can use this improvement in case 1 too (after the Join Node, you need a Decision to find the team that select the card and add above statement to your model).

Finally, If TeamA always ask the question after pick up the card and there is no need to picking the card from TeamB, there is only one improvement to use a Merge Node after two pick a cards. Consider that Merge Node input flows are alternate flows to accept single outgoing flow.