The users must register or identify themselves before using services offered by the system.
Characteristics: Common. Some blueprints are basic, whereas others are advanced.
Keywords: Password, PIN code, user authorization, user identification, user identity.
The Login and Logout: Standalone blueprint consists of two use cases. The first use case, Login/Logout, models the login and the logout procedures; that is, it models how a user is to register as well as deregister as a current user. The utilization of the other use cases in the system is independent of the actual procedures for registering and deregistering. Those use cases in the system that require the user to be logged in before using the service state this as a precondition. The second use case, Manage User Information, registers and deregisters user identities and their passwords.
This blueprint captures the case where the general login (and/or logout) procedure is extended with system-specific actions to be performed when a user logs in or logs out. These actions are described by a separate use case that extends the Login/Logout use case.
In the Login and Logout: Reuse blueprint, the login and logout procedures are modeled by a separate use case that is included by all other use cases requiring user identification.
Another variant is to model the login procedure, followed by a general service performed by the system, and then the logout procedure, together in an abstract use case. Then, all use cases modeling services of the same kind can be expressed as specializations of that use case.
When every usage of the system is a specialization of a generic use case that includes the login and logout procedures, this is the preferred blueprint. The advantage of this alternative is that the login and logout procedures are described once in the parent use case and that the similarity of the child use cases becomes explicit in the model.
In several systems, it is a requirement that the user is logged in before any of the services of the system can be used; that is, the users must identify themselves by providing some kind of identity and secret key. A few different models of the login procedure to a system are available; in some of them, a relationship is modeled between the login use case and the other use cases of the system, whereas in others the use cases are kept independent. Sometimes it is not necessary to model a login use case, but often an explicit login use case is required. How dependent the other use cases in the system are on the login procedure determines which of the blueprints to apply.
The first question to ask is whether the system's services—the other use cases—are independent of the actual login procedure. If they are independent, there is no include or extend relationship between the login use case and the other use cases (see Figure 31.1), and the Login and Logout: Standalone blueprint is applicable. Here the performance of a login procedure is modeled as a separate use case, which, after verifying the correctness of the password, enables the set of services the user can choose between (usually they are also presented to the user) and then the use case ends. If the allowed set of services depends on the user's access rights, the corresponding selection must also be included in the login use case.
Figure 31.1. If the use cases are independent of how the login procedure is performed, there are no relationships between those use cases and the Login use case.
To state that a user must be logged in before a use case can be used, we can provide a precondition of the other use cases stating that the user must be logged in. However, remember that if the system is to check whether the user is logged in each time a use case is performed, this check must be included as an explicit part of the flow in that use case. If such a check is not to be performed, the GUI designer (or similar) must ensure that the precondition is fulfilled by making it impossible for a user that is not logged in to initiate the use cases (see also Chapter 26, “Use-Case Sequence”).
Include or extend relationships between the other use cases and the login use case are not to be used because they would state that the other use cases are dependent on the login use case or vice versa. Furthermore, they would then be performed as one flow, but in this case the login procedure is not considered part of the other use cases, and the other use cases are not considered parts of the login use case.
In some cases the login procedure is to be extended with additional actions. For example, in some systems all failures of login are logged, so that the system administrator can analyze possible attempts to break in to the system.
If there are any such application-specific actions to be performed when the user logs in to the system, these actions should be expressed in a separate use case that has an extend relationship to the login use case, as is shown in Figure 31.2. We define an extension point in the login use case where the extension is to be made. In this way, the login procedure can be realized in different ways depending, for example, on the security management system of the computer the application is running on, while the application-specific part can be handled separately. This is the case modeled in the Login and Logout: Action Addition blueprint.
Figure 31.2. When a user logs in to a system, the standard login procedure is performed. During the login, the system checks whether there are any unread messages for the user and, if so, sends a notification to the user. This check is modeled in a separate use case extending the Login/Logout use case. See also Chapter 32, “Message Transfer.”
The application-specific parts must not be modeled as a concrete use case because it will not be initiated by an actor. It is the performance of the login procedure that causes the extension to be performed. Moreover, do not include the application-specific parts in the description of the login use case, because this would dilute the description of the application-specific behavior with the description of the login procedure, which most stakeholders are not interested in.
If each usage of the system must verify the identity of the user, the login procedure will have to be included in every use case, as in the Login and Logout: Reuse blueprint. A typical example is an ATM machine where the user must be identified each time the machine is used. In this case, we describe the login procedure as a separate use case to which all the other use cases have include relationships (see Figure 31.3). In this way, the login procedure is described only once, and each time a new service is added to the system (or removed), this new use case states that it will use the login procedure by including it, without having to change the login use case.
Another possibility, which is preferable when all the application use cases are of the same kind, is to define a transaction use case that includes a general description of how a transaction is performed together with the login and the logout procedures (Login and Logout: Specialization). Each application use case will have a generalization to the transaction use case and only specify how its specific transaction is performed (see Figure 31.4). The other parts of the transaction use case, including the login procedure, are inherited. The advantages of this structure are that all application use cases will automatically include the login procedure as soon as it is stated that they are transaction use cases, and that the similarity of the application use cases becomes explicit in the model. However, as stated previously, this requires that all the application use cases be of the same kind as this is a universal requirement for using a generalization in UML.
Figure 31.4. When several system usages are of the same kind, the login procedure can be modeled as part of a parent use case.
Neither of these two techniques should be used unless the login procedure is to be performed each time the application-specific use case is performed. Otherwise, even if it would be possible to enclose the login procedure within a condition (a guard) in the application-specific use case, every reader of the model would misunderstand such a model. Furthermore, the use cases would be more difficult to realize and implement.
You can find examples of these two techniques in the Chapter 7, “Include: Reusing Existing Use Cases,” and Chapter 11, “Use-Case Generalization: Classification and Inheritance.” Chapter 13, “Describing Use Cases,” covers how they are to be documented.
Many applications do not specifically require a login procedure. It is just assumed that after you have logged in to a computer where the application is installed, the application will be available. In this case, we do not include a login use case in the application. We need not even describe it in a precondition of each use case. Because the application itself does not need the information about the user, it should not be included in the model.
Obviously, we must include the login use case in the model if some of the use cases of the application have to know the identity of the user because it might confuse a reader of the model if the user identity is found in the system while the identity is never established in any of the use cases. However, the realization of this use case is often quite simple: It is already provided by the operating system on which the application is to run, and the user's identity can be requested from the operating system. In the use cases needing the user's identity, we simply state the following:
Because it is a design matter, we need not say from where it is retrieved.
Most systems require not only that a user log in to them but also that the user log out from them when finished. Therefore, if there is some kind of login use case, a logout use case will also be necessary. Both of the login and the logout procedures can be modeled within the same use case. This use case, called, for example, Login/Logout, will have two basic flows, because neither procedure is an alternative of the other.
We should not model login and logout as two separate use cases, as in the Login and Logout: Separate blueprint, unless the descriptions of the two procedures are quite large (or if a stakeholder insists on separating them). Both procedures will use the security mechanisms of the system. Moreover, separating them would increase the size of the model and make it more difficult to understand without really adding anything of value to the model. The two procedures form one conceptual unit: It is very seldom that one of them, but not the other, will be needed in our model.
In a system utilizing a login process, it must be possible to register and deregister user identities and passwords. This information is used when checking the information provided by the user when trying to log in to the system. The management of the user identities and passwords must also be expressed in the use-case model. The use case Manage User Information, which is found in all the Login and Logout blueprints, initiated by the System Administrator, is a typical example of a CRUD use case (see Chapter 20, “CRUD”). It models how a user identity is registered, modified, and removed from the system, together with the associated password.
The example in this section illustrates two of the blueprints. The first case describes a situation when the system's services are independent of the login procedure, as in the Login and Logout: Standalone blueprint. The model includes the Login/Logout use case, the Manage User Information use case, and fractions of an example use case, called Order Ticket (see the left part of Figure 31.5). The latter has been included to show how we can state that the user must be logged in to the system without having to define a relationship to the Login/Logout use case.
Figure 31.5. The example captures two of the alternatives: independent use cases and additions to login procedure.
The second case describes addition of actions to the login procedure, which is described in the Login and Logout: Action Addition blueprint. Here the model contains a use case called Check for Messages. This use case will present any notifications that arrived while the System User was not logged in to the system. The use case has an extend relationship to the Login/Logout use case so that its actions will be executed whenever a login procedure is performed (see the right side of Figure 31.5).
Note that the same use-case description of Login/Logout is used in both examples.
Here, the CRUD and the Use-Case Sequence patterns as well as the Message Transfer blueprints might also be useful.
The model presented in Figure 31.6 is quite straightforward. The System User requests to be allowed to log in to the system using the Start Form. An instance of Login Handler is created to manage the login procedure. It opens a Login Form to the System User where the user information, such as the name and the password, PIN code, or similar, is to be entered. When the Login Handler receives this information from the Login Form, it verifies the correctness of the entered information using information stored in the instance of User Information identified based on the given information. The Login Handler handles all error cases such as invalid password or PIN code, nonregistered user, and the procedure to be followed when too many invalid attempts have been made.
Finally, when the System User has successfully entered the login information, the Login Handler registers that the System User has logged in, and an instance of the System Form is presented to the System User. This instance will, possibly depending on who the System User is, display welcome messages and open up different services to be used by the System User.
If any additional actions are to be performed (Login and Logout: Action Addition, Login and Logout: Reuse, and Login and Logout: Specialization), the Login Handler creates instances of appropriate Other Handler classes. After creating the System Form for the System User, the Login Handler and the Start Form cease to exist.
When the System User requests to log out from the system, the System Form creates a Login Handler to manage the logout procedure. It registers that the System User exits, removes the System Form, and presents the Start Form. Finally, the Login Handler ceases to exist.
To register or deregister user information, the System Administrator initiates the Manage User Information use case via the System Form, which creates an instance of the User Information Handler. It opens a User Information Form, where the System Administrator can enter and modify the information. Finally, the information is stored in an instance of the User Information class.