Wednesday, October 24, 2007

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.

12 comments:

西明的春天 said...

Thanks for sharing your thoughts. It's great.

To business, they could go either way: business process modeling or use case modeling.

But the question is whether the business process modeling is more suitable for Service-Oriented Architecture? On the other hand, use case modeling is good at component-based, model-drvien architecture?

Any comments?

Thanks,

Jan Kettenis said...

I don't think the determining factor is SOA versus component-based, model-driven architecture. After all, in the latter case you could start with business process modeling. It probably is more a matter of what people are used to.

And in many SOA project there are plenty of user-goal use cases that are better captured using a use case description than a diagram, because diagrams offer little to no means to express other aspects than just only a flow.

Granted, being a schema technique business process modeling seems to make it easier to go from a model to an implementation, like from BPMN to BPEL.

As often, it depends. Use what suits you best. As long as you a aware that both techniques are just different representations of the same, you can easily switch from one technique to the other when appropriate.

Anonymous said...

When use case modeling was introduced by Ivar Jacobsen, the vast majority
were rightfully confused as to how and what a use case actually was.
Alister Cockburn work was fundamnetal in adding some level of precision and
his attempt to categorize use case levels was a big step in the right
direction.

The name use case refers to the set of all possible use case scenarios for that
given use case. Any scenario or instance of that use case can be also called a
use case description and depicted in an activity diagram. Hence the confusion,
especially if english is not your native tongue.

I agree that "narrating a business process results in a summary use case description."
However, another important difference that comes to mind is the fact that while a use case
title will be used for low level features it will also be used to name a business process.

While a feature does not add business value for the stakeholder a business process is
required to do so. From an application development point of view, "SearchTerm" is more than
just a feature for any search engine that wishes to compete with other search engines. However,
to search for something in most application is just a tiny feature hardly giving any business
value in most applications.

A second thing worth mentioning is that use cases are simply listed in a brainstorming
attempt to create an overall view of the essential goals. Business processes are typically
sequentially placed in relationship to each other. So as you may compare a
scenario/use case description (which can be described either with text or with an activity diagram)
to a business process, it is in my opinion incorrect to equate a use case to a
business process. Understanding the difference between a use case, a scenario and use case levels
is the key for not making this mistake.

Claudia Frers, IT Architect Devoteam

Des Plante said...

I like to start modeling the business goals and business use cases (what an external actor could do with the business).

Each business case is described with a business process to accomplish the associated goal.

Some steps int this business process will be invocation of automated services, and others will be human tasks. Then, human tasks become use cases (user goal level).

If using a BPM engine, the user interface (boundary) for each use case will sure be one-to-one (eg. one set of task specific web pages per use case). If not, designers could come up with a user interface composed by the boundary of many use cases.

So, I don't feel I have to choose either business OR use case modeling. Am I missing something here?

Comments welcomed!!

Anonymous said...

I'm not suggesting this is right but for me it draws a parallel between Business Process diagrams and Use-cases and shows how they compliment each other...

I always see BPMN diagrams as a great way to start out. I start fleshing out the Business Process and don't take too long on it because I'm keen to start to consider the Use-cases model (the goals).

The Business Process and Use-case may be a one-2-one match between process and goal or the Process may break down into more than one goals.

After a few iterations of this I start to elaborate the Use-case model goals with Use-case specification(s) (the steps).

While I'm doing this I'm considering and capturing the business rules and non-functionals.

However, I'm likely to discover that there is something I've missed in the Process I started out with so I refactor it.

In effect the BPMN diagram is representing the Business Use-case while the Use-case model and specifications are fleshing out the system use-case.

I hope this make sense? As I say, might not be a perfect approach so I'd welcome any thoughts/comments...

Jan Kettenis said...

@Claudia:

I'm curious why you would say: "While a feature does not add business value for the stakeholder". What would otherwise the rationale be of implementing a feature if it does not add business value to the stakeholder? What is your definition of a feature? Some say use cases are features, but I suppose not every feature is a use case. IBM recognizes the requirements pyramid (not sure what the origin is), consisting of needs - features - use cases - scenarios - test cases, making a distinction between features and use cases.

