├── README.md ├── Requirements.md ├── TeamContract.md ├── UserStories.md └── images ├── .gitkeep ├── ArchitecturalStylesDiagram.png ├── component_diagram.png ├── deployment.png ├── functional_decomposition.png └── project.png /README.md: -------------------------------------------------------------------------------- 1 | # Group 7 2 | 3 | # Table of contents 4 | 1. [Purpose](#purpose) 5 | 1. [What](#what) 6 | 2. [Why](#why) 7 | 3. [How](#how) 8 | 4. [Developers](#developers) 9 | 5. [Team Resources](#team resources) 10 | 2. [Requirements (SRS)](#requirements) 11 | 3. [Architecture (SAD)](#architecture) 12 | 4. [Project Management Report (PMR)](#pmr) 13 | 5. [Developers](#developers) 14 | 15 | ## Purpose 16 | ### What are you going to make? 17 | We will build a web-application that allows citizens of Gothenburg to book dentist appointments. 18 | The application will display a map that the user can navigate and find dentist offices. 19 | In the application the user can choose among different dentist offices to book appointments at. 20 | 21 | ### Why will you make it? 22 | There is a real demand for this kind of system and as of now there is no available system that 23 | provides users the opportunity to select from various dentist offices in their area. 24 | 25 | ### How are you going to make it? 26 | We will build a distributed web-application powered by Node.js and Express using the MQTT-protocol. 27 | 28 | ## Developers 29 | 30 | - [Clementine Jensen](https://git.chalmers.se/jensenb) 31 | - [Christian O'Neill](https://git.chalmers.se/oneillc) 32 | - [Hjalmar Thunberg](https://git.chalmers.se/hjathu) 33 | - [Hugo Hempel](https://git.chalmers.se/hugohe) 34 | - [Linus Ivarsson](https://git.chalmers.se/ilinus) 35 | - [Linus Åberg](https://git.chalmers.se/linusab) 36 | 37 | 38 | ## Team Resouces 39 | 40 | - [Trello](https://trello.com/b/9ccpzxgs/dit-355-2020-team-7) 41 | - [EmailSender-component](https://git.chalmers.se/courses/dit355/2020/group-7/notifier) 42 | - [SystemLogger-component](https://git.chalmers.se/courses/dit355/2020/group-7/logger) 43 | - [AppointmentHandler-component](https://git.chalmers.se/courses/dit355/2020/group-7/backend) 44 | - [BookingGUI-component](https://git.chalmers.se/courses/dit355/2020/group-7/ui) 45 | - [RequestGenerator](https://git.chalmers.se/courses/dit355/2020/group-7/requestgenerator) 46 | 47 | ## Requirements (SRS) 48 | [Requierments](/Requirements.md) 49 | 50 | [User stories](/UserStories.md) 51 | 52 | ## Architecture (SAD) 53 | 54 | #### Component diagram: 55 | ![component_diagram](./images/component_diagram.png) 56 | 57 | #### Architectural Styles diagram: 58 | ![architectural_styles_digram](./images/ArchitecturalStylesDiagram.png) 59 | 60 | The Circuit Breaker which can be seen above the Appointment Handler was added as fault tolerance mechanism to measure the load. 61 | The reason it is in the appointment handler is due to this being the component with the largest amount of traffic. 62 | 63 | #### Functional functional decomposition diagram: 64 | ![functional_decomposition](./images/functional_decomposition.png) 65 | 66 | 67 | Our Architecture for the system: 68 | 69 | The system will consist of four different components. 70 | * AppointmentHandler that will take care of the database handling. This is where we will store information about dentist offices and appointments. 71 | 72 | * BookingGUI is the part that our users get in contact with which will contain a map view of Gothenburg that show available time-slots at different dentists. The GUI will let the user book appointments at dentist offices with open time-slots. 73 | 74 | * EmailSender that will handle email-conformations. 75 | 76 | * SystemLogger that handles the logging of previous events to increase our traceability within the system. 77 | 78 | The components mentioned above will communicate through Publish/Subscribe via MQTT. All communications will be handled through a MQTT broker before it is sent to the subscribers. 79 | 80 | ## Project Management Report (PMR) 81 | In this project endevour the team will follow an agile development process. The team will, once a week, together derive a certain set of user stories from bigger requirements that will be implemented the coming week. During the working week the team is divided up into smaller teams, Frontend, Backend, and if necessary Architecture. A lot of emphasis will be on pair-programming, this is to ensure efficiency and to maximize the learning throughout the project. The members of each team will change every week in order to deepen the learning. The team will further make use of a Kanbanboard hosted at Trello where work will be distributed in an pull approach. 82 | 83 | The whole team will meet up three times a week. Monday and Friday, its just the team that meets and on Wednesday it is a meeting with the team and the Product Owners (TAs and Teachers). 84 | * The purpose of Monday meetings is to derive more User Stories if there is velocity for it and also discuss requirements changes that might have com up during the weekend. 85 | * The purpose of the Wednesday meetings is to report work progress to Product Owner and to receive feedback on the product at hand. 86 | * The purpose of the Friday meeting is to discuss the work that has been done during the week and to get a collective vision of where we are in the development. 87 | 88 | Furthermore the team has agreed on a code of conduct which can be found [here](/TeamContract.md) 89 | 90 | 91 | 92 | -------------------------------------------------------------------------------- /Requirements.md: -------------------------------------------------------------------------------- 1 | # Requirements 2 | 3 | 1. The system shall utilize a publish subscribe architecture. 4 | 5 | 1. The system shall use middleware based on the MQTT-protocol. 6 | 7 | 1. The system shall utilize a Publish/Subscribe system for the MQTT protocol. 8 | 9 | 1. The system shall allow users to book dentist appointments. 10 | 11 | 1. The system shall display a web-based GUI, which should include: 12 | 1. User specified time-slots. 13 | 1. Track free time-slots and dentist availability. 14 | 1. A confirmation/rejection notification. 15 | 1. A map-view over Gothenburg that can be navigated. 16 | 1. Allow for user requests. 17 | 1. Delegate incoming user requests. 18 | 1. Reactivity to booked user slots. 19 | 20 | 1. The system shall be a distributed system. 21 | 22 | 1. The system shall consist of at least 4 distributed components, which shall clearly contribute to the purpose of the application. 23 | 24 | 1. The system shall track free time slots and dentist availability. 25 | 26 | 1. The system shall send confirmation and rejection notifications to users. 27 | 28 | 1. The components shall be resistant to standard failures, out of bounds inputs and ill-formatted data inputs. 29 | 30 | 1. The components shall unsubscribe from the MQTT broker when stopped. 31 | 32 | 1. The system shall be able to communicate and utilize the dentist registry database. 33 | 34 | 1. The system shall contain time slots, which shall: 35 | 1. Be 30 minutes in lenght, 36 | 1. Include a one hour lunch break, as well as a 30 minute Swedish Fika break. 37 | 38 | 1. The booking requests shall follow a predefined format, that is handled through the MQTT-middleware. 39 | 40 | 1. The booking response follow predefined format. 41 | 42 | 1. The GUI should notify the user if the request was failed or successful depending on the response it recieves. 43 | 44 | 1. The system shall react to simutaneous bookings by visualizing available time slots. 45 | 46 | 1. The system shall provide timeslots depending number of dentists in the dentist office. 47 | 48 | 1. The system shall repsond to changes in openinghours. 49 | 50 | 1. The system shall allow for additional dentist offices. 51 | 52 | 1. The system shall react to changes in the DentistRegistry within 10 minutes. 53 | 54 | 1. The system shall utlize a Request Generator to stress test the system. 55 | 56 | 1. The system shall send requests that follows the predefined format. 57 | 58 | 1. The system shall have fault tolerance mechanism. 59 | 60 | 1. The system shall display a visual cue on the map to indicate if a dentist office has available timeslots for a specified date. 61 | 62 | 1. The system shall utilize Quality of Service to ensure the delivery of messages. 63 | 64 | 1. The components shall unsubscribe from the MQTT broker when stopped. 65 | 66 | 1. The components shall be resistant to standard failures, out of bounds inputs and ill-formatted data inputs. -------------------------------------------------------------------------------- /TeamContract.md: -------------------------------------------------------------------------------- 1 |

