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. Use Case Diagram Borrow journal Reserve book Book Borrower
Return journal
Journal Borrower
Borrow copy of book
Browse
Return copy of book
Browser
Extend loan
Update catalog
Librarian
Use Case Diagram

3. Beware of making diagrams very complex
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: 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. Initial Class model Book Copy Journal 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. Revised class model Book Copy Journal 1 Is a copy of 1..*
LibraryMember
Copy
borrows/returns
0..1
0..*
MemberOfStaff
Journal
borrows/returns
0..1
0..*
Revised class model

9. Further Revision? Book Copy Loan Journal Same for journal? 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. Interaction shown on a Sequence Diagram
theLibraryMember:
LibraryMember
theCopy: Copy
theBook: Book
aMember: BookBorrower
borrow (theCopy)
1: okToBorrow
2: borrow
2.1:borrowed
Interaction shown on a Sequence Diagram