Without elaborating on it, I rather avoid using the word "feature". For the sake of keeping it short, I also avoided mentioning the difference between a /business/ and a /system/ use case.

I must admit that from what I write it may be hard to recognize, but I also did not try to suggest that a use case is equal to a business process.

What I did try saying is that (depending on the scope) they can represent the same thing, meaning that both a business process and the use case scenario (or set of scenarios to be very precise) of a summary use case represent a "business process".

Unfortunately we currently do not make a difference between /business/ processes (that abstract from systems) and /system/ processes (that do take systems into account). In this context a /system/ process would be something that you can implement with a BPM tool like the Oracle BPM Suite.

Otherwise you could say that summary (system) use cases represent the same thing as /system/ processes. What is the same is that the description of the summary use also would show how the lower level use cases are tied together.

But in my opinion this starts to become too academic. Progressive insight tells me that in practice you probably use business processes to tie user-goal use cases together. In this way business processes are the higher-level things "above" the use cases.

Jan Kettenis said...

@Des & Allen:

What you say makes perfect sense to me. I suppose my previous comment (especially the last section of it) will tell you why.

أبل said...

now i believe that you are professional

mainlymilitary said...

I absolutely match with your post.

Anonymous said...

good
Cara Menghilangkan Kutil di Batang Kemaluan
Cara Menghilangkan Kutil di Batang Kelamin
Cara ampuh Menghilangkan Kutil di Batang Kemaluan
Cara alami Menghilangkan Kutil di Batang Kemaluan
Cara tradisional Menghilangkan Kutil di Batang Kemaluan
Cara Menghilangkan Kutil di Ujung Kemaluan
Cara Menghilangkan Kutil di Ujung Kelamin
Cara alami Menghilangkan Kutil di Ujung Kemaluan
Cara herbal Menghilangkan Kutil di Ujung Kemaluan
Cara ampuh Menghilangkan Kutil di Ujung Kemaluan
Cara Ampuh Menghilangkan Kutil di Kemaluan
Cara Ampuh Menghilangkan Kutil Kemaluan
Cara Menghilangkan Kutil di Kemaluan
Menghilangkan Kutil Kelamin
Cara Alami Menghilangkan Kutil di Kemaluan
obat untuk menghilang kutil yang ada di kelamin
obat untuk menghilang kutil
obat untuk menghilang kutil kelamin
obat untuk menghilang kutil kemaluan
obat alami untuk menghilang kutil yang ada di kelamin
Obat Untuk Menghilang Kutil yang Ada di Kelamin Pria
Obat Untuk Menghilang Kutil
Obat ampuh Untuk Menghilang Kutil yang Ada di Kelamin Pria
Obat Menghilangkan Kutil
Obat alami Untuk Menghilang Kutil yang Ada di Kelamin Pria
Obat Untuk Menghilang Kutil yang Ada di Kelamin Wanita
Obat Untuk Menghilangkan kutil
Obat Untuk Menghilang Kutil yang Ada di Kelamin
Obat Kutil yang Ada di Kelamin Wanita
Obat alami Untuk Menghilang Kutil yang Ada di Kelamin Wanita
Obat Untuk Menghilang Kutil yang Ada di Kelamin Laki-laki
Obat Untuk Menghilang Kutil yang Ada di Kelamin
Obat Untuk Kutil yang Ada di Kelamin Laki-laki
Obat Untuk sakit Kutil
Obat alami Untuk Menghilang Kutil yang Ada di Kelamin Laki-laki
Obat Untuk Menghilang Kutil yang Ada di Kelamin Perempuan
Obat Untuk Menghilang Kutil yang Ada di Kelamin
Obat ampuh Untuk Menghilang Kutil yang Ada di Kelamin Perempuan
Obat Untuk Menghilang Kutil
Pengobatan Untuk Menghilang Kutil yang Ada di Kelamin Perempuan

