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.
You could use Extend in this case.
Example include and extend:
UC “login” includes UC “sign up”: The login page can be accesses straight away, but if you haven’t signed up the alt path would lead you to the sign up page . You must complete this UC to get through. You can assess the sing up page directly as well. So for reuse you could make this two use cases, instead of an alt path and include the sing up UC.
UC “edit profile” extends UC “login”: The UC “Login” always has a pop-up when you login to ask if you want to change your profile. You don’t have to do this to accesses the site. You can accesses the profile edit page from several places, with its own UC of course. You would draw this relationship as an extend because its optional to get through.
Best Answer
I'm looking at what is currently the latest UML specification, the Unified Modeling Language v2.5, released in June 2015. It is specified in an English language specification and four XMI documents.
I think there are two things to consider to provide a complete answer.
The first thing to keep in mind is the difference between a "model" and a "diagram". Annex A defines models and diagrams. Elements, such as classes and nodes and associations and actors and use cases, are part of a model. Different models have different valid elements, which are described in the standard. Diagrams are graphical views of the model. A repository contains one or more models of a software system.
The second thing to consider is the usage of UML. UML is a language, a set of standard notations with defined meanings. Martin Fowler identified different UML modes, such as sketch, blueprint, programming language. Sketches and blueprints are designed for human consumption. They take advantage of the defined notations to reduce ambiguity in a diagram and make it easy to communicate ideas in a shared language. UML as a programming language is a mode designed to be consumed by a tool, such as for autogenerating code.
The combining of models is not allowed by the formal specification. The definition of an Activity model doesn't allow for the inclusion of elements such as actors, lifelines, and objects. You can see this in the XMI documents, or in Section 15 of the English-language standard. There's simply no concept of this.
However, when creating a diagram (either by hand or with a software package), there's nothing that precludes this. For example, Figure 18.12 shows a use case diagram that is associated with a state machine diagram. Tools may show these in different formats. I'd have to dig deeper to see if it's possible to link all of the diagrams that you mentioned, but it is possible to associate an element of one model with an element in a different model, so that the output diagram may contain visual representations of multiple models in one view.
Annex A specific supports this: