System Use Case | OOP Demystified

Whereas the essential use case approach defines the nontechnical aspect of a particular task or goal, the system use case defines the technical aspect. It is important to note that the use case diagram in Figure 10-1 can be used in both, as it demonstrates a particular task and its actors.

System use cases differ from essential use cases in their documentation and how we describe the process itself (as noted earlier, essential use cases are documented). Whereas the essential use case documentation would refer to the basic steps, needs, prerequisites, actors, and so on, the system use cases will document the technical aspects of the system, such as the user interface elements, database elements, and so on.

In describing a system use case, we might also find references to user interface elements, which are what make up the visual interface to the application. The most common user interface is Windows, and we can easily imagine using dialog boxes and controls ( buttons , check boxes, list boxes, and so on) in the documentation process. Of course, not all programs or program steps require a user interface. Server-type applications don t have a specific user interface but can still benefit from system use cases to describe technically explicit operations.

Even the documentation here takes a bird s-eye-view of the process. We might describe our registration process in terms of User login screen UI12 is displayed to retrieve the user s name and password and Logon table TBL3 is queried for a valid name and password combination. Note that UI12 and TBL3 are unique IDs given to a user interface element and a database table. As we design systems, we want a way to easily refer back to a specific item.

More technical (system) documentation for the use case diagram might look like the following:

Name : StudentRegister
Description : The student attempts to register, and if the registration is valid, she is registered for the class.
Prerequisites : The student must have no outstanding bills, not already be enrolled in the class, and be in good academic standing.
Path:
1. The student requests registration into a class using form UI12.
2. The system checks business rules BR1, BR5, and BR9 to determine whether the student is eligible. If not, student is notified immediately.
3. The system notifies the registrar of a new request using pop-up form UI11.
4. The registrar reviews the data on form UI11 and approves or declines the registration.
5. If the registration is approved, the system stores the registration data in Enrollments table TBL3 and sends an e-mail to student using the Mailer class.
Results : The student is either registered in class or is not. The student is sent e-mail notification of the end result either way.