1. 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 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.

2. Borrow journal Borrow copy of book Return copy of book Extend loan Reserve book Return journal Browse Update catalog Book Borrower Journal Borrower Browser Librarian Use Case Diagram

3. 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.

4. 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.

5. 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.

6. 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.

7. Book 1 Is a copy of 1..* LibraryMember Copy borrows/returns 0..1 0..* 0..* borrows/returns 0..1 MemberOfStaff Journal borrows/returns 0..1 0..* Initial Class model

8. Book 1 Is a copy of 1..* LibraryMember Copy borrows/returns 0..1 0..* MemberOfStaff Journal borrows/returns 0..1 0..* Revised class model

9. Book 1 Is a copy of 1..* LibraryMember Copy borrows/returns 0..1 0..* Loan MemberOfStaff Journal borrows/returns 0..1 0..* Same for journal? Further Revision?

10. 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

11. 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

12. theLibraryMember: LibraryMember theCopy: Copy theBook: Book aMember: BookBorrower borrow (theCopy) 1: okToBorrow 2: borrow 2.1:borrowed Interaction shown on a Sequence Diagram