IGNOU MCS-219 Solved Question Paper PDF Download

IGNOU MCS-219 Previous Year Solved Question Paper in Hindi

IGNOU MCS-219 Previous Year Solved Question Paper in English

Q1. Design suitably an Hospital Management System which consists of several subsystems providing a variety of functions. Hospital Reception subsystem supports some of the job duties of the hospital receptionist. Receptionist schedules patient’s appointments and admission to the hospital, collects information from patient upon arrival or by phone. For inpatients (patients who _stay-in), gets a _ bed _ allotted. Receptionist may also get and process patient’s payments, record them and provide receipts. She is also responsible to file insurance claims and generate medical reports. Make necessary assumptions and perform the following tasks for the description given above. (a) Design and draw use case diagrams. (b) Provide description for at least two use cases. (c) Draw the class diagram of the system. (d) Draw the sequence diagram of system. (e) Draw the state diagram for appointment process. (f) What is abstract class ? Explain why abstract classes are created. (g) What are boundary conditions ? How are they dealt while designing the system.

Ans. Based on the description of the Hospital Reception subsystem, the design and analysis, with necessary assumptions, are as follows:

(a) Use Case Diagram

This diagram illustrates the interactions between users (actors) and the system. Actors:

• Receptionist: The primary actor who performs most of the system functions.
• Patient: The person for whom appointments and other services are provided.
• Insurance Company: An external entity to which insurance claims are sent.

Use Cases:

• Schedule Appointment
• Admit Patient
• Process Payment
• Allot Bed (can be an extension of ‘Admit Patient’)
• File Insurance Claim
• Generate Medical Report
• Manage Patient Information

Diagram Description:

A rectangular box represents the system boundary, titled ‘Hospital Reception Subsystem’. Outside the box, the actors Receptionist, Patient, and Insurance Company are depicted as stick figures. Inside the box, the use cases listed above are shown in ovals. The Receptionist actor is connected by lines to all these use cases, indicating they can initiate all these functions. There might be an

<<extend>>

relationship from the ‘Admit Patient’ use case to the ‘Allot Bed’ use case, as bed allotment is specific to inpatients.

(b) Description for at least two use cases

1. Use Case: Schedule Appointment

• Actor: Receptionist
• Description: This use case allows the receptionist to create, reschedule, or cancel an appointment for a patient with a doctor.
• Pre-conditions: The receptionist must be logged into the system. Doctor availability information must be accessible.
• Main Flow:
  1. Receptionist selects the option to schedule an appointment.
  2. The system prompts for patient information (new or existing).
  3. The receptionist enters the patient’s details.
  4. The system prompts for the selection of the required department/doctor.
  5. The receptionist selects the doctor.
  6. The system displays available time slots for the selected doctor.
  7. The receptionist selects a time slot and confirms the appointment.
  8. The system records the appointment and generates a confirmation message.
• Post-conditions: A new appointment is created in the system. The patient and doctor are notified.

2. Use Case: Admit Patient

• Actor: Receptionist
• Description: This use case allows the receptionist to admit a patient to the hospital as an inpatient.
• Pre-conditions: The receptionist is logged in. The patient has been recommended for admission by a doctor.
• Main Flow:
  1. The receptionist selects the patient admission option.
  2. The system requests the patient’s ID or name.
  3. The receptionist enters patient details and provides admission details (e.g., admission date, reason).
  4. The system checks for available beds. ( Extension point: Allot Bed )
  5. The receptionist selects an available bed and allocates it to the patient.
  6. The system generates a unique admission ID for the patient.
  7. The system updates the patient’s record as an inpatient.
• Post-conditions: The patient is admitted to the hospital, and a bed is allocated to them.

(c) Class Diagram

This diagram shows the static structure of the system, its classes, attributes, operations, and the relationships among them. Classes:

