 |
|
|
| Re: Activity Diagram: Decision or Parallel Activities? |
|
|
Sorry, let me make absolutely sure I get this:
In the example I provided, the user could actually perform some or all of those activities in no particular order. When the user is finished executing the activity (ies) the join is reached and the process proceeds. In essence, progress is sort of 'paused' while the user is executing the 'OR' activities.
Is this a correct interpretation? |
|
|
|
 | |
|
|
| Re: Activity Diagram: Decision or Parallel Activities? |
|
|
| vinny wrote
Sorry, let me make absolutely sure I get this:
In the example I provided, the user could actually perform some or all of those activities in no particular order. When the user is finished executing the activity (ies) the join is reached and the process proceeds. In essence, progress is sort of 'paused' while the user is executing the 'OR' activities.
Is this a correct interpretation? |
Yes - but let me clarify. In the absence of parallel flows, at any single point in the process there is only one activity/step being executed. The decision itself is a step since, in this case, the user must pick a path (make a choice). Until the user makes a choice the execution does not continue. Once a user makes a choice, the process continues with the next activity/step in the selected path. Again, until that activity is complete the execution does not continue.
That's why I like the BPMN way of thinking. If you think of the token traveling through the process flow, only the step(s) or activity(s) which have a token are actively executing.
FYI: in your example, you are referring to the decision point as an OR but would be better described as an XOR (exclusive OR) since only one of the subsequent paths will be used at a time (receive the token). I'm sure you already noticed that the diagram is modeled like a loop with the user having the ability to go back to the original decision and pick a path again.
- Adrian
Adrian Marchis
Business Analyst Community Blog - Post your thoughts! |
|
|
|
| |
|
|
| Re: Activity Diagram: Decision or Parallel Activities? |
|
|
| adrian wrote
I'm sure you already noticed that the diagram is modeled like a loop with the user having the ability to go back to the original decision and pick a path again.
|
Believe it or not, Adrian, I had not noticed that.  I guess now I'm wondering now why the "OR" was in there in the first place if only one of the events could occur at a time anyway. Seems sort of useless to me.
Thanks again for taking the time to help me, Adrian.
vinny |
|
|
|
| |
|
|
| Re: Activity Diagram: Decision or Parallel Activities? |
|
|
"...if more than one following activities can be performed at the same time (regardless of order) then you'll need to use the fork in the Activity Diagram."
This is confusing to me, unless I'm interpreting it incorrectly. If activites are performed at the same time, how can there be an order to how they're executed?
What I'm trying to show, essentially, is that at a certain point in the process it doesn't matter what order certain activities are executed; it only matters that all of them get executed. For instance, I come to a point when activities A, B, and C must execute in order for the rest of the process to continue. I do not want to imply that one must be done before the other; that is, the order of activity execution is arbitrary, just as long as all of them are executed.
So what I was doing was using a fork that branched out to all of the activities, indicating that all of them must be done eventually. I wanted to show that these are events that can not occur simultaneously, but all of them must be completed in order for the process to continue. So then I was bringing the transitions from each activity into a join, and then the process proceeds.
Am I not doing this correctly?
Thank you,
vinny
P.S. I would love to use BPMN for this, but the tools our organization are using are UML tools, and I have no control over that currently. I have to work with what I got. |
|
|
|
| |
|
|
| Re: Activity Diagram: Decision or Parallel Activities? |
|
|
| vinny wrote
"...if more than one following activities can be performed at the same time (regardless of order) then you'll need to use the fork in the Activity Diagram."
This is confusing to me, unless I'm interpreting it incorrectly. If activites are performed at the same time, how can there be an order to how they're executed?
What I'm trying to show, essentially, is that at a certain point in the process it doesn't matter what order certain activities are executed; it only matters that all of them get executed. For instance, I come to a point when activities A, B, and C must execute in order for the rest of the process to continue. I do not want to imply that one must be done before the other; that is, the order of activity execution is arbitrary, just as long as all of them are executed.
So what I was doing was using a fork that branched out to all of the activities, indicating that all of them must be done eventually. I wanted to show that these are events that can not occur simultaneously, but all of them must be completed in order for the process to continue. So then I was bringing the transitions from each activity into a join, and then the process proceeds.
Am I not doing this correctly?
Thank you,
vinny
P.S. I would love to use BPMN for this, but the tools our organization are using are UML tools, and I have no control over that currently. I have to work with what I got. |
OK... Sorry if I confused you... You are correct... That was what I was trying to say - once you model the activities as parallel (using the fork) order can no longer be enforced.
So let me rephrase (hopefully this will be clearer): There are times when you need to allow for multiple activities to take place at the same time. In this case you would use a fork in the Activity Diagram. The result of this is that you cannot impose an order/dependency among activities in separate branches that is they may or may not take place at the same time. What the fork specifies is that it's allowed for those activities to take place at the same time but that that is not necessary. What I meant by "... regardless of order ..." was that the actual order in which these activities get actually performed is irrelevant.
Now on to what you are actually trying to accomplish:
There is a bit of an issue with what you are trying to do and the decision of using the fork. If I understand correctly, you have two constraints: (1) ALL activities in question MUST complete in order for the process to continue beyond a certain point, and (2) the activities in question CANNOT occur at the same time.
Using the fork satisfies your constraint # 1 but it does not satisfy constraint # 2 since when you use a fork, you model parallel activities and, as you mentioned, there cannot be order. Therefore there is no guarantee that the parallel activities will not occur at the same time. As a matter of fact, the fork implies a high probability that they will be executed at the same time. So if you are using this diagram to tell the developer how to implement the system behavior, the interpretation would be that the system MUST be able to allow for these to be done in parallel.
One solution:
One way to satisfy both your constraints is as follows:
- Use a decision point (XOR) which allows the user to take one and only one path at a time
- When the paths merge, take the user back to the original decision point (XOR) and let me pick another activity to perform (you are now creating a loop)
- Make sure that one of your options in the original decision point (XOR) is a way to exit the loop AKA "I'm done, I don't want to make any more choices, and I'm ready to move to the next step in the process."
- Before you allow the user to go to the next step, you insert a validation activity which checks to ensure that ALL of the required activities have been completed,
- Then you put a decision (XOR) which uses the output from the validation: IF not all steps were completed then force user back to your original decision to pick a task ELSE they can proceed to the next task. FYI: many people will combine 4&5 into one step and simply model it as a decision.
Hope this makes more sense!
- Adrian
Adrian Marchis
Business Analyst Community Blog - Post your thoughts! |
|
|
|
| |