4.3.                    Example system

Lets see how we can apply this methodology to our example system under development. From the system description we identify the actors. We can identify two actors, the user and the librarian, and if we consider that we shall use a database management system to store the information stated in the description, then this database shall be a third actor.

The next step is to find out how our actors interact with the system. This will help us identify a first cut of use cases. We can do this by going through the description again. The first statement states:

“There is a need for an automated library system that permits the registration of books, magazines, documents, electronic data storage software (CD, floppy, zip etc.) etc.”

There must be a way to insert (register) all these items with the library. This is the responsibility of the librarian even though it is not stated in the description. Hence, we can create a use case Registers item for this case.

            The next statement:

“A user must be able to browse a library catalogue and be able to do a search to the catalogue (by author, by title, by ISBN and/or by keyword).”

notifies us that there should be a use case Search for item that contains also another use case Browse library catalogue. But for now, lets assume only the use case Search for item.

“The user will be able to make an application electronically to borrow a book and after approval, a token will be returned to him/her and s/he will be able to borrow the item from its physical location in the library.”

From the above statement, another use case will be Borrow item.

“If the item is not available, s/he will be able to make a reservation on the item. Reservations will be stored in a FIFO list for the users.”

The user can also interact with the system with the use case Reserve item.

Continuing the same way we have produced the use case diagram of Figure 7 .

Figure 7 A first cut use case diagram for the example system

Next, we must register each actor and use case using the formula described in §4.1. For example, a short documentation for the actor user would be: “A user can be anyone who has rights to use the system to search for and borrow an item”. 

The documentation for a use case will be:

Use case RESERVE ITEM

ID

Reserve item 1

Description

A user can reserve an item if another user has borrowed it.

Actor(s)

User

Preconditions

The user is a valid system user (has been successfully logon into the system) and another user has borrowed the item s/he wishes to borrow.

Basic flow of action

  1. The user fills in a form with his/her user id and the item’s id s/he wishes to reserve
  2. The user clicks on the reserve button
  3. The user is added in the reserve FIFO list for this item and the system notifies the user about this.

Exceptions/Alternative flows

  • If the item has not been borrowed by another user, then the user should be able to directly borrow it
  • If the reserve list is full, the user is notified about it and is requested to try later.
  • If there is a system or communications error while the user is processing the reservation form, then no update to the reservation list should be made and the database should backtrack the changes.

Post conditions

The user has been added in the reserve FIFO list for the item.

Sub use cases

 

Extension points

 

Requirements tracing

“If the item is not available, s/he will be able to make a reservation on the item. Reservations will be stored in a FIFO list for the users.” 1

Notes

 

We see that some fields are empty in the above use case documentation. These fields will be completed later during the analysis phase.

Once we have documented all use cases, we can now proceed further with our analysis by rectifying our use case diagram. First, we can analyse more the relation between the user and the librarian. We can assume that the librarian can also be a normal user of the system, i.e. be able to borrow items, make reservations etc. However, a librarian has additional responsibilities such as to register new items or users, receive fine payment etc. Or, we may decide that the librarian cannot perform what a normal user can do. In this case if the librarian wishes to borrow items too, then s/he must have a second id with the library, that of a normal user. In our system, we decide for the first case. Hence, we have to provide a generalization relationship between the librarian and the user as is shown in the following diagram:

Figure 8 A generalisation relationship among actors

This relationship means that the librarian can perform all the use cases the user can perform, plus additional ones, but not the other way round.

We are now in a position to further rectify out use case diagram by use of associations. We saw in our previous analysis that Search for item use case also includes a use case Browse items which is not shown in the use case diagram. The basic flow of action for Search for item use case is:

1.

1 In a real system a use case ID will be of the form: #13. Similarly, requirements come will some sort of numbering, so in the "Requirements tracing" row, instead of a description of the requirement we would have something like: #906, #45, #34 etc. if the use case refers to more than one requirement statements.