DEPARTMENT OF COMPUTER SCIENCE AND SOFTWARE
ENGINEERING
Software Design Methodologies
FALL 2023
ASSIGNMENT - 1
Prof: DR. REZA MIRSALARI
Chandra Sagar Reddy Sangu (40234194)
Munj Bhavesh Nayak (40195590)
Saiteja Gattu (40233461)
Objective :
To assess your understanding and application of various software design methodologies,
principles, and design patterns in a real-world scenario, challenging you to devise a resilient and adaptive
software design solution. Scenario: Intelligent Hospital Management System (IHMS) A local government
health agency has recognized the need to overhaul its current Hospital Management System to
accommodate the growing technological advancements and provide seamless healthcare experiences. The
new system, termed as the Intelligent Hospital Management System (IHMS), aims to streamline
healthcare processes, enable efficient management of hospital resources, and enhance patient care through
intelligent solutions.
Scenario:
Intelligent Hospital Management System (IHMS) A local government health agency has
recognized the need to overhaul its current Hospital Management System to accommodate the growing
technological advancements and provide seamless healthcare experiences. The new system, termed as the
Intelligent Hospital Management System (IHMS), aims to streamline healthcare processes, enable
efficient management of hospital resources, and enhance patient care through intelligent solutions.
Assignment Tasks
Task 1 : Propose an object-oriented design to handle the different entities and functionalities
involved in IHMS.
The list of classes are as follows.
User Management
● User(Base class)
○ Patient
○ Doctor
○ Pharmacist
○ Admin
User class:
Responsibilities:
● Represent a generic user with basic authentication information.
● Serve as a base class for more specialized user types (Patient, Doctor, Admin, Pharmacist).
Attributes:
● User_id
● Username
● Password
● Email
● Phone number
Methods:
● Login()
● Logout()
● View_Profile()
● Change_Password()
Doctor Class:
Responsibilities:
● Manage doctor-specific operations, including confirming/rescheduling appointments and
viewing patient history.
● Maintain information about the doctor's schedule, appointments, and availability.
Attributes:
● Speciality
● Qualifications
Methods:
● View Medical records()
● Update medical records()
● Give prescription()
● View schedule()
● Adjust schedule()
Patient class:
Responsibilities:
● Manage patient-specific operations, such as booking appointments, viewing medical history,
and making payments.
● Hold information about the patient's medical history, appointments, payments, and
notifications.
Attributes:
Methods:
● Book Appointment()
● View medical records()
● View bill()
● Make payments()
● Get notifications()
● Register()
Admin class:
Responsibilities:
● Handle administrative operations like system configuration, user management, and updates.
● Maintain information about system configurations, deployed updates, and user management
logs.
Attributes:
Methods:
● Configure system
● Manage users
● Deploy updates
● Log activity
Pharmacist class:
Responsibilities:
Managing medicine stock levels.
● Generating orders to suppliers.
●
●
●
Receiving and updating medicine stock.
Interacting with patients and doctors for medication needs.
Handling notifications about stock levels.
Attributes:
● pharmacist_id
Methods:
● manageStock
● generateOrder
● receiveOrder
● generateReceipt
● despenseMedicine
Appointment Management
● Appointment
Appointment Class:
Responsibilities:
● Handel all things related to appointment including but not limited to view, adjust, reschedule
and delete appointments.
● Notifying users about upcoming appointments and any modifications to it.
Attributes:
● Appointment id
● Doctor
● Patient
● Date
● Status
Methods:
● Appointment scheduler
● Push Notification
Medical Records Management
● Medical Record
● Diagnosis
● Prescriptions
● Notes
Medical Records class:
Responsibilities:
- Responsibilities:
● Storing and managing patient medical history, including diagnoses, prescriptions, and notes.
● Providing authorized access to medical records for doctors and patients.
● Ensuring data security and privacy of medical records.
Attributes:
● record_id
● patient (reference to Patient object)
● doctor (reference to Doctor object)
● diagnoses (list of Diagnosis objects)
● prescriptions (list of Prescription objects)
●
Methods:
●
●
notes (list of Note objects)
Update Records
View Records
Diagnosis class:
Responsibilities:
● Store and manage information about a specific diagnosis, including the doctor, patient, date,
symptoms, findings, prescriptions, and notes.
● Update the diagnosis whenever required
Attributes:
● Diagnosis id
● Diagnosis description
Prescription class:
Responsibilities:
● Maintain records of all the prescriptions the patient has been given including list of medicine,
dosage
Attributes:
● Prescription id
● Medication(Refers to medicine class)
● Dosage
Notes class:
Attributes:
● Notes id
● description
Billing and Payments
● Bill
● Payment
Bill class:
- Responsibilities:
● Generating bills automatically based on the services provided.
● Managing patient billing information.
● Supporting various payment methods.
● Handling billing-related notifications and payments.
Attributes:
● bill_id
● patient (reference to Patient object)
● total_amount
● status (e.g., unpaid, paid)
Payment class:
Responsibilities:
● Initiate payment and maintain payment records
● Updating the payment status and notifying the user
● Handling multiple modes of payment and if necessary handling refund process
Attributes:
● payment_id
● patient (reference to Patient object)
● amount
● timestamp
Notifications and Alerts
● Notification
Notification class:
Responsibilities:
● Sending automated notifications to patients and healthcare providers.
● Managing notification delivery and read status.
● Providing relevant information about appointments, billing, and stock levels.
Attributes:
● notification_id
● recipient (reference to User object)
● content
● timestamp
Medical Stock Management
● Medicine
● Medicine Stock
● Medicine Order
Medicine class:
Responsibilities:
● Checking price and expiration of each medicine
● Checking the stock quantity and comparing to threshold. If below threshold notifying the
pharmacist and automating the order to supplier
Attributes:
● medicine_id
● name
● description
● stock_quantity
● threshold_quantity
● unit_price
● expiration
Methods:
● checkExpiration()
● checkPrice()
● checkquantity()
● checkDescription()
Medicine Stock class:
Responsibilities:
● Maintaining real-time data about medicine stock levels.
● Generating automated orders to suppliers when stock levels reach a predefined threshold.
● Managing medicine stock updates and interactions with pharmacists.
Attributes:
● medicine (reference to Medicine object)
● pharmacist (reference to Pharmacist object)
● quantity
Medicine order class:
Responsibilities:
● Managing the order and delivery of medicines from suppliers.
● Confirming and receiving medicine orders.
● Updating the stock levels upon receiving orders.
Attributes:
● order_id
● pharmacist (reference to Pharmacist object)
● medicine (reference to Medicine object)
● quantity
● order_status (e.g., pending, delivered)
System Configuration and Logging
● Classes:
○ SystemConfiguration
■ Methods for configuring system parameters.
○ SystemLogger
■ Methods for logging user activities and system events.
● 8. Security and Authentication
○ SecurityManager:
■ Methods for user authentication and data security.
● 9. External Systems Integration:
●
○ Classes or interfaces to interact with external systems like the Patient Notification
System and Pharmacy Stock Management System.
● 10. Main Application:
IHMS class or module to orchestrate interactions between various components and manage the main
application logic.
Task 2: Develop a comprehensive design class diagram showcasing all entities, relationships,
attributes, methods, and interactions within the system.
Task 3: Identify and design controller classes to manage the flow of data between the user interface
and the system.
Identify and design controller classes to manage the flow of data between the user interface and the
system
UserController:
Responsibilities:
● Manage user authentication and authorization.
● Handle user registration and login.
● Route user requests to appropriate functionalities based on user roles (e.g., Patient, Doctor,
Admin, Pharmacist).
Methods:
● registerUser(userDetails)
● login(username, password)
● logout()
● getUserProfile()
● updateUserProfile(userDetails)
AppointmentController:
Responsibilities:
●
●
●
Methods:
Manage appointment booking and scheduling.
Handle appointment-related actions, such as confirmation and cancellation.
Provide the UI with information about available appointments.
● viewAvailableAppointments(doctorId, dateRange)
● bookAppointment(patientId, doctorId, dateTime)
● cancelAppointment(appointmentId)
● confirmAppointment(appointmentId)
MedicalRecordController:
Responsibilities:
● Manage access to patient medical records.
● Handle the addition of diagnoses, prescriptions, and notes to medical records.
Methods:
● viewMedicalRecord(patientId)
● addDiagnosis(patientId, doctorId, diagnosisDetails)
● addPrescription(patientId, doctorId, prescriptionDetails)
● addNote(patientId, doctorId, noteDetails)
BillingController:
Responsibilities:
● Generate bills for services provided.
● Handle payment processing.
Methods:
● generateBill(patientId, servicesProvided)
● makePayment(patientId, amount)
● viewBills(patientId)
● viewPaymentHistory(patientId)
NotificationController:
Responsibilities:
●
●
Methods:
Manage notifications and alerts.
Handle the delivery of notifications to users.
● sendNotification(userId, notificationDetails)
● viewNotifications(userId)
● markNotificationAsRead(notificationId)
MedicineStockController:
Responsibilities:
● Manage medicine stock levels.
● Generate and process orders to replenish stock.
● Handle interactions with the pharmacy.
Methods:
● viewMedicineStock(pharmacistId)
● addStock(pharmacistId, medicineId, quantity)
● updateStock(pharmacistId, medicineId, quantity)
● checkThreshold(medicineId)
● generateOrder(pharmacistId, medicineId, quantity)
● receiveOrder(pharmacistId, orderId)
SystemAdminController:
Responsibilities:
● Configure system parameters.
● Manage user access rights.
● Handle system updates.
Methods:
● configureSystem(parameters)
● manageUserAccess(userId, permissions)
● deploySystemUpdate(updateDetails)
● viewSystemLogs()
Task 4 : Identify and design boundary classes for interaction between the system and the external
entities.
PatientBoundary:
- Responsibilities:
- Facilitate interactions between patients and the IHMS system.
- Handle patient registration and login.
- Provide a user-friendly interface for patients to book appointments, view medical records, and
make payments.
- Methods:
- registerPatient(patientDetails)
- login(username, password)
- viewAppointments()
- bookAppointment(doctorId, dateTime)
- viewMedicalRecord()
- makePayment(billId, amount)
- viewNotifications()
DoctorBoundary:
- Responsibilities:
- Serve as an interface for doctors to interact with the IHMS system.
- Provide functionality for doctors to view their schedules, access patient medical histories, and
manage appointments.
- Methods:
- login(username, password)
- viewSchedule()
- updateAvailability(timeSlots)
- viewPatientMedicalRecord(patientId)
- receiveAppointmentRequest(appointmentDetails)
PharmacistBoundary:
- Responsibilities:
- Handle interactions between pharmacists and the IHMS system.
- Provide a user interface for pharmacists to manage medicine stock and orders.
- Methods:
- login(username, password)
- viewMedicineStock()
- addStock(medicineId, quantity)
- updateStock(medicineId, quantity)
- checkThreshold()
- generateOrder(medicineId, quantity)
- receiveOrder(orderId)
SupplierBoundary:
- Responsibilities:
- Represent the interface for IHMS to interact with medicine suppliers.
- Manage the process of placing orders with suppliers.
- Methods:
- viewCatalog()
- placeOrder(orderDetails)
NotificationBoundary:
- Responsibilities:
- Handle communication between the IHMS system and external entities regarding notifications
and alerts.
- Methods:
- sendNotification(recipientId, notificationDetails)
- viewNotifications(userId)
ExternalSystemBoundary:
- Responsibilities:
- Represent the interface for IHMS to interact with external systems, such as the Patient
Notification System and Pharmacy Stock Management System.
- Manage data exchange and integration with these external systems.
- Methods:
- sendDataToPatientNotificationSystem(data)
- receiveDataFromPharmacyStockSystem(data) .
Task 5 : Identify and design entity classes representing the main actors and objects in the scenario.
●
●
●
●
Entity classes are classes that represent real world entities, objects or concepts
entity classes represent main actors and objects involved in the problem domain.
The entity classes for IHMS are as follows: User, patient, doctor, Admin, Pharmacist,
Medicine, appointment, MedicalRecords, bill, payment,notification, MedicineStock,
MedicineOrder.
The Class representation of each of these can be found in Taks 1 and Task 2.
Task 6 : Clearly define the responsibility of each object within your design
The responsibilities of each object is defined in task one
Task 7 : Ensure that every class and method has a single responsibility and there is a clear
separation of concerns
As described in task one, each class has only one responsibility and it is clearly defined. For example, the
classes patient , doctor, pharmacist have very specific attributes and methods the are unique to each of
them. The class patient represents a realtime patient, it concerns only about the patient.
Each class handles specific tasks as mentioned int its responsibilities. We also catagorize all the classes
into specific categories based on their responsibilities. For example, the classes doctor, patient, pharmacist
deal with human end users. Where as the classes medical records, prescription, diagnosis, notes deal with
medical records and their preservation, updation.
Task 8: Implement stable intermediary structures to absorb the variations in your design
Stable intermediary structures act as a intermediary between two or more components of the system to
create a stable point of interaction. In IHMS boundary classes such as patientBoundary, DoctorBoundary,
SupplierBoundary etc act as stable intermediary structures. They enable smooth interaction between
external systems with internal ones as well as two or more internal classes.
Also we can have stable intermediary structures such as appointmentMediator to absorb variations
between Appointment class and notification class
AppointmentMediator class:
Attributes:
Methods:
● scheduleAppointment()
● notifyPatient()
● notifyDoctor()
MedicineOrdermediator class:
Methods:
● placeOrder() // checks if the quantity of medicine is low and notifies medicineOrder clas to
order
new stock.
Task 9: Use intermediary objects to mediate between different components of the system.
As mentioned in the previous task objects of various boundary classes and mediator classes act as an
intermediary for interaction between the classes between different components of the system.
Task 10: Your design should minimize dependency between classes.
Since all the classes are loosely coupled , maintain single responsibility as explained in task 7 , this
minimizes dependency between classes. Also instead of depending on concrete implementation of each
class, all the classes use intermediary classes for interactions there by promoting modular design.
Task 11: Maximize the relatedness of methods within a class.
Patient Class
- view_appointments()
- book_appointment(doctor, date_time)
- view_medical_records()
- make_payment(bill_id, amount)
The maximum relatedness is achieved because all methods are closely related to patient-specific actions
and healthcare interactions. Each method serves a distinct purpose within the patient's context, promoting
cohesion within the class.
Doctor Class
- view_schedule()
- update_availability(time_slots)
- view_patient_medical_record(patient)
- receive_appointment_request(appointment_details)
The maximum relatedness is present as methods are closely tied to doctor-specific responsibilities, such
as managing schedules, viewing patient medical records, and handling appointment requests.
MedicalRecord Class
- add_diagnosis(diagnosis_details)
- add_prescription(prescription_details)
- add_note(note_details)
The maximum relatedness is achieved because these methods are directly related to managing a patient's
medical record, including adding diagnoses, prescriptions, and notes. Each method has a clear, single
responsibility related to medical record management.
Admin Class
- manage_system()
- manage_users()
- configure_system()
- view_logs()
The maximum relatedness is attained as the methods are closely linked to system administration and
configuration. They allow for efficient management of the IHMS system.
Pharmacist Class
- manage_stock()
- generate_order()
- receive_order()
The maximum relatedness is achieved because these methods are primarily focused on managing
medicine stock, generating orders, and receiving deliveries.
Billing Class
- generate()
- process()
The maximum relatedness is present as the methods are directly related to billing and payment
processing.
Notification Class
- send()
- mark_as_read()
The maximum relatedness is attained as these methods are closely tied to sending and managing
notifications within the IHMS system.
Task 12: Integrate the Adapter design pattern to make the IHMS interface compatible with
external systems, like the Patient Notification System.
Adapter Design Pattern in IHMS
1. Target Interface:
- Create a NotificationService interface in IHMS that defines the methods IHMS expects for sending
notifications. This interface should include methods like sendNotification(patientID, message).
2. Adapter Interface:
- Create an ExternalNotificationSystem interface that defines the methods expected by external
notification systems. This interface should include methods like sendExternalNotification(patientID,
message).
3. Concrete Adapters:
- Create concrete adapter classes that implement the NotificationService interface and contain
references to specific external notification systems. Each adapter adapts IHMS's method calls to the
corresponding methods of the external systems.
4. Client Code:
- In IHMS, the client code (e.g., code responsible for sending patient notifications) should interact with
the NotificationService interface. The choice of a specific adapter determines which external system is
used for notifications.
By employing this generalized Adapter pattern in IHMS, we can create adapters that can work with
different external systems while maintaining a consistent interface for IHMS. This approach allows IHMS
to interact with various external systems without altering its core logic and interface.
Task 13: Employ the Factory design pattern to create objects within the system.
Factory Design Pattern in IHMS
1. PatientFactory (ConcreteCreator)
- Factory class responsible for creating instances of the Patient class.
- Contains a factory method, e.g., createPatient(), which instantiates and configures Patient objects.
2. DoctorFactory (ConcreteCreator)
- Factory class responsible for creating instances of the Doctor class.
- Contains a factory method, e.g., createDoctor(), which instantiates and configures Doctor objects.
3. AdminFactory (ConcreteCreator)
- Factory class responsible for creating instances of the Admin class.
- Contains a factory method, e.g., createAdmin(), which instantiates and configures Admin objects.
4. PharmacistFactory (ConcreteCreator)
- Factory class responsible for creating instances of the Pharmacist class.
- Contains a factory method, e.g., createPharmacist(), which instantiates and configures Pharmacist
objects.
Product Classes (ConcreteProduct)
Each of the factory classes above produces instances of the respective classes:
- Patient (ConcreteProduct): Represents a patient with attributes and methods specific to patients.
- Doctor (ConcreteProduct): Represents a doctor with attributes and methods specific to doctors.
- Admin (ConcreteProduct): Represents an administrator with attributes and methods specific to
administrators.
- Pharmacist (ConcreteProduct): Represents a pharmacist with attributes and methods specific to
pharmacists.
Client Code
The client code within IHMS can request object creation from the appropriate factory class, such as
PatientFactory, DoctorFactory
By employing the Factory pattern in IHMS, we can encapsulate object creation logic, enhance code
maintainability, and promote loose coupling between the client and the created objects. This allows our
system to create instances of various entities efficiently while adhering to good design principles.
Task 14: Use the Singleton design pattern to ensure a class has only one instance, e.g., for logging
or configuration management.
login(username, password)
The Singleton design pattern is a creational design pattern that ensures a class has only one instance and
provides a global point of access to that instance. This pattern is useful when you want to restrict the
instantiation of a class to a single object, which is typically used for managing resources like a
configuration manager, database connection, or a logging system.
Key Features of Singleton:
Private Constructor: The Singleton class has a private constructor to prevent direct instantiation of the
class from outside.
Static Instance: It provides a static method to access the single instance of the class. This method creates
the instance if it doesn't exist and returns the existing instance if it does.
Lazy Initialization: The Singleton is often lazily initialized, meaning the instance is created only when it's
first requested.
Thread Safety: If the Singleton needs to be thread-safe, the implementation includes mechanisms to
handle concurrent access to the instance, such as using double-checked locking or other synchronization
techniques.
In the context of Intelligent Hospital Management System (IHMS) taken an example of logging system
Class diagram:
+ —----------------------+
|
Logger
|
+ —----------------------+
|
log: list
|
|
+ __new__()
|
|
+ initialize()
|
|
+ log_message() |
+ —----------------------+
-
‘Logger’ is the Singleton class.
log: list represents a private instance variable to store log messages.
‘+ __new()’ is the method that controls the instantiation of the Logger. It ensures that only one
instance of the Logger is created.
‘+ initialize()’ is a method for initializing the logger. In this example, it initializes the log list.
‘+ log_message()’ is a method to log messages. It appends messages to the log list.
The Singleton design pattern ensures that there is only one instance of the Logger class, as indicated in the
class diagram.
Task 15:Apply the Iterator design pattern to access the elements of a collection object in sequential
manner without needing to know its underlying representation.
In the context of the Intelligent Hospital Management System (IHMS), the Iterator design pattern can be
applied to facilitate the traversal of various lists or collections within the system. For instance, we need to
iterate through lists of patients, doctors, appointments, or medical records without exposing the details of
the underlying data structures. The pattern ensures that we can access these elements sequentially while
maintaining loose coupling between your code and the data structures.
1. Iterator (Interface):
- for IHMS, the Iterator interface defines the common methods for traversing various collections within
the system.
- The interface may include methods like hasNext() to check if there are more elements in the collection
and next() to retrieve the next element.
2. ConcreteIterator (Class):
- The ConcreteIterator class implements the Iterator interface
- In IHMS, specific iterators can be created for different collections, such as PatientIterator,
DoctorIterator, or AppointmentIterator.
- These iterators keep track of the current position within their respective collections and provide the
logic for traversing the data.
3. Aggregate (Interface):
- In the context of IHMS, the Aggregate interface represents the different collection classes, like
PatientList, DoctorList, and AppointmentList.
- The interface declares a method like createIterator() to create a corresponding iterator for the
collection.
4. ConcreteAggregate (Class):
- The ConcreteAggregate class in IHMS represents the various collections of data.
- For example, PatientList may implement the Aggregate interface and provide the createIterator()
method to create a PatientIterator.
- Similarly, other collections like DoctorList or AppointmentList would do the same for their respective
iterators.
Class Diagram in the Context of IHMS:
In this diagram:
- The Iterator interface defines the methods for traversing different collections in IHMS.
- The ConcreteIterator classes (e.g., PatientIterator, DoctorIterator) implement the Iterator interface for
specific collection types and provide the traversal logic.
- The Aggregate interface represents different collection classes (e.g., PatientList, DoctorList) and
declares the createIterator() method to create specific iterators.
- The ConcreteAggregate classes (e.g., PatientList, DoctorList) implement the Aggregate interface and
provide the createIterator() method to create corresponding iterators.
By applying the Iterator design pattern in IHMS, you can efficiently and flexibly traverse various
collections of data within the system while maintaining clean and loosely coupled code.