We continue here with same example from the book, the use case diagram for a new public library book management system. The C.R.U.D. matrix we created in the previous post is below:
C.R.U.D. matrix for library management system |
By reviewing each data entity's column in the matrix we find the following holes in our coverage of the data:
- Titles is read by every use case, but none create, update or delete a title.
- Copies of Books is read by all use cases, but none create, update or delete a copy of a book.
- Check Out Requests and Branch Library Transfers are created, read and updated by our use cases, but no use case deletes a check out request or library transfer.
- Borrowers, Librarians, Curators and Branch Libraries are all read by our use cases, but none create, update or delete these data entities.
• Add Books to Library Database - This use case adds a new copy of a book to the library holdings. But before it can add a new copy, the title is validated (read) to make sure its registered with the library. If not, a new title record is created tracking information common to future copies of this book (create). Also, the curator making the addition is authenticated (read). Finally, a check is made of pending reservation requests for this book title (read); if one exists (next in line for the book if there are multiple), the reservation is flagged to notify person reserving the book (update).
• Remove Books from Library Database - This use cases removes a copy (but not the title) of a book from the library’s holdings. The curator doing the remove is authenticated (read), the title is validated (read), the particular copy of the book to be removed is validated (read). Also, confirmation is made that the book is not currently checked out (read); not on loan to a branch library (read); and not a copy that has been pulled by a librarian for pending pickup by a borrower, e.g. was reserved on-line (read). Once validated, the tracking records for this book copy is deleted from the library tracking system, i.e. information about the particular copy, checkout history, branch library transfer history.
With these additional use cases, we still have a few holes in our coverage of the data:
- No use cases update or delete titles
- No use cases update the information kept for particular copies of each book, say to correct the date of acquisition, or from where it was acquired, etc.
- While book reservations are created, read and updated by the use cases, none delete the backlog of old reservations.
- And no use cases create, update or delete the system’s borrowers, librarians, curators, or branch libraries.
It’s worth emphasizing, sometimes saying what you are not going to test is every bit as important as saying what you are going to test (“What, you didn’t test that? Had I known that I would have said something in the review of the test plan!!”). So while not common on a C.R.U.D. matrix, adding a row called “Don’t Care” is a smart thing to do as a test designer.
Revised C.R.U.D. matrix is below featuring two new use cases and completed “Don’t Care” row. Changes from previous matrix are highlighted in grey and red. Notice now that each column includes at least one create (C), read (R), update (U) or delete (D).
Revised C.R.U.D. matrix for library management system with missing use cases identified |
No comments:
Post a Comment