I have uploaded images describing the assignment and I have also included a sample to have an idea about.
Microsoft Word - Assignment_1._79438_53616433.docx Functional requirements The following functional system requirements were listed by Hagley Dental Care House: · All users must log in before using the system. · System - must record and store the data. Produce a warning if patients balance is lower than £10, produce a warning if the booking was cancelled and notify the administrative staff. Confirm booking by providing doctors name, booking date and time. Register a new user. · Manager – organise inventory, update the system with new devices and tools required for the surgery, manage logistics. · Doctor – See patients treatment history, check available time slots, book and cancel appointments, review booking history. Be able to overview the current balance and payments made by the patient. · Administrative staff – book, cancel, check available time slots and schedule appointments, review booking history. Appoint an alternative doctor. Update or delete account details. Be able to overview the current balance and payments made by the patient. · Patient - Check available time slots, book and cancel appointments, review booking history. Be able to overview the current balance and payments made by the patient. 1 | Page Use case diagram Figure 1. Figure 1. represent the use case diagram. Its purpose is to show all the actors and their functions in one place. Use case documentation Primary case 1 The table below represents a description of two primary use cases. Use Case Title: Login Actors: · Manager · Doctor · Patient · Administrative staff Description: All actors are required to login to use the system. Precondition The actor account must be already created in order to log in to the system. Flow 1. The use case begins with an actor putting name and password. 2. The system checks the input against records in the database. 3. If login details are correct system will display actors personal account. 4. If details are incorrect system will produce an error message and access to the actor's account will be refused. Primary case 2 Use Case Title: Manage the booking Actors: · Doctor · Patient · Administrative staff Description: Actors can book and cancel the appointment. Precondition For booking, the actor must have an account and time slot must be empty, for cancellation an appointment must be already in the system. Flow 1. The use case begins then actor chooses the option to manage booking in a personal account. 2. To book an appointment actor must find an empty time slot in the timetable. 3. Select an empty time slot. 4. Confirm booking. 5. The system will produce a confirmation with doctor’s name, booking date and time. 6. To cancel appointment actor must select the appointment. 7. Confirm cancellation. 10 use cases - brief description Use case 1: Register Description: The new user creates an account. Use case 2: View treatment history Description: Doctors view patients treatment history. Use case 3: Schedule appointment Description: Administrative staff reschedule appointments. Use case 4: Manage records Description: Administrative staff update or delete existing accounts. Use case 5: View patient details Description: Patient, doctor or administrative staff review patients booking history, payments made and current balance. Use case 6: Organise inventory Description: Manager to update the system with new tools and devices required for surgery. Use case 7: Organise logistics Description: Manager order new surgery equipment and organise its logistics. Use case 8: Stores data Description: System records and stores all the data in the database. Use case 9: Confirms booking Description: System produces a confirmation message once booking was successfully completed. Use case 10: Creates alerts Description: System create alert for administrative staff once booking was cancelled or patients get the message that current balance is under £10. Class diagram Figure 2. Figure 2. represents the class diagram. The class diagram shows relationships between all the classes in the system. The table below describes every single class displayed in Figure 2. And shortly describes their functions, properties and relationships. Class name Description NewUser A “NewUser” class is a parent class and holds common attributes: user ID, user type, first name, last name, home address, phone number, gender, age and date of birth. As well it holds common methods: register and log in. All child classes will inherit these attributes and methods from this parent class. Manager A “Manager” is a child class of the “NewUser” parent class and inherits all the attributes and methods. This class has four new additional methods to work with inventory and logistics: updateToolsInventory(), updateDeviceInventory(), orderEquiptment() and manageLogistics(). Manager implements qualification attribute from iQualification class. It has association relationships with Tool, Device and Logistics classes where 1 manager manages many Tool, Device and Logistics classes. Doctor A “Doctor” is a child class of the “NewUser” parent class and inherits all the attributes and methods. This class has one new additional method which allows viewing patient’s treatment history: viewTreamentHistory(). Doctor class implements qualification attribute from iQualification interface class. Implements two methods bookAppointment(), cancelAppointment() from booking interface and another three methods reviewBookingHistory(), viewPayments(), viewBalance() from iViewPatientDetails interface. This class has composition relationship with Booking class because without a doctor a new booking cannot be created. AdminStaff An “AdminStaff” is a child class of the “NewUser” parent class and inherits all the attributes and methods. Furthermore, implements iQualification, iBooking and iViewPatientDetails interfaces. This class has access to the user accounts and manages required data if the doctor is absent it will appoint a different doctor. It has association relationships with Booking class where one admin staff can manage many bookings. Patient A “Patient” is a child class of the “NewUser” parent class and inherits all the attributes and methods. Furthermore, implements iBooking and iViewPatientDetails interfaces. Patient has new national insurance attribute and payForTreatment(), topUpBalance() methods. This class has composition relationship with Booking class because without a patient the new booking cannot be created. Booking This class holds the details required to make a booking. It has a booking ID, doctor ID, booking date, visit purpose attributes and showDetails(), create(), update(), delete() methods. This class has a composition relationship with the doctor and patient class without them booking can not be done. System System class provides 3 main functions: confirms bookings, create alerts and store all the data. It has association relationships with Tool, Device, Logistics, BookingDetails, NewUser, CancelAppointmentAlert, LowBalanceAlert UserAccount classes. UserAccount This class allows AdminStaff class to access user records and modify them. It holds user id and two methods to update or delete the user account. UserAccount class has an association relationship with system and AdminStaff classes. BookingDetai ls Booking details class has the booking ID and showDetails() method. This class is created once the booking is completed and provides booking details. This class has an association relationship with the system. CancelAppoi ntmentAlert This class holds alert ID and cancelled appointment ID. It provides cancelled appointment details and notifies admin staff. This class has an association relationship with the system. LowBalanceA lert This class holds alert ID, patient ID and balance attributes and showDetails() method. It is responsible to alert the patient once the balance is low. This class has an association relationship with the system. Tool Tool class holds the tool ID tool name and four methods to create update delete and showDetails. This class is used to keep records of equipment required for surgery. It has an association relationship with System and Manager classes. Device Device class holds Device ID Device name and four methods to create update delete and showDetails. This class is used to keep records of Devices required for surgery. It has an association relationship with System and Manager classes. 10 | Page Logistics Logistics class hold record of order ID and has 2 methods to createOrder() and updateOrder().It has an association relationship with System and Manager classes. Enum class UserType To avoid errors while typing user type an enum class has been created to hold values of user types: manager, doctor, adminStaff and patient. Has a dependency relationship with NewUser account where a new user must have one of these types. Interface class Some methods and attributes are common for doctors, patients, managers and administrative staff. Therefore interface classes have been created to implement these attributes and methods. iQualification This interface class holds qualification attribute. Describes the qualification level. Has a dependency relationship with the doctor, manager and admin classes. iBooking This interface class holds two methods: bookAppointment() and cancelAppointment(). These methods allow to make or cancel the appointment. Has a dependency relationship with the doctor, patient and admin classes. iViewPatient Details This interface class holds three methods: reviewBookingHistory(), viewPayments(), viewBalance(). These methods allow to review patients details: the booking history, view the payments which were paid for the treatment and check a current account balance. Has a dependency relationship with the doctor, patient and admin classes. Interaction diagrams UML sequence diagram Figure 3. 12 | Page The UML sequence diagram represents interactions between two or more objects in the system. It shows how these objects communicate with each other what commands or instructions are used to complete the specific task (Torlak, 2015). Figure 3. shows what actor, in this case, a patient can do with the system. All the methods and messages are listed and followed by arrows which show where the message is going to. The other four objects are used to show the connection between each other and what message is sent. Looking at the diagram it is easy to see how much of time each object requires and all possible scenarios if the task cannot be successfully completed are represented in alternative cases. The diagram demonstrates how often the object is used to complete a specific task. Collaboration diagram Figure 4. Figure 4. represents the Collaboration diagram. According to the author: “A collaboration diagram addresses the loopholes of a sequence diagram by depicting relationships among involved objects. A collaboration diagram is therefore recommended for supplementing both class and use-case(static-view) diagrams because it depicts the interactions among objects (dynamic-view) [16,17] (Chanan et al., 2005)”. In this diagram methods or messages, a numbered to show exact order of communications between the objects. Activity diagram Figure 5. “An activity diagram consists of a set of activities and transitions showing the flow of control from one activity to another (Janowski & Mohanty, 2010:258)”. Figure 5. represents the Activity diagram. It shows the flow of the actor’s actions and possible choices using the system. Furthermore, the whole cycle of the system can be seen in one figure where it starts and where it ends. Arrows are connectors between the shapes and show the direction of activities to complete the task. Rounded rectangles represent a method or the process. A diamond shows possible decisions. Black circle indicates