Use Case - ExampleUniversity 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 year’s 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

Borrow copy of book

Return copy of book

Extend loan

Journal BorrowerReserve book

Return journal

Browser

Librarian

Browse

Update catalog

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 librarian’s 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

• Don’t 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

Copy LibraryMember

MemberOfStaff Journal

borrows/returns

Is a copy of

borrows/returns

borrows/returns

1

1..*

0..1 0..*

0..1

0..*

0..1 0..*

Initial Class model

Book

Copy LibraryMember

MemberOfStaff Journal

borrows/returns

Is a copy of

borrows/returns

1

1..*

0..1 0..*

0..1 0..*

Revised class model

Book

Copy LibraryMember

MemberOfStaff Journal

borrows/returns

Is a copy of

borrows/returns

1

1..*

0..1 0..*

0..1 0..*

Further Revision?

Loan

Same for journal?

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

aMember: BookBorrower

theLibraryMember:LibraryMember

theCopy: Copy theBook: Book

borrow (theCopy)1: okToBorrow

2: borrow2.1:borrowed

Interaction shown on a Sequence Diagram