2

When using bpmn to specify a process model. And using UML to specify a use case diagram. Don't they both describe processes? What's the difference between the two?

I'm reading a course which states:

A process model makes the processes in which the system is used readily understandable, but does not hold enough detail to develop a system

A use case diagram denotes the interaction between a system and its users and the hierarchical relation between functionalities of the system

6
  • The difference seems apparent in the descriptions. One refers specifically to users and hierarchical relations, the other does not. Jan 9, 2017 at 19:53
  • Have you looked at a BPMN process model and a UML use case diagram side by side?
    – Thomas Owens
    Jan 9, 2017 at 19:54
  • Process model, Use Case diagram Jan 9, 2017 at 19:57
  • 1
    @ThomasOwens yes to me it looks like in bpmn you can write out a complete process from start to finish. While in uml use case diagram it just looks like you are summing up use cases/processes (without going into them further)
    – Vincent
    Jan 9, 2017 at 19:57
  • That seems like a reasonable summary to me. Jan 9, 2017 at 19:57

2 Answers 2

6

BPMN is a profile which extends the UML language for a certain domain. Like with natural language you have a different wording to express things. And sometimes the same phonemes even have different semantics. So you need a bit of care when using both languages the same time.

BPMN is different to use cases as it focuses heavily on functionality. It has lots of new words that can describe how things interact. Use cases in contrast primarily aim to describe the added value, a system delivers to an actor. So that's something very, very basic. Use cases also have means to express how process steps are executed (using Activities and Actions). You find the same in BPMN and for the very same purpose. But, where Use Cases end, BPMN will start. So it's a good idea to gather the added value with use cases and then use BPMN in the following phases to describe how scenarios in use cases can be mapped to business processes (means order of actions in activities).

It is noteworthy that UML is not about diagramming, since this is mistaken by many people. There are a couple of different diagrams defined in the UML 2.5 spec for certain sub-domains. So you can expect a set of elements to appear in specific diagrams. But that's not mandatory. You can mix any elements if it helps communication the model (which is what holds the semantic). The diagrams are just meant to help people understand the model. So UseCases as per spec are (p. 637)

a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified in this clause are Actors, UseCases, and subjects. Each UseCase’s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors.

A UseCase is a specification of behavior. An instance of a UseCase refers to an occurrence of the emergent behavior that conforms to the corresponding UseCase. Such instances are often described by Interactions.

And you will find the previous elements most likely in Use Case diagrams. However, you are free to mock them up where needed. So mixing BMPN (or elements from other profiles) is absolutely possible.

From the annex (p. 683):

NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced.

0

Business processes are typically method agnostic. I.e. they do not, or atleast, should not specify the method(system) used to execute a process step. The same may, and should, be said of a Use Case, however, in my experience Use Cases are not typically generalised to "system" and instead explicity state the system in use.

From a design perspective, I would

  1. Establish future state business process
  2. Determine activities in process which must be enabled by software
  3. Determine what actors will interact with software, and what goals they seek to achieve (in relation to the parent business process activity)
  4. Model the Use Case Diagram
New contributor
Sukhdev is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.