A Library System
1. Inception
We have been asked to build a computer based library system that will handle the
bookkeeping aspects of a library and provide user browsing facilities.
The first thing to do is to go and find out about the target library or libraries to see
what they do now and what they would like to be able to do.
We get the following data:
2. Requirements
Books and Journals. The library contains both books and journals. It may have
several copies of the same book. Some of the books are for short term loans only. All
other books may be borrowed by any library member for 3 weeks. Only members of
staff may borrow journals. Members of the library can normally borrow up to 6 items
at a time, but members of staff may borrow up to 12 items at a time. New books and
journals arrive regularly and sometime disposed of; the catalogue needs to be updated.
The current year’s journals are sent away to be bound 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 produce reminders when a book is
overdue. It may be desirable to allow users to extend their loans if the book is not
reserved. The system enforces the rules for borrowing given above.
Browsing: The system should allow users to search for a book on a particular topic or
by a particular author etc. The user should then be able to check if the book is on loan
and if so to reserve the book.
To start the design of the system it is useful to decide on a set of use-cases and usecases involve actors so who are a suitable set of actors?
3. Choosing Actors
One way of choosing Actors is to read the desciption of what the system does and see
what external people or systems are mentioned:
Members of staff
Members of the library
Users
Another approach to choosing actors, which may be more useful is to look at what
people or other systems do when they interact with the system a derive generic nouns
for actors from these:
Borrowers – book borrowers and journal borrowers
cataloguer
Browsers
4. Use Cases for Library
<<uses>>shows that one use case uses another. The arrow is in the direction that use
is made. Words put in double braces indicate that the action is a stereotype that has
been give a pre-defined meaning.
Library System
Reserve
book
browse
browser
book
borrower
<<uses>>
Borrow
copy of
book
Check for
reservation
Return
copy of
book
Extend
load
Borrow
journal
Update
catalogue
Librarian
journal
borrower
Return
journal
Communicates Relationships are associations between actors and use cases. They are
used to model communications actors and use cases in which an actor participates,
communicates with or takes part in a use case.
Communication relationships allow an actor to participate in any number of use cases.
There can be arrows in either direction or none. If the actor uses the services provided
by the use case the arrow points to the actor; if the actor simply particpates in the use
case the communication arrow points to the use case.
Extends Relationships are generalisations between use cases. They
 Are used to capture exceptional behavour of variations of norma behaviour
 Allow an extending use case to continue the activity of a base use case when
the exptension point is reach and the extension condition is fulfilled. Upon
completion fo the extension activity the original case continues.
 The arrow points towards the base use case.
An example is that the Book Borrower may try and borrow too many books and so an
extension of the Borrow copy of book would be Refuse loan, where the condition of
the extension is that the reader has too many books.
Uses Relationships are generalisations between use cases. So a common use case ( see
the Library “check for reservation” use case) may be used in many use cases. They
 Are used to share common behavious among use cases
 Are denoted as generalisation arrows towards the common or shared use case.
 Must be stereotyped using the “uses” keyword.
 Base use cases may interleave the common use cases between other specific
behaviour.
5. What use are Use Cases
They are a device for starting to get the requirements for the system. We identify
the actors and then find out what the actors want the system to do. If a system can
be built over time you can prioitise the work by finding out which use cases are
needed first and then building that part of the system first. Since 25% of computer
based systems are never delivered [Using UML Pooley & Stevens p 100], it is
important to deliver the use cases to the people who are most able to cancel the
system! Finally we can use the use cases as a device to validate that the system
does fulfill the requirements ie the use cases. Summarising:
Requirements capture
Planning – what to do when
System validation.
6. Identifying Classes
Identifying classes is a skill that is the key to good analysis. A simple way to start is
to list all the nouns and noun phrases in the system requirements. This has been done
by underlining them in following abbreviated requirements.
Books and Journals. The library contains both books and journals. It may have
several copies of the same book. Some of the books are for short-term loans only. All
other books may be borrowed by any library member for 3 weeks. Only members of
staff may borrow journals. Members of the library can normally borrow up to 6 items
at a time, but members of staff may borrow up to 12 items at a time.
Borrowing. It is essential that the system keeps track of when books and journals are
borrowed and returned enforcing the rules given above.
and gives the following list:
Library
Books
Journals
Copies of a book
Short term loan
Member of staff
Member of the library
Week
Item
Time
System
Rule
Catalogue
Reminders
rules
We now seek to look for the best generalisations and remove un-necessary classes.
This is a judgement based move but I indicate some useful rules of thumb for
discarding classes:
 Library because it is outside the scope of our system
 Short term loan, because a loan (short term or otherwise) is really an event, the
lending of a book to a user and so is probably not a useful object class
 Member of the library , this is a long title for library member which is better.
 Week, because it is a measure of time and not a thing
 Item, because it is vague; when clarified we see it is a book or a journal
 System, because it is just a part of the language of description not a part of the
domain
 Rule, again as system.
