Grokking the Object Oriented Design Interview

Vote

0% completed

Design a Library Management System

On This Page

System Requirements

Use case diagram

Activity diagrams

Code

The finished class diagram

What we left out, and what to say about it

A Library Management System is a software built to handle the primary day-to-day operations of a library. Libraries rely on library management systems to manage asset collections as well as relationships with their members. Library management systems help libraries keep track of the books and their checkouts, as well as members' subscriptions and profiles.

Library management systems also involve maintaining the database for entering new books and recording books that have been borrowed with their respective due dates.

System Requirements

Always clarify requirements at the beginning of the interview. Be sure to ask questions to find the exact scope of the system that the interviewer has in mind.

We will focus on the following set of requirements while designing the Library Management System:

Any library member should be able to search books by their title, author, subject category as well by the publication date.
Each book will have a unique identification number and other details including a rack number which will help to physically locate the book.
There could be more than one copy of a book, and library members should be able to check-out and reserve any copy. We will call each copy of a book, a book item.
The system should be able to retrieve information like who took a particular book or what are the books checked-out by a specific library member.
There should be a maximum limit (5) on how many books a member can check-out.
There should be a maximum limit (10) on how many days a member can keep a book.
The system should be able to collect fines for books returned after the due date.
Members should be able to reserve books that are not currently available.
The system should be able to send notifications whenever the reserved books become available, as well as when the book is not returned within the due date.
Each book and member card will have a unique barcode. The system will be able to read barcodes from books and members' library cards.

Use case diagram

We have three main actors in our system:

Librarian: Mainly responsible for adding and modifying books, book items, and users. The Librarian can also issue, reserve, and return book items.
Member: All members can search the catalog, as well as check-out, reserve, renew, and return a book.
System: Mainly responsible for sending notifications for overdue books, canceled reservations, etc.

Here are the top use cases of the Library Management System:

Add/Remove/Edit book: To add, remove or modify a book or book item.
Search catalog: To search books by title, author, subject or publication date.
Register new account/cancel membership: To add a new member or cancel the membership of an existing member.
Check-out book: To borrow a book from the library.
Reserve book: To reserve a book which is not currently available.
Renew a book: To reborrow an already checked-out book.
Return a book: To return a book to the library which was issued to a member.

Activity diagrams

Check-out a book: Any library member or librarian can perform this activity. Here are the set of steps to check-out a book:

Return a book: Any library member or librarian can perform this activity. The system will collect fines from members if they return books after the due date. Here are the steps for returning a book:

Renew a book: While renewing (re-issuing) a book, the system will check for fines and see if any other member has not reserved the same book, in that case the book item cannot be renewed. Here are the different steps for renewing a book:

Code

Here is the code for the use cases mentioned above:

Check-out a book,
Return a book, and
Renew a book.

The listing compiles and runs in Python, Java and C++. Where a real system would read and write rows in a database, the classes below keep those rows in memory instead, so that the behaviour is visible without a database to connect to.

Enums and Constants: Here are the required enums, data types, and constants:

The five code groups below also build the class diagram as they go. Each group adds its classes to one picture, the classes from earlier groups stay exactly where they were, drawn in grey, and by the last group you have seen a reason for every box in the finished diagram at the end of the lesson.

Python3

. . . .

BookReservation, BookLending, and Fine: These classes represent a book reservation, lending, and fine collection, respectively.

Requirements 4, 7 and 8 are about remembering what happened: who reserved a copy, who borrowed it, and what is owed on a late return. Each record keeps the barcode of the copy and the id of the member, so both halves of requirement 4, who took this book and what does this member have out, are answered by scanning these records. The diagram starts with these three classes alone. The arrows out of them appear in later stages, as the classes they point at arrive. The legend after the diagram shows how to read every arrow used in this lesson.

Python3

. . . .

Book, BookItem, Author, and Rack: Book is the title. BookItem is one physical copy of that title, with its own barcode and its own place on a rack, which is what a member actually borrows:

Requirements 1, 2, 3 and 10 produce the book cluster. Book is the title and BookItem is one physical copy, which is what the inheritance arrow says: a copy is everything the title is, plus a barcode, a price and a place on a rack. With copies in the picture, the stage 1 records get their arrows: a reservation and a lending are each for exactly one copy.

