Demystifying Business Process vs Use Case Modeling

The other day I was part of an interesting discussion that started with the statement that there is a problem with OUM (Oracle Unified Method), or to be more precise the Unified Process being use case centric, while these days much development is based on business process modeling. The problem being that because of this people involved with business process modeling might think that OUM does not properly fit their needs.

I often hear people talk about use cases, and too often find out they actually do not know what a use case is. I’m convinced that anyone that does know both business process modeling and use case modeling, would not say such a thing as they would realize that a business process model is just another representation of the same thing.

Let me explain and convince you that OUM supports business process modeling quite well and does so for as long as it is there.

Now, I’m not going to explain what use case modeling all is about, but rather point you to the white paper. I wrote about that subject. However, what I probably do need to explain is that you can have use cases at different levels. My paper is based on OUM and the original work of Alistair Cockburn, who presents the following levels:



Before I continue I need to make the distinction between the conceptual notion "use case", being the interaction of an actor with a system to achieve a specific goal, and a "use case description", being a narrative description of that interaction.

The key point that I’m trying to make here is that a use case should be specified as a scenario. You might realize that at every level you can describe that scenario either by using a use case description, as an activity diagram or both, whatever suits your needs. And you might also be aware that at any level above the user goal use cases, an activity diagram actually is a description of a business process at some level. So there you are ...

What some of you folks that are into the Business Process Modeling Notation (BPMN) might not be aware of, is that UML activity modeling and BPMN just are two different schema techniques for doing the same task, as is clearly explained in a white paper by Stephen A. White. OK, granted, some patterns are more effectively handled by BPMN (like the concept of ad-hoc process to support the Interleaved Parallel Routing pattern), but that concerns minor details only.

So now I proved that a business process model and a use case description can describe the same thing, I hope with that you realize that the only thing you need to do to transform a business process model into a use case description, is by creating a narrative description out of that. But let me bring this academic discussion down to a practical level and discuss how to get from business process models to use cases. Otherwise, why bother, right?

Mind that narrating a business process results in a summary use case description. Many people not being aware that there are different levels of use cases, probably will use the notion "use cases" only to mean the user-goal level use case descriptions, a use-goal use case being defined as a use case for which the primary actor can go away happily after finishing it. If you are not aware of this it is likely you will have a hard time working with use cases. Just to warn you.

When going from business process models to user cases, you will be aiming at a model of user-goal use cases (and a couple of subfunction use cases going with that) as normally that should be the lowest level at which you capture requirements. Before you can do so, you need to make sure that the lowest level business process models contain activities at the level of user-goal use cases only. If that is not the case, fix that first.

Once that has been done you need to take just one more step from there. How you do that is up to you of course, but you could create a use case description for each activity in that diagram that is a candidate for being implemented and start detailing from there. Whenever useful, you can add an UML activity diagram to that. To prevent confusion, you probably better not use BPMN for that.