What is the difference between a process model and a use case diagram?

Question

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

Answer 1

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.