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 (
stephere 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
-
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
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 your opinions/experience on the usage of these diagrams in software engineering process?
I know methodology like XP which specifies its own practice in software development process. However, unlike Scrum where it focuses more on management aspects (which means you can still apply the BPMN/UML modeling into your work process), XP specifies software practices and requires you to follow, and eliminate the modeling process like BPMN/UML, and its practices if not apply properly will lead to issues like under documentation, incorporates insufficient software design….
I prefer the model driven way than XP. I guess it's up to the preference of companies and people. One of Agile goal is to "free developers from document works". Methodology like XP seems to easily lead to under documentation. I think to achieve that goal, the solution is to implement the tool to help developer reduce the workload on writing document, not by writing less documents, by gathering information from existing diagrams and automatically generate reports (in RTF, PDF, HTML in the case of Enterprise Architect of Sparx System). Another example is, people often complain about drawing diagrams consume their time. In my opinion, the solution is not to draw diagram, but the using the tool. Modeling tools today support round-trip engineering, where you can synchronize between your code and your diagrams, thus eliminates the extra effort to manually correct the diagrams if the code base changes (specifically, class diagram). What's your opinions/experience on this issue?
Best Answer
Usecase should be goal oriented tasks they are not single steps. The first example is a definite variation of the standard way to utilise usecases. I suggest map each usecase onto a single business process. This Sparx EA example maps usecase onto activities diagrams but does reveal the approach to use.