PROJECT
Project Title: City Public Library Management System
1. Class Definitions
Here are the classes, their attributes (with visibility), and their methods.
A. The Abstract Parent: SystemUser
• Type: <<Abstract>>
• Description: Represents any human interacting with the system.
• Attributes:
o # name: String (Protected: accessible by children)
o # email: String
o - phoneNumber: String (Private)
• Methods:
o + login(): boolean
o + updateContactDetails(phone: String): void
B. The Children (Generalization)
1. Member (Inherits from SystemUser)
• Attributes:
o - memberId: String
o - outstandingFines: double
• Methods:
o + checkoutItem(item: LibraryItem): void
o + payFine(amount: double): boolean
2. Librarian (Inherits from SystemUser)
• Attributes:
o - employeeId: String
o - shift: String
• Methods:
o + addItem(item: LibraryItem): void
o + blockMember(m: Member): void
C. The Resource Hierarchy
1. LibraryItem (Abstract Parent)
• Attributes:
o - barcode: String
o - title: String
o - isReferenceOnly: boolean
• Methods:
o + getLocation(): String
2. Book (Inherits from LibraryItem)
• Attributes:
o - isbn: String
o - author: String
• Methods:
o + readSummary(): String
3. DVD (Inherits from LibraryItem)
• Attributes:
o - duration: int (minutes)
o - regionCode: int
• Methods:
o + watchTrailer(): void
D. The Structural Classes
1. Library
• Attributes:
o - branchName: String
o - address: String
• Methods:
o + openLibrary(): void
o + closeLibrary(): void
2. Section (e.g., Fiction, History, Kids)
• Attributes:
o - categoryName: String
o - floorNumber: int
• Methods:
o + listItems(): List<LibraryItem>
E. The Transaction (Association Class)
1. Loan
• Description: The link between a Member and a LibraryItem.
• Attributes:
o - loanId: int
o - issueDate: Date
o - dueDate: Date
• Methods:
o + calculateOverdueDays(): int
o + markReturned(): void
F. The Utility (Dependency)
1. FineCalculator
• Attributes:
o - dailyRate: double
• Methods:
o + generateFine(l: Loan): double
2. defined Relationships
Here is how these classes connect. This is what the diagram would look like.
1. Generalization (Inheritance)
• Relationships:
o Member IS-A SystemUser.
o Librarian IS-A SystemUser.
o Book IS-A LibraryItem.
o DVD IS-A LibraryItem.
• Symbol: Solid line with an empty triangle pointing to the parent.
2. Composition (Strong Whole-Part)
• Relationship: Library (1) composed of Section (1..*).
• Logic: A Section (like the "Kids Section") cannot exist without the Library building. If the Library
is demolished, the Sections are gone.
• Symbol: Solid line with a Filled Diamond on the Library end.
3. Aggregation (Weak Whole-Part)
• Relationship: Section (1) contains LibraryItem (0..*).
• Logic: A Section holds Books/DVDs. However, if the "Fiction Section" is removed during a
renovation, the Books still exist and can be moved to a warehouse or another section.
• Symbol: Solid line with an Empty Diamond on the Section end.
4. Association (Structural Link)
• Relationship: Librarian (1) manages Loan (0..*).
• Logic: A Librarian processes loans.
• Symbol: Solid line.
5. Association Class (The Triangle)
• Relationship: Member borrows LibraryItem.
• The Logic: You cannot just draw a line between Member and Book because we need to know
the Due Date of that specific borrow event.
• Solution: The class Loan sits between Member and LibraryItem.
• Multiplicity:
o Member (1) <---> Loan (0..*)
o LibraryItem (1) <---> Loan (0..1) (An item can only be on one active loan at a time).
6. Dependency (Usage)
• Relationship: FineCalculator ..> Loan.
• Logic: The FineCalculator does not store Loans permanently. It just takes a Loan object as a
parameter in its generateFine(l: Loan) method to calculate the cost, then forgets it.
• Symbol: Dashed arrow pointing to Loan.
COURSE: OBJECT-ORIENTED MODELLING
Project Case Study: City Public Library Management System
Time Allowed: 1 Hours
Instructions: Answer all questions.
SECTION A – MULTIPLE CHOICE (15 Marks)
Instructions: Select the best answer. All questions refer to the Library Class Diagram.
1. Which symbol represents the relationship between Library and Section?
A. Empty Diamond (Aggregation)
B. Filled Diamond (Composition)
C. Solid Triangle (Generalization)
D. Dashed Line (Dependency)
2. The LibraryItem class is marked as <<Abstract>>. What does this imply for the code?
A. It cannot be instantiated directly (you cannot create a generic "Item").
B. It has no attributes.
C. It is visible only to the Librarian.
D. It generates a database error if accessed.
3. In the SystemUser class, the attribute phoneNumber is marked with a minus sign (-). This
means:
A. It is Public.
B. It is Protected.
C. It is Private.
D. It is Static.
4. Member and Librarian are connected to SystemUser with a triangle arrow. This relationship
allows them to:
A. Share the loanId attribute.
B. Inherit the login() method and name attribute.
C. Be deleted if SystemUser is deleted.
D. Access each other’s private data.
5. What is the multiplicity of Member in the relationship with Loan?
A. 1 (Exactly one)
B. 0..1 (Zero or One)
C. 1..* (One or Many)
D. 0..* (Zero or Many)
6. Why is Loan modeled as a class rather than a simple line between Member and LibraryItem?
A. Because the arrow is dashed.
B. To store specific transaction data like issueDate and dueDate.
C. Because Java requires it.
D. To prevent the Member from borrowing more than one book.
7. The FineCalculator connects to Loan with a dashed arrow. This indicates:
A. FineCalculator owns the Loan.
B. FineCalculator inherits from Loan.
C. FineCalculator depends on (uses) Loan to perform a calculation.
D. Loan is a parent of FineCalculator.
8. If the Library object is destroyed (e.g., the building closes down), what happens to
the Section objects?
A. They are destroyed (Composition).
B. They continue to exist (Aggregation).
C. They are moved to the SystemUser class.
D. They become Abstract.
9. Conversely, if a Section (e.g., Fiction) is removed, what happens to the LibraryItem objects
(Books/DVDs) inside it?
A. They are automatically destroyed.
B. They continue to exist (Aggregation) and can be moved elsewhere.
C. They become null.
D. They are deleted from the database immediately.
10. The attribute regionCode is found in DVD but not in Book. This demonstrates:
A. Encapsulation.
B. Polymorphism.
C. Specialization (attributes specific to a subclass).
D. Dependency Injection.
11. Which method allows a Librarian to stop a Member from borrowing books?
A. payFine()
B. blockMember()
C. checkoutItem()
D. updateContactDetails()
12. The method generateFine(l: Loan) returns a double. What does this represent?
A. The number of books borrowed.
B. The monetary amount of the fine.
C. The number of days overdue.
D. The ID of the Member.
13. What is the return type of the login() method in SystemUser?
A. void
B. String
C. int
D. boolean
14. The relationship between Librarian and Loan is labeled "manages". This is an example of:
A. Association.
B. Generalization.
C. Realization.
D. Composition.
15. If we add a method getEmail() to SystemUser, which classes can automatically use it?
A. Only SystemUser.
B. Only Librarian.
C. Member, Librarian, and any future subclasses of SystemUser.
D. Book and DVD.
SECTION B – STRUCTURAL QUESTIONS (20 Marks)
Instructions: Answer the following questions briefly (1-2 sentences). Each question is worth 2 marks.
1. Inheritance: The SystemUser class holds the name and email attributes. Why is it better design to
put these here rather than repeating them inside both Member and Librarian classes?
2. Lifecycle Analysis: Explain the difference in lifecycle between a Section and a Book based on their
relationship diamonds (Filled vs. Empty) in this diagram.
3. Encapsulation: In Member, the outstandingFines attribute is Private (-), but payFine() is Public (+).
Explain how this protects the library from errors (e.g., a member setting their own fines to zero).
4. Method Parameters: The FineCalculator class has a method generateFine(l: Loan). Why do we
pass the whole Loan object as a parameter instead of just passing the number of overdue days?
5. Abstract Classes: If a developer tries to write code var item = new LibraryItem();, the compiler
will throw an error. Why is this restriction intentional in our design?
6. Association Classes: Explain why Loan connects to LibraryItem with a multiplicity of 0..1 on the
Item side (Logic: Can a physical book be on two loans at once?).
7. Data Types: In the DVD class, duration is an int (Integer). Why is this suitable for a movie length,
whereas fineAmount in other classes is a double?
8. Navigability: Librarian has a line to Loan. If you were coding the Librarian class, would you likely
include a method like getAllActiveLoans()? Explain based on the relationship.
9. Extensibility: If we wanted to add "AudioBooks" to the library, which class should it inherit from,
and why?
10. Dependency: FineCalculator does not have an attribute holding Loan data. It only uses it in a
method. What is the technical name for this "temporary" relationship?
SECTION C – SHORT ESSAY & DESIGN (10 Marks)
Question 1 (5 Marks)
The Library wants to introduce a Reservation System for popular books that are currently checked out. We
have defined a new class called Reservation with the following specification:
• Class Name: Reservation
• Attributes: - reservationDate: Date, - status: String
• Methods: + cancel(): void, + notifyMember(): void
Task: This new class acts as a link between a user and a resource, similar to Loan, but for the future.
a) Target Class 1: Which class represents the person making the reservation?
b) Target Class 2: Which class represents the object being reserved?
c) Relationship Type: What line would you draw between these classes and Reservation?
d) Multiplicity: Can a Member have multiple reservations? Can a Book have multiple reservations (a
queue)? State the numbers.
e) Justification: Why is Reservation a separate class and not just a "status" attribute inside the Book class?
Question 2 (5 Marks)
Draw/Describe a Use Case diagram for the Librarian and Member based on these requirements:
• Primary Actor: Member.
o Main Use Case: "Borrow Book".
o Constraint: The system must always "Check Overdue Fines" before allowing a borrow
(Use <<include>>).
o Option: The Member might ask to "Print Receipt" after borrowing, but not always
(Use <<extend>>).
• Primary Actor: Librarian.
o Main Use Case: "Register New Member".
o Constraint: The Librarian must always "Verify ID Proof" during registration
(Use <<include>>).
SECTION A – MULTIPLE CHOICE (Answer Key)
1. B (Filled Diamond indicates Composition).
2. A (Abstract classes cannot be instantiated; they are templates).
3. C (The minus sign - in UML denotes Private visibility).
4. B (Generalization allows children to inherit public/protected attributes and methods).
5. D (A Member can have Zero or Many loans).
6. B (The relationship requires data—Dates—that doesn't fit in Member or Item alone).
7. C (Dashed arrow is Dependency; it uses the Loan temporarily).
8. A (Composition implies the part dies with the whole).
9. B (Aggregation implies the part has an independent lifecycle).
10. C (Specialization; DVD adds specific features not found in the parent).
11. B (As shown in the Librarian class box).
12. B (Double represents a decimal number, suitable for currency).
13. D (As shown in the SystemUser class box: + login(): boolean).
14. A (A solid line represents a standard Association).
15. C (Inheritance passes methods down to all subclasses).
SECTION B – STRUCTURAL QUESTIONS (Marking Scheme)
1. Inheritance: Why put name/email in SystemUser?
• Answer: Code Reuse / DRY Principle. Instead of writing the code for name and email twice (once
in Member, once in Librarian), we define it once in the parent. It makes maintenance easier; if the
email format changes, we fix it in one place.
2. Lifecycle Analysis: Difference between Section and Book?
• Answer:
o Section (Composition): Has a dependent lifecycle. If the Library is deleted, the Sections
are deleted.
o Book (Aggregation): Has an independent lifecycle. If the Section is deleted, the Books
survive and can be moved elsewhere.
3. Encapsulation: Why is outstandingFines private but payFine public?
• Answer: Data Integrity/Validation. If outstandingFines were public, a user could set their debt to
0.00 without paying. The public payFine() method ensures the logic is followed (e.g., actually
receiving money before reducing the debt).
4. Method Parameters: Why pass the whole Loan object to FineCalculator?
• Answer: Access to Data. The calculator might need the dueDate, the currentDate, and perhaps
the ItemType (DVDs might have higher fines than Books). Passing the whole object ensures the
method has all the data it needs to do the math.
5. Abstract Classes: Why is new LibraryItem() restricted?
• Answer: Conceptual Logic. There is no such thing as a generic "Library Item" in the real world—
it must be a specific type of item (a Book or a DVD) to exist physically.
6. Association Classes: Why 0..1 multiplicity on the Item side of Loan?
• Answer: Physical Constraint. A specific physical book (identified by a unique barcode) can only
be in the possession of one person (on one active loan) at a time. It cannot be borrowed by two
people simultaneously.
7. Data Types: Why is duration int and fineAmount double?
• Answer: duration (minutes) is a count of whole numbers (you don't usually say 120.5
minutes). fineAmount represents currency, which requires decimal precision (e.g., $1.50) provided
by double.
8. Navigability: Would Librarian have getAllActiveLoans()?
• Answer: Yes. The line connects Librarian to Loan. This implies the Librarian needs to see, search,
or manage the loans to do their job.
9. Extensibility: Where would AudioBook fit?
• Answer: It should inherit from LibraryItem. It shares the base traits (title, barcode, location) but is
a distinct physical media format.
10. Dependency: Name of the temporary relationship?
• Answer: Dependency (or "Uses" relationship).
SECTION C – SHORT ESSAY & DESIGN (Marking Scheme)
Question 1: The Reservation System (5 Marks)
• a) Target Class 1: Member (The person asking).
• b) Target Class 2: LibraryItem (or Book/DVD).
o Note: Using Book is acceptable, but LibraryItem is better as it covers DVDs too.
• c) Relationship Type: Association (or Association Class).
• d) Multiplicity:
o Member (1) <----> (0..*) Reservation.
o LibraryItem (1) <----> (0..*) Reservation.
o Reasoning: A member can reserve many things. A popular book can have many reservations
(a waiting list/queue).
• e) Justification: A simple status string like "Reserved" inside the Book class is not enough because
it doesn't tell us WHO reserved it or WHEN their turn is. We need a separate class to track that
data.
Question 2: Use Case Diagram (5 Marks)
• Actors:
o Stick figure labeled Member.
o Stick figure labeled Librarian.
• Member Use Cases:
o Oval: Borrow Book.
o Oval: Check Overdue Fines.
o Arrow: <<include>> pointing FROM Borrow TO Check Fines.
o Oval: Print Receipt.
o Arrow: <<extend>> pointing FROM Print Receipt BACK TO Borrow Book.
• Librarian Use Cases:
o Oval: Register New Member.
o Oval: Verify ID Proof.
o Arrow: <<include>> pointing FROM Register TO Verify ID.