# Exam Solutions
## PART I : OOM
### Section A : Multiple Choice Questions
1. B) Unified Modeling Language
2. C) Class Diagram
3. C) Component Diagram
4. A) Polymorphism
5. D) Interface
6. B) Singleton
7. C) Realization
8. C) Actor
9. A) Strategy
10. B) Deployment Diagram
### Section B : Structural Questions
#### I. True or False
1. False (Class diagrams show static structure, sequence diagrams show
object interaction)
2. True
3. True
4. False (Observer is a behavioral pattern)
5. False (UML can be used for non-software systems too)
#### II. Fill in the Blanks
1. Package
2. Deployment
3. Factory Method
4. Polymorphism
5. Dependency
#### III. Short Answer Questions
1. **Singleton Design Pattern** : Ensures a class has only one instance
and provides a global point of access to it. Example : A configuration
manager in an application where all parts need access to the same
configuration settings.
2. **Aggregation vs Composition** :
- Aggregation is a « has-a » relationship where the child can exist
independently of the parent (e.g., Department-Professor).
- Composition is a stronger « part-of » relationship where the child
cannot exist without the parent (e.g., House-Room).
### Section C : Answer any two questions
#### Question 1 : Library Management System UML Model
a) **Use Case Diagram** :
- Actors : Librarian, Member
- Use Cases : Borrow Item, Return Item, Reserve Item, Manage Catalog
(for Librarian)
- Relationships : Librarian can perform all actions, Member can
Borrow/Return/Reserve
b) **Class Diagram** :
- Classes : User (abstract), Librarian, Member, Item (abstract), Book,
Magazine, Loan, Reservation
- Relationships :
- Inheritance : Librarian/Member extend User ; Book/Magazine extend
Item
- Association : User borrows Item through Loan
- Composition : Loan contains Item and User
c) **Design Rationale** :
- Abstract classes (User, Item) allow for extensibility
- Separate Loan class tracks borrowing history
- Polymorphism allows treating different item types uniformly
#### Question 2 : Notification System Design Pattern
**Suitable Pattern** : Factory Method or Abstract Factory
**Justification** :
- Need to create different notification types based on user preferences
- Decouples notification creation from the client code
- Easy to add new notification types without modifying existing code
**Class Diagram** :
- Notification (interface/abstract class)
- Concrete notifications : EmailNotification, SMSNotification,
PushNotification
- NotificationFactory (abstract) with createNotification() method
- Concrete factories for each notification type
**Benefits** :
- Follows Open/Closed Principle
- Centralizes creation logic
- Makes testing easier
- Simplifies adding new notification types
## PART 2 : OOP
### Section A : Multiple Choice Questions
1. d. All the above
2. c. Structured and unstructured
3. d. All of these
4. b. Architectural design
5. b. Use case
6. (Figure not shown, cannot answer)
7. b. #include « userdefined »
8. d. Friend constructor
9. c. Inheritance
10. b. A class must contain at least one pure virtual function
### Section B : Chat App Questions
1. **Use Case Diagram Components** :
- Actors (users or external systems)
- Use Cases (system functionalities)
- Relationships (association, include, extend, generalization)
- System Boundary
2. **Proposed Use Case Diagram** :
- Actors : User
- Use Cases : Send Message, Receive Message, Add User to Chat,
Remove User from Chat
- Relationships : User can perform all use cases
2. **Classes Table** :
| Class | Attributes | Methods |
| User | id, username | Constructor, getters, setters
|
| Message | id, sender, receiver, content, time | Constructor, getters,
setters |
| Chat | id, users, messages | AddUser(), RemoveUser(),
SendMessage() |
4. **Class Diagram** :
- User class with attributes/methods
- Message class with attributes/methods and associations to User
(sender, receiver)
- Chat class with attributes/methods and associations to User and
Message
- Multiplicity : Chat has 2..* Users, has 0..* Messages
5. **User Class Implementation** :
```cpp
Class User {
Private :
Int id ;
String username ;
Static int nextId ;
Public :
User(string name) {
Username = name ;
Id = nextId++ ;
// Getters
Int getId() { return id ; }
String getUsername() { return username ; }
// Setters
Void setUsername(string name) { username = name ; }
};
Int User ::nextId = 1 ;
```
6. **Message Class Implementation** :
```cpp
Class Message {
Private :
Int id ;
User* sender ;
User* receiver ;
String content ;
Time_t timestamp ;
Public :
Message(User* s, User* r, string c) {
Sender = s ;
Receiver = r ;
Content = c ;
Timestamp = time(0) ;
// Getters
Int getId() { return id ; }
User* getSender() { return sender ; }
User* getReceiver() { return receiver ; }
String getContent() { return content ; }
Time_t getTimestamp() { return timestamp ; }
// Setters
Void setContent(string c) { content = c ; }
};
```
8. **SendMessage Implementation** :
```cpp
Void Chat ::SendMessage(User* sender, User* receiver, string content) {
// Verify both users are in this chat
Bool senderFound = false, receiverFound = false ;
For (User* u : users) {
If (u == sender) senderFound = true ;
If (u == receiver) receiverFound = true ;
}
If (senderFound && receiverFound) {
Message* msg = new Message(sender, receiver, content) ;
Messages.push_back(msg) ;
} else {
Throw « Sender or receiver not in this chat » ;
```
