...
Design Decisions related to deployment
| BrokerServer | The brokerserver will run with a brokerservice on it. This brokerservice will allow us to create large data-streams. This will in turn allow us to create dynamic graphs on our webpage without having to consult a database twenty times a second. This brokerservice is connected via a broker connection to the Java application API. |
|---|---|
| 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 it's 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 and 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 be run. This is the user end of our application. |
Design Sub-System Login
Design Class Diagram
Sequence Diagram
<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
Login 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.
...