• Receptionist: staffID, name; login(), scheduleAppointment(), admitPatient()
• Patient: patientID, name, address, phone; getInfo()
• Appointment: appointmentID, dateTime, status; create(), cancel()
• Inpatient (inherits from Patient): admissionID, dateOfAdmission; getBed()
• Bed: bedID, roomNumber, status; allocate(), deallocate()
• Payment: paymentID, amount, paymentDate, paymentMode; processPayment(), generateReceipt()
• InsuranceClaim: claimID, patientID, amount, status; fileClaim()
• MedicalReport: reportID, patientID, details; generateReport()

Relationships:

• A Receptionist manages many Appointments (1-to-*).
• A Patient can have many Appointments (1-to-*).
• A Receptionist admits many Inpatients (1-to-*).
• An Inpatient is allocated one Bed (1-to-1).
• A Patient can make many Payments (1-to-*).
• Inpatient is a specialization (generalization) of the Patient class.

The diagram would show these classes as boxes containing their name, attributes, and operations, with lines indicating association, generalization, and multiplicity between them.

(d) Sequence Diagram

This diagram shows the interaction between objects over time. We will design a sequence diagram for the ‘Process Payment’ scenario. Objects: :Receptionist, :PaymentUI, :PaymentController, :Patient, :Receipt Sequence of Interactions:

1. The Receptionist calls `enterPaymentDetails(patientID, amount)` on the :PaymentUI .
2. The :PaymentUI calls `processPayment(patientID, amount)` on the :PaymentController .
3. The :PaymentController finds the patient by calling `find(patientID)` on the :Patient object.
4. The :Patient object returns its details.
5. The :PaymentController creates a new :Payment object `create(amount, date)`.
6. The :PaymentController calls `create(paymentDetails)` to create a :Receipt object.
7. The :Receipt object returns a `receiptID`.
8. The :PaymentController returns a success message to the :PaymentUI .
9. The :PaymentUI displays the receipt to the Receptionist .

This diagram would show objects as vertical lifelines and messages as horizontal arrows.

(e) State Diagram for Appointment process

This shows the lifecycle of an Appointment object. States:

• Scheduled: When the appointment is first created.
• Confirmed: When the patient confirms their attendance.
• Checked-In: When the patient arrives at the hospital.
• Completed: After the consultation with the doctor is finished.
• Cancelled: When the patient or receptionist cancels the appointment.
• No-Show: When the patient fails to arrive for the appointment.

Transitions:

• (creation) -> Scheduled
• Scheduled -[Confirm()]-> Confirmed
• Confirmed -[Patient Arrives]-> Checked-In
• Checked-In -[Consultation Ends]-> Completed
• Scheduled/Confirmed -[Cancel()]-> Cancelled
• Confirmed -[Appointment Time Passed]-> No-Show

The diagram would show these states as rounded rectangles and the transitions as arrows labeled with the triggering event/action.

(f) What is abstract class? Explain why abstract classes are created.

An abstract class is a class that cannot be instantiated directly, meaning you cannot create an object of it. It is designed to be inherited or sub-classed by other classes. An abstract class can contain both abstract methods (methods without an implementation) and concrete methods (methods with an implementation). Why abstract classes are created:

• To Define a Common Interface: It serves as a blueprint for a group of subclasses, defining a common interface. It forces all subclasses to implement certain methods, ensuring uniformity and enabling polymorphism.
• Code Reusability: It allows common attributes and behaviors among related classes to be placed in a single location. Subclasses can inherit this common functionality, reducing code duplication.
• Template Method Pattern: An abstract class can define the skeleton of an algorithm, while deferring some steps to be completed by subclasses. For example, in the hospital system, a `Person` abstract class could have common attributes like `name` and `address`. Concrete classes like `Patient` and `Doctor` could inherit from `Person` and add their own specific attributes and behaviors.

(g) What are boundary conditions? How are they dealt while designing the system.

Boundary conditions are the conditions that occur at the “edges” of the input domain of a system. They include the maximum and minimum allowed values, zero values, empty inputs, and error-generating situations. These are the points where a system’s behavior might change or fail. Examples:

