The purpose of this project is to create a distributed system that allows users to book dentist appointments in the Gothenburg region.
Fayona Cowperthwaite, [email protected]
Dominique Deramat, [email protected]
Shonaigh Douglas, [email protected]
Negin Hashmati, [email protected]
Jennifer Nord, [email protected]
Victoria Vu, [email protected]
- The system shall allow users to book dentist appointments.
- The system shall allow users to book dentist appointments based on time slots.
- The system shall provide a map.
- The system shall allow the map to be navigated.
- The system shall allow the map to visually display an indication of availability to the user.
- The system shall allow users to find available appointment times.
- The system shall provide a graphical user interface for users to use the system.
- The system shall visually distinguish different appointment time slots.
- The system shall provide booking confirmation/rejection to users.
- The system shall be able to show free time slots.
- The system shall keep track of the booked appointments.
- The system shall include a request generator in order to enable stress-testing of the system.
- The system shall be fault tolerant.
- The system shall be capable of appropriately handling standard failures, such as wrongly formatted data inputs or out of bounds inputs for the defined interfaces.
- The system’s resource-handling shall be mindful, e.g. stopped components must unsubscribe from the MQTT broker fulfilling the contract.
- The system shall be able to handle large amounts of requests at the same time.
- The system shall be responsive.
- The system shall react to simultaneous bookings visually (preferably without requiring an active refreshing of the interface by the user).
- The system shall respond to updates fast.
- The system shall provide a way for updates to take effect within 10 minutes of their publication.
- The system shall consist of at least four distributed components.
- The system components shall have no knowledge about the physical location of other components.
- The system component shall not depend on other components residing at a specific physical location.
- The system shall be ready for final release on 5 January 2021.
- The system shall use a combination of architectural styles.
- The system shall use a middleware based on the Message Queue Telemetry Transport (MQTT) protocol.
- The system booking requests and responses are to be handled through MQTT.
- Dentists will be unavailable for booking appointments for 1 hour and also 30 minutes per day due to breaks.
- Dental appointments must be 30 minutes in length and start on the hour or half past the hour.
- Requests and responses need to follow the format in the provided JSON files.
- Users will be able to select a date and time when booking their appointments.
- Updates to the dentist registry will not happen more than twice per day.
- Already existing bookings should not be affected by shorter opening hours or decrease in number of available dentists.
- The ids of the dental offices shall remain consistent.
For older versions of the diagrams, please see the /Diagrams folder.
This is a use case diagram with two actors represented, a User and the Leaflet Map API. It shows the main use cases they are involved in.
This a sequence diagram showing what happens in the system when a user selects a date on the calendar. It shows all the involved components and the interactions between them.
This a sequence diagram showing what happens when a user makes a booking. It shows all the involved components and the interactions between them.
This is a component diagram showing all the components involved in the system and how they use each other. It reflects the architectural styles we have chosen by listing the components’ roles in context of the two featured use cases. The diagram is structured following a layered style, it separates the components amongst the four layers.
This is a deployment diagram that shows where each component is being executed when the program is running. It also lists the transport protocols being used in the system to transfer data.
This is a quality of service flowchart showing the QoS levels set between the various sender and receiver relationships in the system. We have chosen to implement a QoS level of 1 everywhere in the system because due to the nature of the system we felt a level of 0 was too minimal and a level of 2 too slow for our users. Level 1 offered a good balance between ensuring messages are being received and providing a streamlined user experience.
- Dentists will have lunch for an hour in the middle of their work day.
- Dentists will have their fika breaks in the first half hour of their work day.
- Single-page web app front-end rather than a mobile-based front-end.
- Whole website is one page, user is able to view availabilities and make bookings on the same page
- Mapbox is used to display the map
- Leaflet is used to display the pins and provide other functionality because it has more user-friendly documentation than Mapbox
- Availability as its own component, we determined early on that the appointment availability was important and decided to have the filtering logic separate from Booking
- For fault tolerance, we chose the circuit breaker because it is reactive. This means it would be able to adapt to what is happening in the system at any given time.
- Publish-Subscribe for the communication between the components.
- Pipe and filter for booking validation and generation of available booking slots
One of our drivers is resilience since we have to make sure that the system is fault tolerant. Furthermore, our other drivers were compulsory requirements given to us by the product owners: using a broker, having four components, using publish-subscribe as one of the architectural styles.
One of our forces is the group member’s knowledge of certain technologies. We chose to work with technologies that we have used before and are comfortable with, even if there are other technologies that might suit the system better. This leads to another one of our forces: time. Since the system has to be delivered by a certain date, we did not feel that we had the time to properly research and learn new technologies to use for this system.
The initial use case diagram was created to get an overview of what functions the system should have. As the system evolved, the diagram was updated to reflect the requirement changes, and also our new design decisions.
Because of the project requirement of having four components, and the functionality of the system, we created the following components: Dentist, Booking, Availability, and Frontend. These requirements impacted what responsibilities and functionality we gave the different components.
We knew from the start that we were going to use publish-subscribe since using a middleware based on the MQTT protocol was a requirement for this project. This would be our core architectural style as this is used by all of the components in the system.
Pipe and filter was introduced later as we realized that we needed something that would combine the information from the booking registry and dentist registry to generate the free time slots for a certain dentist and date, as well as validating the booking requests before publishing them for the booking component to use.
- Vue.js for frontend
- Bootstrap for frontend
- Java for backend
- Eclipse Paho
- Java
- JavaScript
- Eclipse Mosquitto
- MQTT Explorer for logging
- Leaflet
- Resilience4J
- Mapbox
-
Scrum
- Stand-up meetings on work days
- Project work is organized into 4 sprints
- Kanban board is used on Trello to display the tasks and assigned team members
- Columns for overall backlog, sprint backlog, in progress, merge request/review, completed during each sprint, and discarded.
- The merge request/review column is where tasks connected to a merge request that required a review and testing by other team members would be placed.
- The discarded column is for tasks we believed were necessary but were later rejected but we wanted to keep track of ideas and work produced so did not want to delete them.
- Columns for overall backlog, sprint backlog, in progress, merge request/review, completed during each sprint, and discarded.
- Roles: Scrum master
- Each team member took turns being the scrum master and it was decided that the role would cycle every Monday
- A decision was made to remove the role of product owner after the first week as we felt that the person did not get to do anything extra since they were merely a proxy for the product owners.
- Stand-up meetings on days designated for project work to discuss the work performed and blockers encountered for each sub-team
-
Code of Conduct acts as a team contract and states our expectations, policies and procedures, and consequences
-
Work to be done during the sprint will be decided during a Sprint Planning Meeting with notes taken to record the results of the meeting
-
Schedule for the week will be decided during a weekly team meeting, taking into account team member availability
See Trello board for detailed schedule and work tasks carried out in each sprint.
- Week 1: Work Monday, Wednesday, Thursday
- Week 2: Work Monday, Wednesday, Thursday
- Week 1: Work Monday, Wednesday, Thursday
- Week 2: Work Monday, Wednesday, Thursday
- Week 1: Work Monday, Wednesday, Thursday
- Week 2: Work Monday, Wednesday, Thursday
- Week 1: Work Monday, Tuesday, Wednesday
- Week 2: Work Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday
- Week 3: Work Monday, Tuesday