Reflections: Object-Oriented Information Systems

In week 3, we were set a task to design a UML diagram for a supermarket.

TASK: Create an object model to represent a supermarket, for example, you might like to consider the some but exclusively all of the following: Staff, Products, Customers, Online orders, Loyalty schemes. Consider how you might represent inheritance within your model and where you might use composition.

This was only my second ever attempt at a UML class diagram, and by far the most invloved. I found it really challenging to come up with all of the necessary attributes and methods for each of the classes. I am sure that if it came to implementing this design, my finished product would be quite different to the diagram as I discovered different things I needed a class to do, or different attributes I needed it to have.

Difficulties

The main diffficulty I encountered was trying to deal with people who are both staff members and customers. I think this really highlighted some shortcomings in my initial approach. I wanted Person to be an interface that was implemented by both the Staff and Customer classes. This meant that a "real life person" would be instantiated from either the Customer or the Staff class, and so, if a staff member wanted to buy something, there would be two different objects for the same person.

In the end, I think I got around this successfully, by reversing the direction of the arrows between Customer, Staff and Person. In this revised design, Customer and Staff became interfaces that are implemented by Person. That means that a person can be both a customer and a member without being represented by two different objects.

In weeks 5 and 6, we were tasked with creating a set of diagrams for the process of a GP's receptionist taking a booking for an appointment.

TASK:You have been asked to develop UML diagrams for a doctor’s surgery based on the following scenario:
Before a patient can see a doctor, or nurse, they will be required to make an appointment. The appointment will be made by the receptionist. However, before making the appointment, the receptionist needs to ask the patient which doctor they would like to see, and whether the appointment is standard consultation or an emergency appointment. The receptionist will use this information to check the appointment schedule, find an available appointment and make the booking. During the appointment itself, the doctor may issue the patient with a prescription. It is possible for a patient to request a repeat prescription be raised. Receptionists are able to cancel appointments as well as create them. A doctor at the clinic may have a maximum of 500 patients registered to them at any one time.

I had to create three diagrams:
1. A class diagram for the system.
2. A sequence diagram for booking an appointment.
3. An activity diagram for a receptionist booking an appointment.

Here is my attempt. I have included each of the diagrams and a short description of my thought process during their design.

Class Diagram

I started the class diagram by making a class for each of the people in the task description: receptionist, patient and doctor. Then, I added the other concrete nouns: appointment, prescription and consultation, drawing the lines indicating the interaction between the classes. Adding the attributes for each class was not too difficult as it seemed obvious which items of information needed to be stored on which class.

The most challenging part was adding the methods. An important consideration is separation of concerns, which I did not take into account. Implementation of OO principles should ensure that the methods which modify attributes of a class are contained within that class. That means that, for example, any other object can update the details of an appointment, by calling the appointment.update_details() method. In my attempt above, the Receptionist class had an update_appointment() method. The problems with this are twofold: (1) should the Appointment class be modified, modifcation will also need to be made to this method in the Receptionist class. (2) should we wish to modify the functionality and allow a Doctor to make an appointment too, we would have to duplicate the code from the Receptionist's method. This violates the DRY principle and makes the code much more difficult to maintain effectively.

Sequence Diagram

The challenging part of the sequence diagram was trying to depict all of the communication between objects. I discovered afterwards that it is oftten not deemed necessary to show the returned details(actions which I had used dashed lines for) in an effort to keep the diagram clutter-free. One of the benefits of completing this diagram was it allowed me to more clearly see the communication between objects in the system, and led to me returning to the class diagram to modify many of the methods.

Activity Diagram

This was definitely the most conceptually straightforward of the three diagrams as it is very similar to a flow chart, which I am already familiar with. One of the important design factors that I discovered when reading about this type of diagram is that to ensure that it is comprehensible at a glance, we should aim to keep the "Yes" and "No" exits from a decision flowing in a consistent direction.

One of the immediate differences between this and a normal flow chart is the ability to have simultaneous of parallel actions. This is acheived by arriving at a perpendicular bar with multiple actions flowing in parallel from it, though there was no need to include any in this particular example.