5

I asked this question on stackoverflow, but it seems this question is not suitable there, so I post here for discussion.

BPMN (Business Process Modeling Notations) is used for modeling business process by visualization, thus making intangible ideas become physically concrete through the expression of BPMN diagrams. The question is, how do I organize the BPMN with the UML.

Initially, I thought of two ways to organize use cases and business process diagram:

  • 1 to one/many: By mapping each step (step here means each node in the BPMN digram) in the business process diagram with one or several use cases. Each use case is mapped with relevant several class diagrams/component diagrams (I prefer this one, since you can encapsulate a set of classes into one component which has input and output), several sequence diagrams (optional). After you have class diagrams/sequence diagrams, code is written/generated based on the model.

  • Many to one: By mapping several steps into one use case. The subsequence steps are the same.

  • Many to many: For example, one step in the business process can be mapped with two or more use cases, and the same two or more use cases can be mapped with other steps.

The above methods can be done by the modeling tool, and in my case, I use Enterprise Architect from Sparx System. I discover it recently and I am using its trial, but I will buy it in the future. I can organize many use case diagrams with one step of the BPMN diagram, and can click to view the necessary use cases. However, I don't if it supports many to many cases.

After thinking my own method for organizing BPMN and Use Cases, I searched the Internet, and found two other papers, each suggest the following method:

  • Turn each use case into each step of BPMN diagrams: To visualize how refined use cases fit into the business process. I like this approach, since the business process with steps can be modeled, and later each step is turned into a use case. One step is one use case. This is the same with my one to one mapping above. Original presentation is here: Visualizing Use Case Sets as BPMN Processes Use case - BPMN mapping

  • Each use case is exactly a business process: Each step in the use case is each step of the business process. Original paper is here: Describing Business Processes with Use Cases Use case is a process

It seems to me that there's not standardized way of gluing these artifacts (BPMN and Use Cases and other digrams) together. Maybe it's a management problem and rely more on creative usage rather than follow a formal steps. What are the usage of these diagrams together?

Christophe
  • 74,672
  • 10
  • 115
  • 187
