Just recentlly I was about to hold release planning workshop with domain experts of the customer. And to my huge surprize this customer were prepared! They made diagram that displayed current process. And I must admit I liked it.
I am using word “flowchart” to denote way my customer prepared their diagram because it displayed mixed flow of control and objects plus some additional support information. Sure there is similar diagram in UML – activity diagram. I find though activity diagrams quite difficult to explain for someone who is not familiar with UML. Yes, you can teach your customer UML, but what if he is not interested or willing to. What if there is actually alternative and more or less equal ways to display same information without having to learn UML.
Check out the flowchart of my customer (I beautified and modified it ofcourse):
Well, original diagram was even simpler since it didn’t had object flow. I added object flow to the diagram by reflex and now am too lazy to delete it. I think you will still get the point. And the point is – besides simplified display of activities, there are two additional areas on the both sides of diagram that let you
1. much better understand who is having the ball at the moment
2. adds relevant information without cluttering diagram
Yes, it is possible to display same information using activity diagram, e.g. like this:
My opinnion is – the UML-compliant version of diagram is cluttered, responsibilities not as clear as in first version, if activity is shared by two actors (like “agree on delivery conditions based on availability”) – for me a question pops up if placing activity on the border between two swimlanes is formatting error or intended. Additionally, I think that additional information in notes is not as prominent as it is in the first, non-compliant diagram. Finally, I should’ve ben adding third swimlane for final node since it is being executed by someone else and not purchasing agent.
Sure the differences between two diagrams above are not that huge. But I think that when it comes to acceptance of one or another modeling methodology the devil is in the detail. So I say, for the sake of your customer and productive joint effort, feel free to give up formalism and concentrate on enhancing understanding and readability versus trying to hold on to standard.