Detailed Design Description
<This section contains detailed design documentation of all software components. The content of this section grows iteratively during the sprints. At the end of each sprint, the diagrams shown need to be consistent.>
Deployment Diagram
Deployment Diagram
figure 2: deployment diagram<Provide a UML deployment diagram showing all physical and virtual nodes used in the system. The diagram must also contain all deployment artifacts used in the system, for instance JAR or WAR files, or web artifacts.>
Design Decisions related to
...
<Describe all design decisions manifested in the deployment diagram. For instance the choice of operating systems, protocols, distribution of components over sub-systems and the like.>
Design Sub-System Login
<Do not really name the section “Sub-System A”, use a name that describes the responsibility of the sub-system, instead. Provide a section for each sub-system. These sections are iteratively added and refined during the sprints. Examples of sub-systems include Persistent Storage, Business Tier, Web Application, Webservice API. The sub-sections below may be extended if you think this is useful for describing the software design. The sub-sections below are only required for object-oriented sub-systems. Use other means to describe non-OO sub-systems (for instance Javascript modules).>
Design Class Diagram
With this design class diagram you can see the interactions happening between different classes of our program.
The logincontroller makes sure it knows everything that has to do with logging in. The resource sends the requests to the controller and recieves data back from the controller
The resource classes makes uses of the Response interface. This needs to happen, so that the user knows what went wrong.
<Object-oriented sub-systems should be described using a class diagram. If classes or interfaces are used across sub-systems, make sure you mention this in the description of the class diagrams. If your system entails layers, make sure you indicate this in the class diagram, e.g. by means of packages. For each class diagram, make sure you also mention the deployment artifact (from the deployment diagram) it is part of.>
Sequence Diagramsm
<Provide sequence diagrams for major object interactions within the sub-system. It is ok if sequence diagrams cross sub-system boundaries. Make sure you explain this in the description of the diagram. Sequence diagrams must be consistent with the class diagrams described above. Also, if sequence diagrams cover interaction with users, make sure the diagrams are consistent with SDDs you may have documented as part of the SRS.>
Activity and State Diagrams
<This section is optional. If useful, provide activity and/or state diagrams to describe complex work flows and system state transitions>
Design decisions made for the sub-system
<Describe all design decisions made for the sub-system. Provide at least decision descriptions for all frameworks, libraries and other technologies used. Other decisions may be related to software patterns, system-structure, adapted principles or the like.>
Login
Sequence diagram
The LoginResource should only send requests to the controller and should return only one response, because the class is a resource class. The LoginController class is a controller and provides a link between the resource and the data classes. It sends the necessary methods to the other classes, so that LoginResource may not become a God class. The controller also returns the response to the LoginResource.
Design decisions
...
Decision
...
Description
...
Problem/Issue
...
Deployment Diagram
| BrokerServer | A brokerserver is a server on which one or more brokers reside. In our case this will be just one broker which sends the data from the racecar to our website. The brokerservice will allow us to create large data-streams, sending data from one point to another. This way we can show dynamic graphs on the website with the actual data without using a database. This way the data will be arriving on the website much quicker, which definitely is important in our case. We connect to the broker over a websocket connection directly in the front end code. This way it will be as fast and reliable as possible. It will go through the least amount of code and layers that is possible. |
|---|---|
| DatabaseServer | The database will contain all data that is not required to be updated to show real-time data. This will thus include all sensor-data of past races, as well as all data required for logging in and creating race-views. The database system we use is MySQL, because of its accessibility and relative ease to use. MySQL runs on a databaseServer, that is connected to the Java Application API with the use of a JDBC (Java Database Connectivity) Database Connection. |
| ApplicationServer | The ApplicationServer will contain the API itself. This API will use Jakarta EE and Wildfly 25.0, which allows us to run an API with ease in a web environment. Using the REST API, this Java Application will connect to a webserver and deploy its .war artifact there. |
| Webserver | The webserver is the link between user and API. That is the part of our API that the user can interact with. This webserver could also be described as a simple website. |
User PC | The user PC is the eventual device on which the API and webpage will run. This is the user end of our application. |
table 3: glossary of deployment diagram
Class Diagram
We made three different class diagrams to make the visual side of our program more understandable. The first one is for all our back-end code. The second one shows our data access object and data transfer object diagram and the last one is our front-end class diagram.
Class Diagram Backend
figure 3: class diagram back-end
Class Diagram DAO-DTO-generalisation
figure 4: class diagram DAO and DTO
For every resource we have made, there's a few extra classes that we have generalised here. The DTO classes are being used to model the data in a single format for easier use, this way we only need to edit data in one place. In the DAO classes we put all the logic that is needed to get the data from the database. Here we will process the data from a query result into the DTO and pass it back to the services. This way we create a layer pattern in our application which gives better readability and clarity for the next team that wants to alter our code after us.
Class Diagram Front-end
figure 5: class diagram front-end
...
Decision
...
Description
...
Problem/Issue
...
View Data
The choice has been made to have a method create all required data-objects. These objects contain all data required to show data in a graph. The GenerateGraphData method will first create a new WheelspeedDTO (Data Transfer Object) and WheelspeedDAO (Data Access Object). These objects are then filled with the data that is retrieved from the createGraph method. Next, the objects are sent over to the frontend in JSON-format.
By sending data to the front-end this way, we can ensure expandability in the future. The contents of this diagram can be copied easily, which will make implementations of new graphs a lot easier.
View data per Round
The crewmember interacts with the ModalComponent to create a new tab. In this component, the crewmember fills in the desired rounds that they want to see data from. The system will then add the new tab with the specified rounds to the application.
View Races
The crewmember goes to the rewatch race page where the front-end does a call to the back-end. This activates the getAllRaces method in the RaceResource. The resource is only responsible for returning the response so it gets delegated to the RaceController. The RaceController delegates this to the raceDAO because getting the data from the database is not the responsibility of the controller. In the RaceDAO a database connection is established to get all the data from the database. The benefit of this structure is that you can easily swap the classes which results in low cohesion and high coupling. This structure is based of the the layer pattern.
Design decision
...
Decision
...
Description
...
Problem/Issue
...
The BMW is the only car they intend to use in the near future so it's not necessary to make a new table for racecar.
Place Graph
SD 1 Add graph
When a crewmember opens the a tab, the front-end does a call to the back-end. It calls a method to SensorWithGraphResource. This is the controller of the SensorWithGraphDAO that gets the data which is needed for displaying graphs on the front-end. The SensorWithGraphDAO creates two DTO's. This is because SensorWithGraphDAO is the information expert of them.
SD 2 Select sensor
We decided that making a sequence diagram is not needed for this user action to the system. The crewmember will click on the desired sensor to view a graph from. After the user clicks on the sensor, it wil instantly show the types of graph linked to the sensor. This is something that happens on the front-end, thats why we decided its unnecessary. information expert.
SD 3 Select graph
The crewmember interacts with the front-end by clicking on the desired graph type. This will call a method to create the graph on the sidebar component. This is because the sidebar component is the controller. The sidebar component will interact with GlobalComponent because he is the information expert. GlobalComponent knows everything about graph.
Design decision
...
Decision
...
Description
...
Problem/Issue
...
Not every sensor has good enough data for a normal table.
Tabs CRUD
During the development for the user tabs we got into an argument on how we were going to display the tabs a user can have. We came to the conclusion that it would be easier if we were to store the tabs in the database. This way the crewmembers don't have to recreate the tabs every time they would login. Also, this way every crewmember could design their dashboard the way they find easy to read.
Database Design
This is the database setup we will use for the RegterschotRacing API. A full description of every tables usage and datatypes can be found below.
All green boxes will be made by Smalltalk in order to provide a sound foundation to build an API on. The two red boxes could be future expansions that are out of our current scope. These have been placed here as an example to provide future developers with a stepping stone. These expansions would allow for the creation of 'Raceteams', which could give the API the functionality to be used by other raceteams, each with their own crew and cars. The sensors have been tied to the racecar, as all sensors should be in a racecar.
Database Glossary
Tablenames and formats are written in italic; Columns that contain the primary key are underlined.
...
The type of graph, can be anything from the following:
- linechart
- barchart
- piechart
- scatterchart
- columnchart
- areachart
- donutchart
- table
- gaugechart
...
The unique identifier of the race.
...
Tabs
...
This field contains the specific data that a sensor sends to this database. For this specific sensor, that data is received as RPM. When a new sensor is added to the API, a new table, just like this one should be created where only the data field should be edited.
Design decisions related to the database
<Describe all design decisions made along the database. This could include the choice of the database management system, the use of certain triggers or stored procedures, special indexes and so on.>
hier moeten nog dingen bij als triggers en uitleg over de keys
...
Decision 1
...
Description
...
Problem/Issue
...
Divide the different datatypes into multiple tables: a rounds table, a race table and a driver table.
Create a linking table that links all of these three tables together.
...