Consider a scenario as such:
A university ABC allocates 2 lecturers to a course (a main lecturer and a substitute lecturer). The job of the substitute lecturer is to conduct lectures whenever the main lecturer cannot attend. Thus, both lecturers need not be present at the same time to conduct a lecture.
How do I show that either the main lecturer or the substitute lecturer offers lectures at a time?
What I drew :
However, the idea depicted in the scenario isn't consistent here because, at the same time it is possible for both lecturers to offer the lecture.
How do I correct this?

- 68,716
- 7
- 72
- 138

- 139
- 1
- 9
-
there is no way to depict your scenario using just the diagram. You have to add in your assumptions to make it clear. – Vincent Dec 14 '21 at 04:09
-
1How about a general lecturer that is either main or sub? – Jim L. Dec 14 '21 at 04:55
-
You can describe such conditions always using constraints (plain text or OCL enclosed in `{}`). – qwerty_so Dec 14 '21 at 09:02
2 Answers
Whether you associate two distinct lecturers to the use-case or one lecturer with a multiplicity of 2 does not make a difference here. The UML specifications let the case with multiple actors completely unspecified:
UML 2.5.1, page 640 (highlighting is mine):
When a UseCase has an association to an Actor with a multiplicity that is greater than one at the Actor end, it means that more than one Actor instance is involved in the UseCase. The manner in which multiple Actors participate in the UseCase depends on the specific situation on hand and is not defined in this specification. For instance, a particular UseCase might require simultaneous (concurrent) action by two separate Actors (e.g., in launching a nuclear missile) or it might require complementary and successive actions by the Actors (e.g., one Actor starting something and the other one stopping it).
Here some possible solutions to refine your model:
- Show an
{xor}
constraint between the two lecturer associations. - Add a comment box anchored to the use case in which you explain it in plain-text.
- Laeve the diagram as is and describe the requirement in the textual use-case description.
Additional comments, not related to your issue:
- If the number of students has no upper bound, use
*
instead ofM
. Use a number if its specified in the text. - Main lecturers and substitute lecturers are both full lecturers, and the choice only depends on the availability, isn't it?

- 68,716
- 7
- 72
- 138
As commented I would always go down to the actual role. I don't have a good name at hand, but in your case it would be Lecture offerer
. That's the one which is linked to the Offer lecture
use case.
Now the other 3 actors you showed can simply inherit from that actor above via a generalization.
Any constraints about concurrent access are best kept in requirements, constraints and finally in the flow of events describing the many scenarios that come up. Requirements and constraints should not clutter the simple UC diagram. Instead you create different diagrams that take care of them. The main focus of UC diagrams is to show the added value.
And as always I recommend to read Bittner/Spence about Use Case Modeling.

- 35,448
- 8
- 62
- 86