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
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.
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
BPMN process models and use-case models have very different purposes:
Process diagrams shows the succession of steps needed in a flow to achieve the process objectives. It specifies how a behavior works. The closest UML diagram is the activity diagram. There are even some studies that compare BPMN to activity diagrams, for example this one in terms of ease of use with business users.
Use-case diagrams focus on goals. It specifies why a user would want the system and what for. It is not meant for modeling process flows as there is no ordering between use cases. Some people misuse the notation, using «include» and «extend» arrows to suggest a flow, but this leads to flawed diagrams.
There is however a relationship between the two models: steps in a BPMN diagram are related to business user goals when designing a system that facilitates the business process.