I'm writing driver-level code that runs on a microcontroller. I've described some of the design with use cases. The users in my use cases are the the other software components that use my driver. However, I also receive input from the hardware itself in the form of interrupts. How do I describe those interrupts in my use cases? Is the hardware itself another user? Do I describe the interrupts as exception cases in my existing use cases instead? That may be difficult since some of the interrupts are asynchronous and may happen at any time during any use case.
The system under consideration in your model seems to be your microcontroler with your driver.
The actors interact with this system under consideration. They are of two kinds :
- primary actors: they use the system to achieve their goal. They are often represented on the left side of the diagram. Here, it's the software components that use the driver.
- secondary actors: they are other actors involved in a use case. They are usually represented on the right side of the diagram. Here it's the hardware.
I have the impression that the interruptions are not specific to the one or the other use case, and therefore shouldn't be represented as an extension or an exception to them.
If you want to represent interruption, you'd rather go for a distinct use case. I wonder however if it's necessary at all:
- the interruptions do not represent a goal for any of your actors
- the interruptions are not created by the external hardware, but by your own system (i.e.microcontroller response to an input signal), so it seems to be rather an internal implementation detail of how some interactions are handled.
- the logic of interruption and their timing could better be represented using other behavioral diagrams (e.g. an activity diagram with an interruptible activity region).