Use Case - Example

University library system requirements Books and journals the library contains books and journals. It may have several copies of a given book. Some of the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Only members of staff may borrow journals. Members of the library can normally borrow up to six items at a time, but members of staff can borrow up to 12 items at a time. New books and journals arrive regularly, and old ones are sometimes disposed of. The current years journals are sent away to be bound into volumes at the end of each year. Borrowing it is essential that the system keeps track of when books and journals are borrowed and returned. The new system should also produce reminders when a book is overdue. There may in future be a requirement for uses to be able to extend the loan of a book if it is not reserved. Browsing this system should allow users to search for a book on a particular topic, by a particular author, etc., to check whether a copy of the book is available for loan and, if not ,to reserve the book. Anybody can browse in the library.
P. Stevens, R. Pooley. Using UML: Software Engineering with Objects and Components. Addison-Wesley, 2000.

Borrow journal Book Borrower Reserve book Return journal Borrow copy of book Journal Borrower

Return copy of book

Browse

Browser

Extend loan Update catalog Librarian

Use Case Diagram

 User interface
our task is to build the underlying system providing functionality which will be invoked through the user interface. separation between user interface and underlying system.

Beware of making diagrams very complex

A diagram too complex to draw by hand is probably also it too complex to think out clearly. Split into multiple diagrams; use cases at high level of abstraction. Update catalog use case: Includes all the librarians adding and removal of books, sending away of journals etc. When this functionality is considered in detail we may want to separate these out into multiple use cases.

Short descriptions of use cases

Do not invent requirements! Can be useful to make a list of questions and possibilities with each use case, for discussion with the customer.

Borrow copy of book

A BookBorrower presents a book. The system checks that the potential borrower is a member of the library, and that s/he does not already have a maximum permitted number of books on loan. This maximum is six unless the member is a staff member in which case it is twelve. If both checks succeed, this system records that this library member has this copy of the book on loan. Otherwise it refuses the loan.

Identifying classes
Key domain abstractions Features and facts about the library which matter in the system

we are building to support it.

Noun identification
Books and journals the library contains books and journals. It may have several copies of a given book. Some off the books are for short term loans only. All other books may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff can borrow up to 12 items at a time. Only members of staff may borrow journals.

Candidate classes
Discard as candidate classes:
Library Short term loan loan is really an event, which, so far as we know, is not a useful object in the system Week measure of time, not a thing. Item vague. Clarify as either a book/journal.

Candidate classes
Book Journal Copy of book library member Member of staff

Dont need to get it absolutely right at this stage we are not trying to design the system, butt to identify the important real world objects within the domain of the system.

Book
Is a copy of 1 1..*

borrows/returns
LibraryMember 0..1 0..*

Copy
0..*

borrows/returns 0..1 MemberOfStaff borrows/returns 0..1 0..*

Journal

Initial Class model

Book
Is a copy of 1 1..*

borrows/returns
LibraryMember 0..1 0..*

Copy

MemberOfStaff

borrows/returns 0..1 0..*

Journal

Revised class model

Book
Is a copy of 1 1..*

borrows/returns
LibraryMember 0..1 0..*

Copy

Loan

MemberOfStaff

borrows/returns 0..1 0..*

Journal Same for journal?

Further Revision?

Interaction Diagrams
UML uses interaction diagrams to show how messages pass between objects of the system to carry out some task To realize a particular use case Not needed for every use case. For a complicated use case, or to clarify which of several use case

realizations is better

Library member borrows a book In the physical world a human library member will come to the issuing desk with physical copy of a book. Via the system interface there will be some means of identifying the library member and book copy. So we can start with a library member object (theLibraryMember) and a certain Copy object (theCopy). The interaction begins by a BookBorrower actor sending a message to theLibraryMember. The message will specify the service required, in this case to borrow theCopy say, borrow(theCopy). This system has to check that it is permitted for the theLibraryMember to borrow another book: one of the duties of the library member will be to perform this check theLibraryMember sends itself a message, say, okToBorrow. Next we want to update the systems information about how many copies of the book are in the library, since now there is one fewer. This involves the book object (theBook) that is associated with theCopy. Suppose that theLibraryMember informs theCopy that it is being borrowed by sending it the message borrow, and that theCopy then sends theBook a message to say that a copy of the book is being borrowed, say borrowed. Nothing else needs to be done

theLibraryMember: LibraryMember

theCopy: Copy

theBook: Book

aMember: BookBorrower borrow (theCopy) 1: okToBorrow 2: borrow 2.1:borrowed

Interaction shown on a Sequence Diagram