Amumu
  • 824
  • 2
  • 8
  • 14
  • 3
    A discussion isn't suitable here either. What problem are you trying to solve here? If you really want a discussion then you need to post somewhere else. – ChrisF Jan 26 '12 at 11:05
  • 1
    The question is in the title? It's my problem I'm trying to solve. I just write the question in detail, so people can have enough information. Sadly, I think it's being viewed as just a "wall of text". Discussion is an obvious thing, because any question will involve discussion to finally select the answer, as you can see on every other questions. – Amumu Jan 26 '12 at 11:38
  • You are specifically asking for "opinions/experience" which invites discussion. Check the [FAQ] and the [How to ask](http://programmers.stackexchange.com/questions/how-to-ask) page. – ChrisF Jan 26 '12 at 11:42
  • Asking for opinions/experience means asking for answer with people's real life experience. If I trim down the word "opinion/experience", will it make the question better? Yes? – Amumu Jan 26 '12 at 11:58
  • Possibly. Try rewording the whole last section into a question. – ChrisF Jan 26 '12 at 12:05
  • This is a good question. It is complex. The two diagrams are for two different activities with different purposes. This makes the answer difficult. – NoChance Feb 18 '12 at 10:41
  • Why do you need this stuff in the first place? I hope it's just for documentation purposes. – Falcon Feb 18 '12 at 12:24
  • BPMN sub-processes are candidates for sea level use cases. A use case has scenarios, atomic BPMN tasks can't be decomposed further and therefore do not qualify as sea level use cases. – Etienne Aug 31 '17 at 19:50

4 Answers4

4

What's not clear is whether you're talking about Use Cases or UML.

Use cases:

With regards to use cases: with BPMN, you use those to develop the BPMN. In fact, to some degree, BPMN is meant to replace some of the use cases. Use cases are typically used to illustrate the business process to the developer -- but in this case, the business analyst/use case writer can put a lot of that "description" into the BPMN.

What's left over is maybe some detail about the BPMN process, which analysts can add in a document. But again, in that document, it needs to be clear that the BPMN is what's being described (and not that the BPMN is an addition to the text).

(This also depends on whether or not the analyst or the developer is writing the BPMN: if the developer is writing the BPMN, then obviously you need the use cases to help the developer define the BPMN -- but that's a little weird. In an effective organization, the business analysts know how to and can write BPMN and the developers can help double-check it. BPMN is, to some degree, meant to free developers from writing business logic code and get analysts to "write" it.)

The only use cases that should be left over should be cases that describe situations that are not fully covered by the BPMN. For example:

  • Web page or UI interactions
  • Technical use cases involving multiple systems
    • web service descriptions, for example.

The whole purpose of BPMN is to remove the business logic from your application (code). Use cases which describe business logic are often used to build business logic into an application. In short, if you're using both, you need to make rules about which one is the defining definition. (Otherwise, we get possibly conflicting descriptions of the same process/logic...)

UML:

With regards to UML: the BPM engine becomes an actor. Similar to how use cases should be used, it's important to not describe the same thing in both your UML and your BPMN. Otherwise, you may have two slightly similar but conflicting descriptions of the same thing.

Marco
  • 736
  • 5
  • 17
1

I think that this has strayed a bit from what use-cases are. Remember that use-cases and BPMN are two ways of modeling the same thing, but they are not necessarily meant to be literally translated. BPMN intends to provide a fully machine executable model. Use-cases to give a natural language explanation for a human.

If we look at the explanation of use-cases (for example in Use-Case Modeling (Bittner et. al.)), they are a dialogue between the system and actors, placing the requirements in context (by providing an example scenario).

This does present the problem that any particular use-case model might not cover the whole of the business, but just a sufficient amount of the business to explain the requirements.

So the closest thing in BPMN is not an activities, but the collaboration and conversations. The collaboration shows the interaction between pools/participants. (Check out http://www.omg.org/spec/BPMN/20100601/10-06-02.pdf.)

The BPMN Private/Internal process and activities tell us what the business internally does in response to receiving and input from a participant. It is analogous to building a sequence diagram with the analysis model boundaries, controls, and entities in the unified process.

The BPMN public process http://www.omg.org/spec/BPMN/2.0/PDF/ section 10.1.1.2 shows the use of a activities in an external process, but notes that internal activities are never shown.

In your diagram example, try breaking the Student out into its own participant. Model the students interaction with the university. Then in a different diagram, model the university's process that realizes each of the public activities.

Adam Zuckerman
  • 3,715
  • 1
  • 19
  • 27
Chris
  • 83
  • 3
0

Hope you question is answered in this blog article

On The Future of BPMN (Too)...

[5] BPMN replaces UML activity diagrams. Activity diagrams as currently defined in UML are deprecated and replaced with BPMN notations and semantics. BPMN essentially replaces a portion of UML behaviors.

[6] BPMN grows to make UML not required. BPMN grows to encompass all the capabilities required for business-focused modeling and architecture, thus making any integration with UML redundant. BPMN may, some day, replace UML.

[7] BPMN and UML are separate models, mapped with QVT. BPMN and UML are separate metamodels as they are now. A QVT mapping is specified between them such that a portion of a model in BPMN can be used to create a UML model and a portion of a UML model can be used to create a BPMN model. Since the notations are not the same, notations would not be mapped.

gnat
  • 21,442
  • 29
  • 112
  • 288
sridhar
  • 9
  • 1
0

Unfortunately it appears that everyone here has to correct everyone else. That isn't exactly helpful...

A fully dressed Use-case, or user-case as they were defined back in the early days of development, was not as robust as a BPMN diagram is supposed to be. This is why many like Alistair Cockburn and others from the IEEE Requirements Engineering group, blew them out. They needed to be more in-depth, have differing levels, and include the PPT (People, Processes & Technologies) to include the functional requirements. Unfortunately a use-case cannot show the same level of detail, nor can it include the data behind each data-driven element in functional BPMN modeling tool. They will in many cases say the same things; but the "model" is not just a model. Very few tools, including the older Rational TUP, used the verbal use-cases well, and they were difficult to tie to the Rose models and elements within. Einar Karlson spent a good bit of his career hooking those products' outputs together with SoDA.

It is sometimes easier and faster to start with user stories or the "way-too-in-depth business requirements" to flesh out the BPMN or the use-cases.

Patrick
  • 9
  • 2