0

I am working on an attendance system app for my graduation project. In short, basically the instructor generates QR codes every day for each class using an API, and a student scans it and their attendance status will be set in database.

However, since the API generates the code, I was wondering: should I add a secondary actor called 'system' to represent the API?

Also for the login, system is supposed to have a basic 2FA mechanism and I was wondering if what I did here is correct?

attendance system use case

Christophe
  • 68,716
  • 7
  • 72
  • 138
Sam Nakity
  • 1
  • 1

2 Answers2

0

should i add a secondary actor called 'system' to represent the API?

The way you have modeled it, you imply that there is yet another software called "system" which provides the QR codes to the software that you design.

That is probably untrue, therefore remove the actor "system".

All the use cases on the right-hand side are functional decomposition. Don't do that. It is not the purpose of a use case diagram.

The use cases on the left-hand side are good (except "login", see my separate comment)

observer
  • 2,925
  • 1
  • 19
  • 38
0

The following elements are keys of successful use-case modelling and can be directly derived from the UML 2.5.1 specifications (p639 and 640):

  • A use-case specifies a set of behaviors offered by the subject (system), with an observable result that is of value for the actors, and without reference to the system's internal structure
  • An actor is outside the subject (system).

If the QR code is generated by the same system, you MUST NOT have a System actor: the system is not outside of itself. The QR code generation would just be part of the offered set of behaviors.

If the QR code is generated by another system, it depends:

  • if the other system is just an auxiliary one that is required by the internal structure of the system, but that is not relevant to the users, you SHOULD NOT show it as an actor;

  • if the other system is an independent system, and in particular if 1) it could be replaced by a human operator; or 2) its existence is relevant for the business stakeholders (e.g. a weather system, a stock quotation system, ...); or 3) your system helps that other system to achieve its goals; then you COULD show it as an actor (even SHOULD in the case 2).

More generally, there is some controversy around login use cases (detailed explanation of the opposing point of view : here). I'd advise not to use it. But if you, remove Verify (this is an action performed by the system, and not something that is of value for the user), remove Bad password (this is an event that will trigger some action, but definitivierly not something that the users avalue). Finally, if it's a password login, an SSO login or a MFA login does not matter: all tehrse are just means to achieve the goal. Let these kind of details for the description of the login scenario.

Keep also in mind that there is no sequencing between use-cases (this is one more reason why it's not a good idea to have a login use-case).

Christophe
  • 68,716
  • 7
  • 72
  • 138