Grokking the Object Oriented Design Interview

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 software that handles the main day-to-day work of a library. Libraries use it to manage their collections and their relationships with members. It keeps track of the books and their checkouts, and of each member's subscription and profile.

A library management system also maintains the database. New books are entered there, and each borrowed book is recorded with its due date.

System Requirements

Always clarify requirements at the beginning of the interview. Ask questions until you know the exact scope of the system the interviewer has in mind.

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

Any library member should be able to search books by title, author, subject category, and publication date.
Each book will have a unique identification number and other details, including a rack number that helps to locate the book physically.
There can be more than one copy of a book. Library members should be able to check out and reserve any copy. We call each copy of a book a book item.
The system should be able to answer who took a particular book, and which books a specific member has checked out.
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 send a notification when a reserved book becomes available, and when a book is not returned by the due date.
Each book and each member card will have a unique barcode. The system will read barcodes from books and from members' library cards.

Use case diagram

We have three main actors in our system:

Librarian: Adds and changes books, book items, and users. The librarian can also issue, reserve, and return book items.
Member: Searches the catalog, and checks out, reserves, renews, and returns books.
System: Sends notifications for overdue books, canceled reservations, and so on.

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

Add/Remove/Edit book: Add, remove, or change a book or book item.
Search catalog: Search books by title, author, subject, or publication date.
Register new account/cancel membership: Add a new member, or cancel the membership of an existing member.
Check-out book: Borrow a book from the library.
Reserve book: Reserve a book that is not currently available.
Renew a book: Borrow again a book that is already checked out.
Return a book: Return a book that was issued to a member.

Activity diagrams

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

Return a book: Any library member or librarian can perform this activity. If a member returns a book after the due date, the system collects a fine. Here are the steps for returning a book:

Renew a book: Renewing means issuing an already borrowed book to the same member again. While renewing, the system checks for fines. It also checks whether another member has reserved the same book. If so, the book item cannot be renewed. Here are the 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++. A real system would read and write rows in a database. The classes below keep those rows in memory instead, so the behavior is visible without a database to connect to.

Enums and Constants: Here are the required enums, data types, and constants. An enum is a type with a fixed list of named values, like the statuses a book item can be in:

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 gray. 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, a lending, and a fine.

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 are answered by scanning these records: who took this book, and what does this member have out.

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. The copy 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. That is what the inheritance arrow says. A copy is everything the title is, plus a barcode, a price and a place on a rack. Inheritance means one class is a kind of another and takes on all its fields. 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. An abstract class cannot be created on its own; only its subclasses can. The filled diamond is composition, which means one class owns another. Here it says an account owns its library card: cancel the account and the card goes with it. The other new arrows read like sentences: a fine is charged to one member, and a member makes reservations.

Python3

. . . .

Search interface and Catalog: The Catalog class implements the Search interface, which is how books are searched. An interface is a list of methods with no bodies, and a class that implements it promises to provide every one of them.

Requirement 1 lists four ways to search. Those four methods become the one interface in the design. Catalog implements Search, which is the dashed arrow with the hollow head. The catalog 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. The reservation record is what sends one when a reserved copy comes back. Library arrives last. It owns the catalog, the racks and the book items. That 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 color 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 this software is built for. It has attributes like 'Name' to tell it apart from other libraries and 'Address' for its location.
Book: The basic building block of the system. Every book has an ISBN, title, subject, publisher, and so on.
BookItem: A book can have many copies. Each copy is a book item in our system, and each book item has a unique barcode.
Account: There are two types of accounts in the system: a general member and a librarian.
LibraryCard: Each library user is issued a library card. It identifies the user when a book is issued or returned.
BookReservation: Manages reservations against book items.
BookLending: Manages the checking out of book items.
Catalog: A catalog is a list of books sorted on some criterion. Our system supports searching through four catalogs: Title, Author, Subject, and Publish-date.
Fine: This class calculates the fines that library members owe and records them.
Author: This class holds a book author.
Rack: Books are placed on racks. Each rack has a rack number and a location identifier that says where the rack sits in the library.
Notification: This class sends 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. That was a decision, not 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. 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. It would 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

Balaji Srinivasan

· 3 years ago

· 4 years ago

Show 2 replies

Reading Progress

Vote for new content

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