Behavioral Model of the System
We documented the behavioral model of our system in this document in the form of sequence diagrams. We created sequence diagrams based on the Structural Model of the System.
NOTE: To keep our diagrams simple, we omitted the calls to the database (data stores).
NOTE: To keep our diagrams simple, we omitted the calls to the log store. However, it should be assumed that all activity is logged properly.
NOTE: To keep our diagrams simple, we omitted the check whether the token the user presents is valid. However, it should be assumed that the user data manager performs this check when decodes the token, and if the token is invalid, rejects the request.
The user can create an account by choosing a username, and entering an email address and a password. The request is rejected if:
- The username is already taken
- The email is already used
- The password does not meet the policy
Otherwise the user account is created.
The user can login with either its username or email and the corresponding password. If the password matches the user successfully logs in, and the system generates token that will be expected of the user in subsequent requests in the session.
To modify the user data, the user has to present a token it authorizes itself with, and the modified user data. The user can modify its own data, or an administrator can modify the data of any user. However, the administrators cannot modify the email of users and cannot modify the password of users. Instead, the administrators are allowed to force-reset the password of other users, during which the user receives a temporary password in email which it can use for the next few minutes.
The get the data of a user, the user has to present a token it authorizes itself with. The user can get the user data, if it tries to get its own data or it is an administrator.
The get the logs, the user has to present a token it authorizes itself with. The user can get the logs, if it is an administrator, as the logs might contain sensitive data.