• When allocating a bed, a boundary condition is ‘no beds available’.
• When processing a payment, a boundary condition could be ‘payment of zero amount’ or ‘payment exceeding a maximum limit’.
• When entering patient information, an empty string for the name is a boundary condition.

How boundary conditions are dealt with in system design:

• Input Validation: The system should be designed to ensure all inputs are within valid ranges. For example, age cannot be negative, and a phone number should contain only digits.
• Exception Handling: When a boundary condition leads to an error (like no beds available), the system should handle it gracefully instead of crashing. This is done using try-catch blocks or other error-handling mechanisms.
• Edge Case Testing: During the design and testing phases, special attention is paid to these boundary conditions (edge cases) to ensure the system behaves correctly in these scenarios.
• Handling Default and Null Values: The design must specify what happens when a value is not provided or is null.

Identifying and addressing these conditions early in the design is crucial for building a robust and reliable system.

Q2. (a) What are the different types of communication between objects ? Explain with examples. (b) What are the features of synchronization in UML ? Explain with an example. (c) Explain the purpose of state chart diagram. Give an example.

Ans. (a) Different types of communication between objects

Objects in an object-oriented system communicate with each other to perform tasks. The primary mechanism for this is message passing. Communication can be broadly categorized into two types: synchronous and asynchronous.

1. Synchronous Communication:
   • In synchronous communication, the sender object sends a message to a receiver object and then waits for the receiver to process the message and return a response. The sender’s execution is blocked until the response is received.
   • This is the most common form of communication, typically implemented as a standard method call .
   • Example: Consider a `ShoppingCart` object and a `Product` object. When the `ShoppingCart` wants to calculate the total price, it might call a `getPrice()` method on each `Product` object it contains. The `ShoppingCart` object sends the `getPrice()` message and waits for each `Product` to return its price before it can proceed with the summation. `totalPrice = product1.getPrice() + product2.getPrice();` Here, the `ShoppingCart` is blocked until `getPrice()` returns a value.
2. Asynchronous Communication:
   • In asynchronous communication, the sender object sends a message to a receiver object and immediately continues with its own execution without waiting for a response. The sender and receiver operate independently and concurrently.
   • This is common in event-driven systems, multi-threaded applications, and distributed systems. It is often implemented using message queues, callbacks, or event listeners.
   • Example: Consider a user clicking a ‘Download’ button in a graphical user interface (GUI). The `Button` object sends an asynchronous `startDownload` message to a `DownloadManager` object. The `Button` and the rest of the GUI do not freeze; the user can continue to interact with the application while the `DownloadManager` handles the download process in the background. When the download is complete, the `DownloadManager` might send another asynchronous message (an event) back to the GUI to update the status.

In UML, synchronous messages are shown with a solid-filled arrowhead, while asynchronous messages are shown with a stick arrowhead.

(b) Features of synchronization in UML

Synchronization in UML is used to coordinate the flow of control in activities that can occur concurrently. It is most prominently featured in Activity Diagrams and Sequence Diagrams to model parallel processing. The key features for managing synchronization are the fork and join nodes.

• Fork Node: A fork node is represented by a solid bar. It has one incoming transition and multiple outgoing transitions. When the flow of control reaches a fork, it splits into multiple concurrent flows, meaning the activities on the outgoing paths can be executed in parallel or in any order.
• Join Node: A join node is also represented by a solid bar. It has multiple incoming transitions and one outgoing transition. It synchronizes multiple concurrent flows. The flow of control can only proceed past the join node when all incoming flows have completed their activities and reached the join.
• Rendezvous: In sequence diagrams, a rendezvous is a point where messages from two different lifelines must arrive at a third lifeline before it can proceed. This is a form of synchronization.

