Imagine the main system with the following use cases : one person may register, and book a room.
At the same time there is a mobile app which is derived from the main system which is enabling the same functions (register, book a room) with some added use case options.
How to distinct these two systems in a same use-case diagram?
The use case diagram shows use cases offered to actors by the system under consideration.
In principle it should not represent the technical distribution of functionality across processing nodes: this is for the deployment diagram.
The assumption here, is that you have only one system with potentially several front ends offering each a different set of use cases. You could then consider using two actors: user and mobile user. You could then:
mobile user can always do everything a user can do, you could represent an inheritance relation between both actors to avoid cluttering the diagram with too much duplicate links (even if this is not explicitly allowed, an actor is a classifier according to UML2.5 §18.2.1, and as illustrated here)Example:
If the common use cases shall exhibit some differences in features or in user interface, you could simply document this in the narrative of the use cases.
If however you want to show optional behaviors in the diagram, you could think of extending use cases. Extensions allow to show a variant to the normal flow and to document in a comment note the condition of such an extension to occur.
Keep nevertheless in mind, that UML use case diagrams should not be abused for functional decomposition. Lots of inclusions or UI specific extension could be a symptom of such abuse. So ask yourself if you really need this level of detail in the diagram.
If you have two systems that have to be considered as distinct from each other (for example if the booking system is operated by a third party), then you need distinct use case diagrams (one for each system).
In the diagram of the mobile app, you'd show the remote system as a secondary actor (and materialize its involvement in the use cases with additional links).
In the UML 2.5 specification, Figure 18.2 in section 18.1.5 is an example of what you want to do:
As you can see, you can show packages and subsystems, as necessary, on a UML Use Case Diagram. In your case, you likely wouldn't have the package, but you would have system boundary boxes identified and annotated as subsystems.
There are a few things to keep in mind:
Each Use Case diagram should show a system. If you have what is really two or more systems, you will want a use case diagram for each system. How you define what the "system" is versus what the "subsystem" depends on what you are building. You may want to define the software you are looking at as two systems or one system with at least two subsystems.
You may also be interested in a question about polymorphism in use cases and my answer to it. There are good methods for showing relationships between use cases that are part of the formal UML specification. There aren't ways to show relationships between actors, however, unless you don't care about following the specification.
