Priory Dental Surgery Appointment Booking System - Coursework Example

?Running head: Exercise learning outcome report Priory Dental Surgery Appointment Booking System (PDS) of number: Course title: Course code: Tutorial One Use Case Diagram This task involved creating of Use Case Diagram for Priory Dental Surgery Appointment Booking System (PDS). The first step was to identify the actors. An actor is a person, device or job role that interacts with the PDS. From the description below actors were identified which interacted with the system. They do carry out a given action in relation to the system. The actors in this case were the Dentists, Patients, Receptionist and the Manager. The second step in this task was to identify the use cases, these are the actions done by the actors. They are identified with the phrases that start with verbs or those that indicate actions being performed by actors. It was observed that one actor can have one or more use cases depending on their role with the PDS. A phrase such as “arrange patients’ booking” is identified as a use case. From this exercise it was observed that it is important to match the actors with their uses case while design the use case diagram. Associations of actors and use cases is therefore important. Use cases also have extended relationship where one use case depends on the other use case within the system. Tutorial two : Use Case Descriptions The second task was to describe the use case. This entails providing steps and responses between the system and the actor. What does an actor require to have in order to accomplish a given task? The description also shows the main steps the actor will take in doing a given action (use case). The task in step 2 demonstrated how one can describe a use case using a table. The task involved how a receptionist could change a given appointment. The receptionist must be able to check into the system the previous appointment allocation then see if there is a time slot in the next proposed time by the patient. In checking the next free slot, factors such as the availability of the Dentist is important if he is available is it the same time as one proposed by the patient? If this conditions are not met the receptionist fails to book appointment for the patient and such feedback is given by the system. Otherwise, the receptionist will print the appointment confirmation or email it to the patient. Unlike making appointment where there are extensions, changing of the appointment does not have any extensions or views. Views means checking other use cases to see if the action you are performing is valid or viable. For instance the receptionist must view patient to ensure that that patient does not have another appointment. Tutorial three: Analysis/Conceptual Class Diagram A class in system design is something that the system needs to store information about. In any scenario they are or case study such as PDS classes are known by identifying nouns. A class diagram is a rectangular shape that contains the name of the class, the operations and methods used by the system to retrieve or store information about the class. It was learnt that class names are in singular forms and only nouns are used not verbs. In exercise one, I was able to identify classes as; Appointment, Dentist and Patient. Exercise two required attributes and operations of the identified classes. Attributes can be said to be characteristics or information that the system will store about the class. Appointment could have the time and date of appointment as attributes while operations are the activities or actions that the system will perform to access or store information about the use case such as checking the free time for appointment. I learnt that attributes are written below the case name with a minus sign(-) at the beginning of the attribute while a plus sign (+)for operations that come below attributes in a class diagram. Exercise five combined all the classes to show how there are associated and their dependencies outlined. It shows that a system is a single unit with many classes that associate with each other. Tutorial four: Layered Design Model The main tasks in this tutorial was exercise 2, 3 and 4 where exercise 2 required completion of operations required for receptionist to complete appointment process of the patient. A patient after making an appointment may change it to another date or cancel the whole appointment these are some other operations required. 3 required boundary class to handle manager and the required operation report() while exercise 4 required completion of the BookingController class which was designed in previous exercises. Layered design of class diagrams are created from an analysis of class diagrams. In this exercise class diagrams from tutorial three were used. The actors interface was handle by a boundary class which layered the receptionist, manager and the report operations in user interface layer. Boundary class for manager and report was done where ManagerGUI, the interface where the manager uses to perform his/her tasks is in the user interface layer similar to the report(). The application layer had in the BookingControler had operations such as adding and deleting of patients, adding and deleting Dentists this operations affects the Patients and Dentist list in the domain/data layer. It can be observed that there are three layers in Layered Design Model. The user interface, application and data/domain layer. Tutorial Five: Design Class Diagram A class diagram is a detailed descriptions of a given class. It is a rectangular diagram that contains the data type for each attribute of the class, operations such as constructors, set get operations and operation signatures depicts required data arguments. The first task was exercise 2 where I was to find out the constructor method for Dentist class which was +Dentist. Get and set methods are used to retrieve or change data in a given class. Exercise 3 was about identifying Set or Get methods. I learnt that for every attribute it has a method to modify it either by retrieving or updating the current information the class. Exercise 4 required an operation that will set the appointment having the correct data or signatures. This was done as +setup(correct signatures), with the correct signatures where the dentist, patient date and time were to be set up. In exercise 5 the system was to notify the Dentist about the appointment made with all the details of the appointment. The solution to the task was : An attribute, dentist, is added to the Appointment class, which enables Appointment objects to send messages to Dentist objects, but not vice versa - Appointment objects are the sending objects whereas Dentist objects are the receiving objects in message passing. Reference Dr. YL Hedley, starUML, lecture notes, Introduction to StarUML. Use Case diagrams including generalizations, and . At Coventry University Read More