Example: Consider an e-commerce “Order Fulfillment” process modeled in an Activity Diagram. 1. The process starts with “Receive Order”. 2. After the order is received, a fork node splits the process into two parallel activities:

• Activity A: “Process Payment”
• Activity B: “Package Items”

3. These two activities can happen at the same time.

4. Once “Process Payment” is complete, its flow reaches a

join

node.

5. Once “Package Items” is complete, its flow also reaches the same

join

node.

6. Only when

both

activities are complete and have reached the join node does the process continue with the single outgoing transition to the final activity, “Ship Order”.

This use of fork and join ensures that an order is not shipped until the payment has been successfully processed AND the items have been packaged.

(c) Purpose of a state chart diagram and an example

The primary purpose of a State Chart Diagram (also known as a State Machine Diagram) is to model the dynamic behavior of a single object throughout its lifecycle. It specifies the sequence of states an object goes through in response to external events. It is particularly useful for describing complex objects whose behavior depends on their history.

Key purposes:

• Modeling Object Lifecycle: It shows all possible states an object can be in, from its creation (initial state) to its destruction (final state).
• Visualizing State Transitions: It clearly depicts the events that trigger a change from one state to another (a transition).
• Specifying Actions: It can specify actions that are executed when an object enters a state, exits a state, or upon a specific transition.
• Understanding Complex Behavior: It helps in understanding and designing objects with intricate, state-dependent behavior, making the logic easier to manage and implement.

Example: A Simple Light Switch An object of class `LightSwitch` can be modeled with a state chart diagram.

• States: The switch has two possible states: Off and On .
• Events: The events that cause a change of state are `flipSwitch()`.
• Initial State: Let’s assume the switch is initially Off . This is shown by a solid circle pointing to the ‘Off’ state.
• Transitions:
  1. When the `LightSwitch` is in the Off state and receives the `flipSwitch()` event, it transitions to the On state.
  2. When the `LightSwitch` is in the On state and receives the `flipSwitch()` event, it transitions back to the Off state.

The diagram would show two rounded rectangles labeled “On” and “Off”. An arrow would go from “Off” to “On” labeled `flipSwitch()`, and another arrow would go from “On” to “Off” also labeled `flipSwitch()`. This simple diagram perfectly captures the complete behavior of a light switch object.

Q3. (a) Draw the component diagram for the online banking system. (b) Draw the deployment diagram for the ATM system. (c) What are the advantages of sequence diagram ? Explain with anexample.

Ans. (a) Component Diagram for an Online Banking System

A component diagram models the physical components of a system and their dependencies. It shows how the software is divided into reusable modules (components). For an Online Banking System, the components could be as follows:

Components:

• WebUI.jar: A JAR file containing all the user interface elements, servlets, and JSPs that render the web pages for the user.
• AccountMgmt.dll: A component (e.g., a DLL or a library) responsible for all account-related logic, such as viewing balances, statements, and user profiles.
• TransactionEngine.exe: A core processing engine that handles all financial transactions, like fund transfers, bill payments, etc. It ensures the atomicity and integrity of transactions.
• AuthService.jar: A component dedicated to user authentication and authorization, managing logins, sessions, and access rights.
• DatabaseConnector.lib: A library component that provides an interface for other components to communicate with the database. It encapsulates the JDBC/ODBC logic.

Interfaces and Dependencies (Diagram Description): The diagram would show each component as a rectangle with a small component icon (a rectangle with two smaller rectangles protruding from its side).

• The WebUI.jar component would have a dependency (a dashed arrow) on the AuthService.jar for user login.
• WebUI.jar would also depend on AccountMgmt.dll to display account information and on TransactionEngine.exe to initiate transactions.
• The AccountMgmt.dll component would provide an interface, say `IAccount`, which is represented by a small circle (a “lollipop”). The WebUI.jar component would use this interface.
• Similarly, TransactionEngine.exe would provide an `ITransaction` interface.
• Both AccountMgmt.dll and TransactionEngine.exe would depend on the DatabaseConnector.lib component to persist and retrieve data from the bank’s database.

