Use case diagram for overriding settings?

Question

I have a fan in a room. The fan has two speeds 1,2,3,4,5. 1 is slowest, 5 is fastest. The speed of the fan depends on the temperature.

These are my regular settings for the fan: if temp is cold - speed = 1, if temp is normal - speed = 2, if temp is hot - speed = 3

Suppose someone else wants to use my room when i am out. He wants to change the speeds as shown: cold = 2, normal = 3, hot = 5

For this system, I made a use case - setFanProperties which lets ME set fan speeds according to MY needs.

I want to make a use case for regular settings and one for overriding these regular settings. Don't ask me to change my system. I MUST have regular settings and override settings use cases in my system.

How do i do it? Should i extend setFanProperties use case? If it is okay, then can I make overrideFanProperties use case an instance of setFanProperties use case?

EDIT -

I want my system to work such that if there is an override, then change the settings as per the overriding person. the moment the person vacates the room, use regular settings.

Given this new information, would extension still be the best choice?

Here is my diagram so far -

Answer 1

I think so. The use case setFanProperties would configure the system with the regular settings and provide an extension point that can be associated to overrideFanProperties, which extends setFanProperties.

UML 2.4.1 says that if the condition of the extension is true at the time the first extension point is reached during the execution of the extended use case, then all of the appropriate behavior fragments of the extending use case will also be executed. If the condition is false, the extension does not occur. Then, if the "override" condition is false, overrideFanProperties use case is not executed and the default settings will be applied, but if the condition is true, then overrideFanProperties will be executed, effectively overriding the default settings).

(BTW, use cases are classifiers, so I don't think that a use case may be an instance of another, in the same way that a class is not an instance of another class).

Edit:

The UML standard says that "the condition of the relationship as well as the references to the extension points are optionally shown in a Note attached to the corresponding extend relationship."

The condition is a Constraint (which may be expressed in either a natural language, or a formal language such as OCL). The "reference to the extension point" is just the name of the extension point. (of course, the level of detail depends on what you are modelling and who is your intended reader).

The description of the locations of the extension point is given in a suitable form, usually as ordinary text (...). In this example, I chose attaching a note to each use case, detailing their behaviors (and where the extension point may be executed). You could write it in any way that you use for documenting your use cases.