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 use-cases 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.
book
borrower
Librarian
journal
borrower
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
1
Is a copy of
1..*
Borrows/returns
10..*
0..*
Borrows/returns
1
Borrows/returns
10..*
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
1
Is a copy of
1..*
Borrows/returns
10..*
Borrows/returns
10..*
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 theCopy 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.
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 borrowableborrowable
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.
BookBorrower
2.1:borrowed
Borrow(copy)
2.borrow
1:okToBorrow