Priory Dental Surgery Appointment Booking System Coursework

Priory Dental Surgery Appointment Booking System - Coursework Example 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 or der 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 t o 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 whi le 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