This diagram helps developers understand the system’s architecture, promotes reusability, and makes system maintenance easier by isolating functionalities into separate components.

(b) Deployment Diagram for an ATM System

A deployment diagram models the physical deployment of software artifacts on hardware nodes. It shows the runtime configuration of a system.

Nodes (Hardware):

• ATM Machine: The physical client machine with a screen, keypad, card reader, and cash dispenser.
• Bank Application Server: A central server that hosts the main banking application logic.
• Database Server: A server dedicated to hosting and managing the bank’s database.

Artifacts (Software):

• ATMClient.exe: The client application software running on the ATM Machine.
• TransactionProcessor.jar: The server-side application artifact deployed on the Bank Application Server that processes transaction requests.
• BankDB: The database schema/instance running on the Database Server.

Diagram Description: The diagram would show three large cubes representing the nodes: `ATM Machine`, `Bank Application Server`, and `Database Server`.

• Inside the `ATM Machine` node, there would be a smaller rectangle representing the artifact ATMClient.exe .
• Inside the `Bank Application Server` node, there would be an artifact TransactionProcessor.jar .
• Inside the `Database Server` node, there would be an artifact BankDB .
• A solid line would connect the `ATM Machine` and the `Bank Application Server`, labeled with the communication protocol (e.g., `TCP/IP` or `HTTPS`), indicating a network connection.
• Another solid line would connect the `Bank Application Server` and the `Database Server`, labeled with a protocol like `JDBC`, indicating the database connection.

This diagram is crucial for system administrators and deployment teams to understand the physical architecture, network requirements, and software distribution.

(c) Advantages of Sequence Diagram

A sequence diagram is an interaction diagram that shows how objects collaborate in a time-ordered sequence. It provides several advantages in system analysis and design:

1. Clear Visualization of Interaction Logic: It provides a clear, step-by-step visual representation of a specific scenario or use case. This makes it easy to understand the flow of control and messages between objects, which can be difficult to grasp from static diagrams alone.
2. Understanding Object Responsibilities: By showing which objects receive and send which messages, a sequence diagram helps in assigning responsibilities to classes. If one object’s lifeline is overly crowded with messages, it might indicate that the class has too many responsibilities (low cohesion) and needs to be refactored.
3. Easy Transition to Code: The detailed sequence of method calls shown in the diagram maps closely to the code that needs to be written. Developers can use it as a blueprint for implementing methods in classes.
4. Identifying Potential Bottlenecks: It can help in identifying potential performance issues. For example, a long sequence of synchronous calls or excessive communication between objects might indicate a design that could be slow.
5. Modeling Complex Scenarios: They are excellent for modeling complex interactions involving multiple objects, loops, conditional logic (using `alt` and `opt` fragments), and concurrent operations.

Example: User Login Consider a sequence diagram for a user login process with objects `:LoginScreen`, `:LoginController`, and `:UserDatabase`.

1. The `User` (actor) enters credentials into `:LoginScreen`.
2. `:LoginScreen` sends a `login(username, password)` message to `:LoginController`.
3. `:LoginController` then sends a `validateUser(username, password)` message to `:UserDatabase`.
4. `:UserDatabase` checks the credentials and returns a `true` or `false` value to `:LoginController`.
5. `:LoginController` receives the response. Based on the result (using an `alt` fragment for if/else), it sends either a `showSuccess()` message or a `showError()` message back to `:LoginScreen`.

This simple diagram clearly shows the time-ordered flow of method calls required for a user to log in, making the logic unambiguous for designers and developers.

Q4. (a) Explain generalization-specialization relationship with an example. (b) Describe the dynamic model with an example. (c) What do you understand by a DFD (Data Flow Diagram) ? Explain the use of DFDs with an example.

Ans. (a) Generalization-Specialization Relationship