herbalku ampuh said...

THANK'S
Obat Untuk Penyakit Kondiloma Akuminata Kutil Kelamin Manjur
Merk Obat Untuk Penyakit Kondiloma Akuminata Kutil Kelamin Manjur
Obat Kapsul Untuk Penyakit Kondiloma Akuminata Kutil Kelamin Manjur
Obat Untuk Penyakit Kondiloma Akuminata Kutil Kelamin Yang Manjur
Obat Tradisional Untuk Penyakit Kondiloma Akuminata Kutil Kelamin Manjur

Unknown said...

Kemaluan Pria Sakit Keluar Nanah Untuk mencegah penyakit ini, hindari hubungan seksual yang tidak aman seperti hubungan seksual tanpa kondom, seks bebas, atau bisa juga menular melalui jarum suntik. Pengguna narkoba juga berpotensi tertular penyakit ini dari jarum suntik yang mereka gunakan. Kemudian, untuk ibu hamil, baik bagi mereka untuk memeriksakan apakah mereka mengidap kencing nanah. Ibu hamil yang menderita kencing nanah bisa menyebabkan kebutaan pada anaknya. Bakteri gonorrhea bisa menyerang bagian putih pada mata yang menyebabkan kebutaan. http://herbal789.tumblr.com/post/136783495960/kemaluan-pria-sakit-keluar-nanah Dari Penis Mengeluarkan Cairan Seperti Nanah Infeksi bakteri Neisseria gonorheae yang menyerang bagian teggorokan disebut penyakit Faringitis Gonokokal yang mempunyai gejala susah menelan karena adanya rasa sakit pada tenggorokan. Infeksi bakteri juga bisa terjadi pada bagian lapisan putih mata yang disebut dengan istilah Konjungtivitas Gonore. Mata yang bengkak dan keluarnya cairan nanah dari mata adalah ciri-ciri yang dapat dilihat secara nyata oleh kita. Jika infeksi pada mata ini tidak segera ditangani secara medis, maka dapat menyebabkan kebutaan permanen. http://blogherbaldenature.blogspot.com/2016/01/dari-penis-mengeluarkan-cairan-seperti.html
Penyebab Kemaluan Sakit Keluar Nanah Penyakit gonore atau kencing nanah bisa menyerang siapa saja. Tidak peduli pria maupun wanita, tua ataupun muda, semuanya memiliki peluang yang sama untuk terkena penyakit ini. Bahkan bayi yang baru lahir pun bisa tertular penyakit ini ketika mereka dilahirkan. http://herbal789.pbworks.com/w/page/104037463/Penyebab%20Kemaluan%20Sakit%20Keluar%20Nanah Dari Penis Mengeluarkan Nanah Kental Terkena penyakit memang merupakan suatu hal yang tidak meyenangkan. Kita akan merasa tidak nyaman dengan kondisi tubuh sehingga aktifitas pun akan terganggu. http://denature222.blog.planetbiru.com/?id=8876
Penyebab Kelamin Pria Sakit Keluar Nanah Selain bisa menyerang siapa saja, penyakit gonore ini juga bisa menyebabkan beberapa komplikasi jika tidak segera ditangani. Radang sendi, infeksi jantung dan munculnya bintik-bintik merah bernanah di kulit hanyalah sebagian dari komplikasi yang muncul akibat lambatnya penanganan penyakit ini. http://obatherbal789.blog.fc2.com/blog-entry-586.html Penis Mengeluarkan Nanah Kental Dari banyaknya masalah kesehatan yang ada, kencing nanah adalah satu jenis masalah kesehatan yang cukup berbahaya karena penyakit ini bisa menyebabkan kebutaan pada penderitanya jika bakteri yang menjadi penyebab penyakit ini sampai pada bagian mata. http://herbal789.tumblr.com/post/137790800375/penis-mengeluarkan-nanah-kental