Team Contract:

2 |
  • Expectations:
    First and foremost, our expectations depend on the group members being attentive and hard working throughout the project. The working morale and dedication in the group is quite high, and because of this it is crucial that members of the group keep up with the task they are assigned, to avoid conflict. 3 | 4 | Furthermore, we expect that the group members will stay updated on what the other members in the group are doing. This is both to know what they are doing - for when it is their turn to enter the role - as well as being able to contribute and help should it be necessary. 5 | 6 | The group members are expected to keep Trello, slack, GitHub and the documentation updated, and inform if anything is drifting away from the plan. 7 | 8 | We expect the group members to take part in conversations and meetings on the project, and if such participation will not be possible on any given occasion, the group member will inform of this immediately. 9 | 10 | Finally, the quality of work should be that of the singular group members highest capacity. This is to ensure that: 11 | * i) the work one is doing is as good as possible in quality. 12 | * ii) one sees the size of the group not as an opportunity to do less work, but rather as an opportunity to develop their respective skills and deepen their understanding. 13 | * iii) every person in the group has the ability to be challenged and grow intellectually. 14 | * iiii) one evens out a set of boundaries for those with less capacity in the group, making sure that the focus is on an individuals best rather than a set standard.
    15 | 16 | The group will meet on Mondays and Fridays at 13:00 in Zoom, until the meeting has been concluded. With the need of additional meetings, these will be provided in the same environment as mentioned previously. 17 | 18 | Policies and Procedures: 19 | Behave in a mature manner. This describes proper meeting etiquette, as well as general respect and professionalism within the working environment. 20 | Be open to help each other. If an issue with understanding occurs, it is fundamental to the group's progression that there is an open environment that allows for aid to be represented to the member(s) who are struggling with a specific topic. 21 | If you do not understand what to do, ask for assistance. Your group members are there to assist you, if you need it. 22 | Do not intentionally sabotage for other group members. 23 | Keep yourself up to date with others' work. If something new is added to the code, for instance a commit or a push, ensure that you are up to date with its functionality. 24 | Each and everyone in the team has a responsibility to carry out their tasks and gather necessary knowledge to succeed in these tasks. If something should hinder this, it must be communicated in a timely manner in order to assess the impact and give the team an opportunity to address these issues. 25 | 26 | Roles and Responsibilities: 27 | (Preliminary roles, will potentially be updated) 28 | 29 | - Product Owner: 30 | Takes care of the product backlog, as well as overseeing that the appropriate measures are taken towards the implementation of the software description. 31 | Scrum-Master. An influential leader to the process of the development process. 32 | 33 | - Team: 34 | Developer. Focuses primarily on the implementation of code. Their main goal is to develop the software. 35 | Tester. Writes automated test cases which are implemented into the automation process. 36 | Architect. Develops and provides the architectural aspects of the software, such as Architectural Style, forces and drivers, etc. 37 | 38 | On Mondays new roles will be provided to the team members, which will last until the coming Monday meeting. On occasion, some cross-roles will occur. In the case of lack of work, for instance architect or scrum-master, might be provided additional roles. 39 | -------------------------------------------------------------------------------- /UserStories.md: -------------------------------------------------------------------------------- 1 | # User Stories 2 | 3 | 1. As a developer I want to have a Publish/Subscribe architecture so I can fully utilize MQTT protocol. 4 | 5 | 1. As a user I want a visual presentation of avaliable time-slots in my city so I do not have to call multiple different dentist offices. 6 | 7 | 1. As a user, I want the GUI to dispay a navigable map, so that I can freely view and choose dentist offices. 8 | 9 | 1. As a user, I want to be able to make appointments through the system, so that I don't have call the dentist. 10 | 11 | 1. As a user I want to see what dentist offices have available time-slots so that I do not need to manually check multiple offices. 12 | 13 | 1. As a user I want to specify my booking time so I can plan my day accordingly. 14 | 15 | 1. As a user I want conformation regarding my booking so that I can be certain it has been correctly booked. 16 | 17 | 1. As a user I want the interface to be responsive so I can, for instance, zoom in and out on the map, or see further information about the different offices. 18 | 19 | 1. As a dentist, I want the time slots to include lunch and fika-breaks, so that I do not get bookings during these time slots. 20 | 21 | 1. As a developer, I want the booking requests to follow a predefined format, so that it is easier to develop a system for requests. 22 | 23 | 1. As a dentist, I want the appointments to start at full and half hours, so that I can more easily manage my schedule. 24 | 25 | 1. As a user, if my booking is not approved, I want a rejection notification, so that it is clear whether the appointment is booked or not. 26 | 27 | 1. As a developer, I want the system components to be isolated and independent so that it is easier to discover issues within the code. -------------------------------------------------------------------------------- /images/.gitkeep: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Brother-Blue/Dist.-Systems-documentation/c9a21008f2de2e77d10aa8a3333e6b4b8959fa83/images/.gitkeep -------------------------------------------------------------------------------- /images/ArchitecturalStylesDiagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Brother-Blue/Dist.-Systems-documentation/c9a21008f2de2e77d10aa8a3333e6b4b8959fa83/images/ArchitecturalStylesDiagram.png -------------------------------------------------------------------------------- /images/component_diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Brother-Blue/Dist.-Systems-documentation/c9a21008f2de2e77d10aa8a3333e6b4b8959fa83/images/component_diagram.png -------------------------------------------------------------------------------- /images/deployment.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Brother-Blue/Dist.-Systems-documentation/c9a21008f2de2e77d10aa8a3333e6b4b8959fa83/images/deployment.png -------------------------------------------------------------------------------- /images/functional_decomposition.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Brother-Blue/Dist.-Systems-documentation/c9a21008f2de2e77d10aa8a3333e6b4b8959fa83/images/functional_decomposition.png -------------------------------------------------------------------------------- /images/project.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Brother-Blue/Dist.-Systems-documentation/c9a21008f2de2e77d10aa8a3333e6b4b8959fa83/images/project.png --------------------------------------------------------------------------------