A generalization-specialization relationship is a fundamental concept in object-oriented modeling that represents an “is-a-kind-of” or “is-a” relationship between classes. It is implemented in programming languages through inheritance .

• Generalization is the process of extracting common properties (attributes) and behaviors (methods) from a set of classes and placing them in a more general superclass.
• Specialization is the process of creating more specific subclasses from an existing general class. The specialized subclass inherits all the properties and behaviors of the general superclass and can add its own unique properties and behaviors or override inherited behaviors.

This relationship helps in creating a hierarchy of classes, promoting code reuse and reducing redundancy. In UML class diagrams, this relationship is represented by a solid line with a hollow arrowhead pointing from the specialized class (subclass) to the generalized class (superclass).

Example: Vehicle Hierarchy

Consider a system that deals with different types of vehicles.

• Generalization (Superclass): We can define a general class called `Vehicle` . This class would contain attributes and methods common to all vehicles, such as:
  • Attributes: `licensePlate`, `maxSpeed`, `color`
  • Methods: `start()`, `stop()`, `accelerate()`
• Specialization (Subclasses): We can then create specialized classes that inherit from `Vehicle`.
  • `Car` is a `Vehicle`. It inherits all attributes and methods from `Vehicle` and adds its own specific ones, like `numberOfDoors` and a method `openTrunk()`.
  • `Motorcycle` is also a `Vehicle`. It inherits from `Vehicle` and adds specific attributes like `hasSidecar` and might override the `accelerate()` method to behave differently than a car’s acceleration.
  • `Truck` is another `Vehicle`. It could add an attribute `cargoCapacity` and a method `loadCargo()`.

In this example, `Vehicle` is the generalization, while `Car`, `Motorcycle`, and `Truck` are its specializations. This structure makes the model more organized and allows for polymorphism, where an object of a subclass can be treated as an object of its superclass.

(b) The Dynamic Model with an Example

The dynamic model is a part of a complete system model that describes the behavior of the system over time. It contrasts with the static model (like the Class Diagram), which describes the structure of the system. The dynamic model focuses on the control flow, interactions, and state changes within the system. It answers questions like “What happens when?” and “In what order do things happen?”.

The primary UML diagrams used to represent the dynamic model are:

• Sequence Diagrams: Show time-ordered interactions between a set of objects.
• Communication Diagrams: Also show interactions but focus on the relationships between objects rather than the time sequence.
• State Chart Diagrams: Model the lifecycle of a single object, showing its states and the transitions between them.
• Activity Diagrams: Model the flow of activities in a process or operation, including concurrent and conditional flows.

Example: Dynamic Model of an Online Order Let’s describe the dynamic behavior of an `Order` object in an e-commerce system using a State Chart Diagram .

An `Order` object doesn’t stay static; its state changes based on events.

• Initial State: The process starts, and the order is created, entering the `Pending` state.
• State: `Pending`
  • Event: `makePayment()` -> Transition to `Paid` state.
  • Event: `cancelOrder()` -> Transition to `Cancelled` state.
• State: `Paid`
  • Event: `shipItems()` -> Transition to `Shipped` state.
• State: `Shipped`
  • Event: `confirmDelivery()` -> Transition to `Delivered` state.
• State: `Delivered`
  • This is often a final state for the positive flow.
• State: `Cancelled`
  • This is also a final state.

This state chart diagram is part of the dynamic model. We could also create a sequence diagram for the `makePayment()` event, showing how the `Order` object interacts with a `PaymentGateway` object and a `Customer` object to complete the payment. Together, these diagrams provide a comprehensive view of the system’s behavior.

(c) DFD (Data Flow Diagram) and its use

A Data Flow Diagram (DFD) is a graphical representation of the “flow” of data through an information system. It is a key tool in structured analysis and design , focusing on what the system does (the processes) and the data it uses, rather than how it does it. DFDs are used to model a system from a data perspective.

A DFD has four main components:

