Transcript Use Case - Example University library system requirements Books and journals – the library contains books and journals.

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.
Borrow journal
Book Borrower
Journal Borrower
Reserve book
Return journal
Borrow copy of book
Return copy of book
Browse
Browser
Extend loan
Update catalog
Use Case Diagram
Librarian
• 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
1
Is a copy of
1..*
borrows/returns
Copy
LibraryMember
0..1
0..*
0..*
borrows/returns
0..1
MemberOfStaff
borrows/returns
0..1
0..*
Initial Class model
Journal
Book
Is a copy of
1
1..*
borrows/returns
Copy
LibraryMember
0..1
MemberOfStaff
0..*
borrows/returns
0..1
0..*
Revised class model
Journal
Book
Is a copy of
1
1..*
borrows/returns
Copy
LibraryMember
0..1
0..*
Loan
MemberOfStaff
borrows/returns
0..1
Journal
0..*
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