4

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.

  • Have a look here: scrum.org/Forums/aft/1472 – Erik Eidt Nov 18 '16 at 17:57
  • I agree that hardware is a legitimate actor, but interrupts, events and the like are implementation details. – Robert Harvey Nov 18 '16 at 19:21
  • I have removed the comment because I didn't want it to lead to false assumptions. After reading Christopher's answer I understood why Robert Harvey cataloged interruption as implementation details. It make sense. – Laiv Nov 18 '16 at 20:14
5

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.

enter image description here

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).
  • I have never heard of that left-primary/right-secondary rule :-/ I always used stereotyped associations (e.g. <<use>>) or un-/directed associations to distinguish both. – qwerty_so Nov 18 '16 at 23:41
  • @ThomasKilian Not a rule, more a common practice. I've seen it quite often. I don't know its origin, but I have a pocket memento and other references that states it (e.g. this book, or this paper or SO ) – Christophe Nov 19 '16 at 0:32
  • One never stops learning :-) At least I see my practice also used in the SO answer you cite. – qwerty_so Nov 19 '16 at 8:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.