1. Process: An activity or function that transforms data. Represented by a circle or a rounded rectangle. (e.g., ‘Validate Payment’).
2. Data Flow: The movement of data between processes, data stores, and external entities. Represented by an arrow. (e.g., ‘Payment Details’).
3. Data Store: A repository of data. Represented by two parallel lines or an open-ended rectangle. (e.g., ‘Orders’ database).
4. External Entity (or Terminator): An external system, person, or organization that sends data to or receives data from the system. Represented by a rectangle. (e.g., ‘Customer’).

Use of DFDs: DFDs are used to understand and analyze the data requirements of a system. They can be created at different levels of detail. A Level 0 DFD (or Context Diagram) shows the entire system as a single process interacting with external entities. Higher-level DFDs (Level 1, Level 2, etc.) decompose processes into more detailed sub-processes, providing a layered view of the system.

Example: Simple Library Book Issue System (Level 1 DFD)

• External Entities: `Member`
• Processes:
  1. `Check Member Status`
  2. `Check Book Availability`
  3. `Issue Book`
• Data Stores: `Member Records`, `Book Inventory`

Flow: 1. A `Member` provides a `Member ID` and `Book ID` to the system. 2. The `Member ID` flows to the `Check Member Status` process, which reads from the `Member Records` data store. It outputs a `Member Status` (e.g., ‘Valid’ or ‘Expired’). 3. The `Book ID` flows to the `Check Book Availability` process, which reads from the `Book Inventory` data store. It outputs a `Book Status` (e.g., ‘Available’). 4. If both statuses are valid, the `Member ID` and `Book ID` flow to the `Issue Book` process. 5. The `Issue Book` process updates both the `Book Inventory` (marks book as issued) and `Member Records` (adds book to member’s issued list). 6. A `Receipt` data flow is sent back to the `Member`. This DFD clearly shows how data moves through the book issuing process without specifying the underlying technology or implementation details.

Q5. (a) Differentiate between Coupling and Cohesion. (b) What is object ID ? What are the advantages of using it ? (c) Explain two-way associations in design model. (d) Differentiate between Aggregation and Composition. Also, give an example for each.

Ans. (a) Differentiate between Coupling and Cohesion

Coupling and Cohesion are two fundamental metrics used to measure the quality of a software design. The goal of a good design is to have low coupling and high cohesion .

Coupling:

• Definition: Coupling refers to the degree of interdependence between software modules (e.g., classes or components). It measures how closely connected two modules are.
• Goal (Low Coupling): In a low-coupled system, a change in one module will have a minimal impact on other modules. Modules are largely independent. This makes the system easier to maintain, test, and reuse.
• High Coupling (Bad): If two classes are highly coupled, a change in Class A forces a change in Class B. For example, if Class B directly accesses the internal data members of Class A instead of using public methods, they are tightly coupled.

Cohesion:

• Definition: Cohesion refers to the degree to which all elements inside a single module belong together. It measures how focused a module is on a single, well-defined task or responsibility.
• Goal (High Cohesion): In a highly cohesive module, all its elements (methods, attributes) work together to achieve a single purpose. The module is focused and easy to understand.
• Low Cohesion (Bad): A class with low cohesion performs many unrelated tasks. For example, a single class that handles user authentication, database connections, and logging has low cohesion. It would be better to separate these responsibilities into different classes (`Authenticator`, `DBManager`, `Logger`).

Analogy: Think of a team of employees. High cohesion means each employee is an expert in their specific job and is not distracted by other tasks. Low coupling means the employees can do their jobs without constantly needing to check in with or depend on every other employee in the company.

(b) What is object ID ? What are the advantages of using it ?

An Object ID (OID) , or object identifier, is a unique, system-generated identity assigned to an object when it is created. This identity remains constant for the entire lifetime of the object, regardless of any changes to the object’s state (its attribute values) or its physical location in memory or storage.

An OID is conceptually similar to a primary key in a relational database, but it is for an object and is typically managed by the object-oriented system (like an OODBMS) itself, transparently to the user.

