For business process modeling, attach any number of sequence diagrams to the use case. Avoid activity diagrams unless you are describing procedural code (for example a class method at logical / physical level)
Hi Richard,
You seem to have a rather software centric view on things.
When we model business processes, we often don't even want to consider software, or systems.
A Use Case is a group of functionality that is to be automated (i.e. software), but business processes exist even without automation. (e.g. phone calls, paper documents, et...)
And frankly, if I wanted to validate my business process with the business, they would shoo me out of their office if I came to them with sequence diagrams.
Sequence diagrams are a very technical type of diagram, and are hard to understand by non-technical users.
Flow charts on the other hand is something they know and understand. BPMN looks a lot like flowcharts, so that tends to go a lot better.
Your remark about BPMN and Activity diagrams being not object oriented illustrates my point about the software centric view.
I can understand that your approach works for your environment, but modelling if often done for a much broader scope than just the software or systems.
Geert
Not so Geert Sir.
I've never worked in software development. My work is in Supply Chain - building new factories, moving logistics centers etc. I work with procurement managers, manufacturing managers, development managers, site managers and local government agencies.
I always use UML (as described in above post) to coordinate business process, contractual agreements and system changes between these parties. I start my workshops with 15 minutes training on the diagrams of the day (use case, sequence, class, component). The simple reason is that other languages (flowcharts, IDEF etc.) don't do the job.
Case in point: can you think about integrating the roles/responsibilities, contractual agreements and system data exchanges needed to support the R&R and contractual obligations between the Chongqing finance bureau and a german logistics service provider? Based on a few flowcharts from each? Good luck. But a good round of use cases with (1) actor definition, (2) sequence diagrams integrating the roles from each party, (3) how they exchange information to perform the contractual obligations, and (4) a class diagram (logical level) built from the sequence diagram did the job and ended up as attachment to the signed contract. This is just one of dozens of examples in my experience. (ps all done in Sparx EA! Yay!)
One of the sad reasons why UML failed is because big industry players pushed it as a programming language which never made sense (but it looked good in the management brochures). They were hoping to make money selling CASE tools that could generate better code than a guy sitting in front of a text editor. That never worked out (maybe 20 years from now with AI... possibly).
UML is great for talking to people with different backgrounds and integrating process-data-systems in a single model that can be changed easily. The big consultants are pushing flowchart-like languages for the simple reason that they can easily generate hundreds of powerpoints for the customers and bill lots of hours (been there, done that). These flowcharts are better than nothing but vastly inferior to a decent UML model.
The books, videos and talks about UML as a business modeling tool are out there: it works fine for me. If you are interested you can google my name + UML: you'll find a few invited talks at The Open Group and Data Modeling Zone.
Anyways, I'm for whatever works for you: my point is that there is always a better way to skin the cat.