Python3

. . . .

Account, Member, Librarian, and LibraryCard: These classes represent the people who use the system. Member carries the three use cases this lesson is about: checking a copy out, returning it, and renewing it:

Requirements 5 and 6 are limits on a member, so they live with the people. Account is abstract with Librarian and Member below it, and the filled diamond says an account owns its library card: cancel the account and the card goes with it. The other new arrows read the same way as sentences: a fine is charged to one member, and a member makes reservations.

Python3

. . . .

Search interface and Catalog: The Catalog class will implement the Search interface to facilitate searching of books.

Requirement 1 lists four ways to search, and those four methods become the one interface in the design. Catalog implements Search, which is the dashed arrow with the hollow head, and keeps one index per search so every lookup is a read rather than a scan. The catalog indexes the book items; it does not own them.

Python3

. . . .

Library and Notification: The library owns the catalog and the racks. Notification is the abstract class behind the message a member gets when a copy they reserved comes back:

Requirement 9 produces the notification classes, one subclass per way of delivering, and it is the reservation record that sends one when a reserved copy comes back. Library arrives last and owns the catalog, the racks and the book items, which is why all three filled diamonds sit at the Library end of their lines.

Python3

. . . .

The finished class diagram

Now that every class exists, here is the whole model in one picture. It is the same picture the five code groups have been filling in, with every class in full colour at last: nothing on it appears here for the first time.

Here are the main classes of our Library Management System:

Library: The central part of the organization for which this software has been designed. It has attributes like 'Name' to distinguish it from any other libraries and 'Address' to describe its location.
Book: The basic building block of the system. Every book will have ISBN, Title, Subject, Publishers, etc.
BookItem: Any book can have multiple copies, each copy will be considered a book item in our system. Each book item will have a unique barcode.
Account: We will have two types of accounts in the system, one will be a general member, and the other will be a librarian.
LibraryCard: Each library user will be issued a library card, which will be used to identify users while issuing or returning books.
BookReservation: Responsible for managing reservations against book items.
BookLending: Manage the checking-out of book items.
Catalog: Catalogs contain list of books sorted on certain criteria. Our system will support searching through four catalogs: Title, Author, Subject, and Publish-date.
Fine: This class will be responsible for calculating and collecting fines from library members.
Author: This class will encapsulate a book author.
Rack: Books will be placed on racks. Each rack will be identified by a rack number and will have a location identifier to describe the physical location of the rack in the library.
Notification: This class will take care of sending notifications to library members.

What we left out, and what to say about it

This design covers the ten requirements and nothing else. Paying a fine, replacing a lost copy, inter-library loans, e-books and a waiting queue for a popular title are all absent, and that was a decision rather than an oversight.

Two places where a reviewer will question the design, and the honest answer to each:

Member does two jobs. It is a person with an address and a card, and it is also the class that checks out, returns and renews. Those are two reasons to change. A longer design would leave the person on Member and move the three flows onto a lending service that takes a member and a copy.
Catalog keeps one index per way of searching. Four search methods means four maps, so a fifth way to search means a fifth map. One index keyed by field name would do the same work and would not grow. The four maps are here because the four search methods are a requirement and the shape makes them easy to read.

One more thing to say before you are asked: a fine is calculated and never collected. Fine records what is owed, and nothing in the design takes payment. In an interview, name that gap yourself and say where payment would go.

💡 In the interview: build in this order and say what each group gives you before you write it. The split that carries the whole design is Book and BookItem: the title against one physical copy with its own barcode and rack. Say why they are separate early, because every later class depends on it. Expect two follow ups. The first is "what happens when two members reserve the last copy at the same moment", which this design does not guard. The second is "how does a member get told the book is back", which is the notification hierarchy and the reservation that triggers it.

Mark as Completed

· 4 years ago

Show 2 replies

Balaji Srinivasan

· 3 years ago

Pedro Barros Torreão Gaião

· 3 years ago

Rohit Bhanot

· 12 days ago

On This Page

System Requirements

Use case diagram

Activity diagrams

Code

The finished class diagram

What we left out, and what to say about it