Advantages of using Object IDs:

1. Uniqueness and Immutability: The OID provides an unambiguous way to refer to an object. It distinguishes between two different objects even if they have the exact same attribute values (e.g., two different `Person` objects both named “John Smith”).
2. Efficient Object Retrieval: OIDs can be used to look up and retrieve objects very quickly, often more efficiently than querying based on attribute values, as the OID can map directly to the object’s physical storage location.
3. Maintaining Referential Integrity: Relationships between objects can be managed using OIDs. If Object A contains a reference to Object B, it stores Object B’s OID. This ensures that the link remains valid even if Object B’s attributes or location change. It prevents the “dangling pointer” problem.
4. Location Independence: Since the OID is a logical identifier, the system can move the object in memory or across different storage devices without breaking references to it from other objects. The system simply updates its internal mapping of the OID to the new location.

(c) Explain two-way associations in design model.

A two-way association , also known as a bidirectional association , is a relationship between two classes where each class is aware of the other and can navigate to the associated object(s). In essence, information about the relationship is maintained in both directions.

In a UML class diagram, a two-way association is represented by a solid line between two classes, without any arrowheads (or sometimes with arrowheads at both ends). The multiplicity (e.g., 1, *, 0..1) can be specified at both ends of the association.

Implementation: To implement a two-way association, each class must hold a reference (or a collection of references) to the object(s) of the other class.

• For a one-to-one association, each class has a single attribute referencing the other.
• For a one-to-many association, one class has a single reference, and the other class has a collection (e.g., a list or set) of references.

Example: Student and Course Consider the relationship between a `Student` and a `Course`.

• A `Student` can enroll in multiple `Course`s.
• A `Course` can have multiple `Student`s enrolled.

This is a many-to-many two-way association.

• The `Student` class would have an attribute like `List<Course> enrolledCourses;` to navigate to the courses they are taking.
• The `Course` class would have an attribute like `List<Student> enrolledStudents;` to navigate to the students in that course.

This bidirectional navigation is useful. From a `Student` object, you can easily find all their courses. From a `Course` object, you can easily get a class roster. The main challenge with two-way associations is maintaining consistency. When a student enrolls in a course, you must update both the student’s list and the course’s list to keep the relationship intact.

(d) Differentiate between Aggregation and Composition. Also, give an example for each.

Aggregation and Composition are both specialized types of association that represent a “has-a” or “part-of” relationship. They describe how a “whole” object is related to its “part” objects. The key difference lies in the strength of the relationship and the lifetime dependency between the whole and its parts.

Aggregation:

• Relationship: A weaker “has-a” relationship. It represents a whole-part connection where the part can exist independently of the whole.
• Lifetime: The lifetime of the part object is not tied to the lifetime of the whole object. If the whole object is destroyed, the part object can still exist.
• UML Notation: A solid line from the whole to the part, with an unfilled (hollow) diamond on the “whole” side.
• Example: A Department and its Professors. A `Department` “has” `Professor`s. This is aggregation because a `Professor` is part of a `Department`, but if the `Department` is closed down, the `Professor`s do not cease to exist. They can be reassigned to another department or simply exist without a departmental affiliation for a while.

Composition:

• Relationship: A stronger “has-a” relationship. It represents a whole-part connection where the part cannot exist independently of the whole. The part is exclusively owned by the whole.
• Lifetime: The lifetime of the part object is tied to the lifetime of the whole object. If the whole object is destroyed, all its constituent part objects are also destroyed.
• UML Notation: A solid line from the whole to the part, with a filled (solid) diamond on the “whole” side.
• Example: A House and its Rooms. A `House` “has” `Room`s. This is composition because a `Room` cannot exist without a `House`. The rooms are an integral part of the house. If you destroy the `House`, the `Room`s within it are also destroyed. A specific room cannot be part of two different houses at the same time.