This leaves us as possible classes:
Book
Journal
Copy (of book)
Library member
Member of staff
Now objects and classes, to be useful must have data associated with them and may
take actions by sending messages to other objects or doing something directly
themselves. So books have titles and authors, journals have publishers and dates,
copies of books have a state ie they are on the shelves or on loan, library members
have names, number of books on loan etc. A member of staff has the same data as a
library member.
7. Relations between Classes
We are in the analysis phase of the design. The purpose of the analysis phase is to
make sure that both the designer and the client understand as much as possible about
the requirements and general nature of the system to be designed. This reduces the
risk in the project and generally produces a better product. To better understand the
classes it is good to understand the relationships that exist between the different
classes. If the relationships turn out to be very complex then it is probable that a poor
choice of classes has been made – good systems are modularised into components that
have a low level of coupling. There may be a strong coupling between two classes if
they are conceptually related. There is going to be a lot of similarity between the class
of members of staff and library members – but this is not a bad thing as one could be
a sub-class or specialisation of the other.
Here are some relations:
A copy is a copy of a book
A library member borrows/returns a copy
A member of staff borrows/return a copy
A member of staff borrows/returns a journal
This is portrayed in the UML class model of the library
Book
1
Is a copy of
1..*
LibraryMember
Borrows/returns
1
Copy
0..*
0..*
Borrows/returns
1
MemberOfStaff
Borrows/returns
1
Journal
0..*
We notice that Member of Staff takes part in all the relationships of library member.
We can represent this more general statement by redrawing the UML diagram
showing Library member as a generalisation of Member of staff. This could be
implemented with MemberOfStaff as a subclass of LibraryMember.
The names Book and Copy are succinct but could be confused – clearer language such
as PublishedTitleofBook is preferred.
Note that the UML diagrams show not only the relationships but also the
multiplicities.
1..* means one or more so there may be one or more copies of the same book
0..* means zero or more; so that 1 memberOfStaff borrows or returns none of more
books.
A Revised Class Diagram
Published Title of Book
1
Is a copy of
1..*
LibraryMember
Borrows/returns
1
MemberOfStaff
0..*
Borrows/returns
1
Copy
Journal
0..*
8. The System in Action
So far we have only looked at static structures but most systems are dynamic and we
need to be able to model how it works. This is done using Sequence diagrams.
In UML actions take place by the sending of messages from one member of a class to
a member of another or indeed the same class.
If we go back to our use case diagrams. The actor may be a BookBorrower who
decides to borrow a particular copy of a book. He presents the book to a
LibraryMember and gives the message borrow(the Copy). The LibraryMember
checks if it is ok to borrow the book ie it has not been reserved by someone else and
the BookBorrower has not already got too many books on loan. The library member
knows how to check this and does so by sending himself a message to activate that
activity.
Now it is necessary to update the information about the book. We have a class Copy
and a class Book. So we can now send a message to the Copy to say borrow and then
a message to the particular title ie Book to say that one more copy has been borrowed.
See the sequence diagram that makes all this clearer. Note that there is a numbering
system that explains the order in which the messages are sent.
9. Diagrams that model Activity
Al the models thus far have been largely static, the exception being the Use Cases
which imply action. There are several types of diagrams that display the way that the
system works. Sequence Diagrams are usually used to show how some action occurs
by tracing the flow of control from object to object.
9.1 A Sequence Diagram
The diagram below shows how a library member borrows a book is implemented in
terms of messages passes from object to object.
The
libraryMember
The copy
Published Title of
Book
aMember:BookBorrower
borrow(thecopy)
1:okToBorrow
2:borrow
2.1:borrowed
The Numbering system for messages: Every message is assumed to have an ending
when the activities it initiates directly are finished. We can think of this as the
message getting a reply. In a sequence diagram we number the messages starting at 1
but if there has been no reply to 1 then the next message is called 1.1, 1.2, 1.3 etc until
a reply comes to 1 when we move to 2. This rule applies as all levels so if there is no
reply to 1.3 then the next message is 1.3.1, 1.3.2 etc until a reply to 1.3.1 when we
move to 1.4.
Scenarios are important ways in which we visualise systems behaviour and can check
out whether our system will or is behaving properly. Scenarios are sections of
behaviour of the system so for example one scenario is a Bookborrower presenting a
book and being allowed to borrow it. Another related scenario is when the
BookBorrower has already taken out all the books he is allowed and so is refused the
new book. These scenarios are all in the use cases, but it is useful to pick them out to
check out the system. The sequence diagram above displays the way in which the
system can handle the successful borrowing of a book.
9.2 State Diagrams
Another powerful way to model systems is in terms of their states and the transitions
between states. A trivial example for the class PublishedTitleofBook is:
Returned()
Returned()
Not borrowable
borrowable
Borrowed()[last copy]
Borrowed()
[not last copy]
The diagram shows how the state of a PublishedTitleofBook changes as a result of
borrowing and returning of copies of the book.
9.3 Collaboration
Collaboration Diagrams are used to show the way different objects or classes work
together for some purpose.
If you look at the sequence diagram in 9.1 all the objects in the diagram are
collaborating to organise for a BookBorrower to borrow a book.
Published Title of
Book
BookBorrower
2.1:borrowed
Borrow(copy)
Library
Member
Copy
2.borrow
1:okToBorrow