-
Notifications
You must be signed in to change notification settings - Fork 7
Component Description
| Group 8 | Component Description |
|---|---|
| Weatherbrain | Version 1.1 |
| Name | Description | Responsible person |
|---|---|---|
| REST API | The REST API module will handle data requests from the React Website and provide weather data for the React Website. | Fredrik Lundström |
| Machine Learning | The Machine Learning module predicts weather and uploads a forecast to a database and the module also includes working and managing data. | Casper Kristiansson |
| IoT Module | The IoT module uses sensors to measure precise location current weather data and a Raspberry Pi for uploading it frequently to a database. | Ville Vik |
| React Website | The React Website displays data through communication with the REST API in a very fashionable and user friendly way. | Philip Hägg, Fredrik Janetzky, Daniel Chouster |
Abstract
| This document describes the required behavior and interfaces of the REST API component. |
|---|
Version History
| Date | Version | Author | Description |
|---|---|---|---|
| 12/04/2022 | 1.0 | Fredrik Lundström | First Version |
| 24/05/2022 | 1.1 | Fredrik Lundström | Final Version |
| Introduction |
- Document Purpose
The purpose of this document is to describe the behavior and interfaces of the REST API component in order to:
- Enable the implementation effort to be sized and managed
- Establish the dependencies that exist with other components
- Support the independent development of this component
- Provide a basis for testing that the component operates as required.
- Document Scope
The scope of this document is limited to consideration of:
- The specification of the required behaviors for this component
- The specification of the interfaces that this component must implement
- Listing the required interfaces that this component depends upon
- Optionally specifying the internal structure and design of the component.
This scope of this document does not include consideration of:
- The unit tests that required to verify that this component conforms and performs to its specification
- The specification or implementation of any other components that depend upon this component or that this component depends upon.
- Document Overview
This document contains the following sections:
- Required Behavior – behavior that is required from the component in terms of the responsibilities that it must satisfy and related requirements
- Implementation Constraints – constraints like implementation environment, implementation language and related patterns, guidelines and standards
- Provided Interfaces – the interfaces that the component must provide specified in terms of their signatures and constraints
- Required Interfaces – lists the interfaces that the component depends upon
- Internal Structure – optionally specifies the internal design structure of the component in terms of its constituent components and their relationships
- Internal Element Designs – optionally specifies the internal design of the constituent elements the component.
- References – provides full reference details for all documents, white papers and books referenced by this document.
- Required Behavior
The required behavior of the REST API is that it should provide crucial weather data for the web application. To provide this data for the web application it has to get data from a database and process the data so it can be handled easily by the web application. The REST API component does not require any maintenance once it is deployed and tested. The REST API will be an application that is runned constantly on a server so that the web application can fetch weather data at any time. Since the REST API does not alter the database in any way and only fetches processed data it does not have do log anything but errors that can occur. There is no need to control the application when it is deployed and tested.
- Implementation Constraints
The deployment environment this REST API application must operate in is a virtual computer. This virtual computer will act as a server that the web application can send HTTP requests to. Since this virtual computer must be accessible and running at all times it could be runned on the Microsoft Azure cloud service [1]. This virtual machine will be accessed through a terminal emulator such as PuTTY [2]. The REST API component will be written in the Java programming language and database queries will be written in SQL. The REST API will be built in a Model View Controller (MVC) pattern. The model will consist of a day of weather. The model also has a corresponding integrated DAO. The DAO will handle database calls and process the results into models. The controller will make the result models into JSON objects that can be sent through a socket. JSON is a standard for sending objects with REST APIs.
- Provided Interfaces
The REST API will provide a terminal interface where the user can see all of the connections to the socket and errors if they occur. The REST API component is mostly a machine to machine interface and communicates through HTTP requests and responses.
- Required Interfaces
The only required and crucial interface is the machine to machine interface. The REST API will communicate with the web application automatically (the user only has to access the website). The communication is made through HTTP.
- Internal Structure
The structure of the REST API component consists of a model and a controller. An integration layer is also included in the model. The controller communicates with the view (which in this case is the web application) and then communicates with the integration layer (DAO) which creates objects found in the model layer of what it fetches from the database.
- Internal Element Designs
The elements found in the REST API component, as mentioned earlier, are the model, controller and DAO. The controller consists of two parts. One that runned at all times waiting for HTTP requests from the web application and one that will handle logic. The logical controller will communicate with the DAO. The DAO will be able to handle two types of calls. One for fetching current weather data and one that will fetch a nine day forecast from the database. The model will be the simplest layer since it will only consist of one object. The object will be a day and hold information of that day such as date, temperature, humidity and air pressure. The day object will have a corresponding set and get methods for each object value.
Appendix A - References
Use this section to give full reference details for all documents, white papers and books that are referenced by this document.
[1] Microsoft, Virtual Machines (VM), https://azure.microsoft.com/sv-se/services/virtual-machines/, read 12:15 24th of May 2022.
[2] PuTTY, https://www.putty.org/, read 12:42 24th of May 2022.
Abstract
| This document describes the required behavior and interfaces of the Machine Learning component. |
|---|
Version History
| Date | Version | Author | Description |
|---|---|---|---|
| 12-04-2022 | 1.0 | Casper Kristiansson | First Version |
| 24-05-2022 | 1.1 | Casper Kristiansson | Updated version, updated and added new components to Internal Element Designs. Rewrote a couple of sections |
Introduction
- Document Purpose
The purpose of this document is to describe the behavior and interfaces of the Machine Learning component in order to:
- Enable the implementation effort to be sized and managed
- Establish the dependencies that exist with other components
- Support the independent development of this component
- Provide a basis for testing that the component operates as required.
- Document Scope
The scope of this document is limited to consideration of:
- The specification of the required behaviors for this component
- The specification of the interfaces that this component must implement
- Listing the required interfaces that this component depends upon
- Optionally specifying the internal structure and design of the component.
This scope of this document does not include consideration of:
- The unit tests that required to verify that this component conforms and performs to its specification
- The specification or implementation of any other components that depend upon this component or that this component depends upon.
- Document Overview
This document contains the following sections:
- Required Behavior – behavior that is required from the component in terms of the responsibilities that it must satisfy and related requirements
- Implementation Constraints – constraints like implementation environment, implementation language and related patterns, guidelines and standards
- Provided Interfaces – the interfaces that the component must provide specified in terms of their signatures and constraints
- Required Interfaces – lists the interfaces that the component depends upon
- Internal Structure – optionally specifies the internal design structure of the component in terms of its constituent components and their relationships
- Internal Element Designs – optionally specifies the internal design of the constituent elements the component.
- References – provides full reference details for all documents, white papers and books referenced by this document.
- Required Behavior
This section specifies the behavior that is required from the component in terms of:
- The responsibilities that it must satisfy
- The functions or services it must provide for its clients
- The non-functional requirements that relate to each of these
- Any other maintenance, documentation, reuse, control or logging requirements that relate to the component.
The responsibilities that the machine learning module most satisfy is to be able to give accurate and reliable predictions. The machine learning module also includes working with and cleaning the previous years of weather data that the prediction module will use.
The functionalities and services that the machine learning module includes is producing the upcoming nine days of weather predictions. These predictions are being run on the Microsoft Azure servers once every day.
The non-functional requirements are that the predicted data and service should be reliable. In other terms, it’s important that the predictions are being made every day without any hiccups.
The prediction model will require maintenance occasionally to rebuild the model in order to provide a better prediction model. This can easily be done by simply compiling the new model with the newly added data. (This is not a must but can provide better predictions in the future).
All steps and functions regarding the prediction model and the methods for working with data have relevant documentation and information so that the model can easily be reproduced.
- Implementation Constraints
This section specifies the constraints acting upon the implementation of the component, such as:
- The deployment environments within which it must operate
- What language(s) it must be written in
- The component frameworks it should operate within
- Design patterns it should conform to
- Other architectural standards and structures to which it must conform
- Guidelines that should be followed, including modeling guidelines and coding guidelines and standards
- Environment constraints such as memory footprint and other resource usage constraints.
The components deployment environment which it will operate in, is Microsoft Azure server (virtual machine) [1]. The virtual machine will be running Ubuntu which will be able to provide a terminal window which the component will easily be accessed from.
The component will be written in the programing languages python and java. The machine learning part of the program uses the Tensorflow library [2]** to create a handle the prediction model. Other important libraries that the component will be using is Pandas [3] to manage and load the data.
The methods for managing the data, designing the model and other methods will be mostly written using jupyter notebooks. This is because the notebooks will easily be able to provide an easy overview when design the model and working with the data. But also, because most of these functions only will be called once a notebook provides a better alternative.
- Provided Interfaces
This section specifies the interfaces that the component must provide in terms of their signatures and constraints.
The interface that the component will be using is the terminal window of the ubuntu machine. The ubuntu machine will have the prediction functions running from time to time (once a day) which later will give output to the terminal window.
- Required Interfaces
This section lists the interfaces that the component depends upon to fulfill its specified behavior.
The required interface that the component depends upon is the connection between the machine and the Microsoft Azure database. The entire component will not be accessed by the user but will work as a back-end module. Once the predictions have been made the component will upload the predictions to the database.
- Internal Structure
This section optionally specifies the internal design structure of the component in terms of its constituent components and how these collaborate to deliver the required component behaviors.
The functions that were created to design the model will only be run once, this also includes the functions for working and managing the data. The other part of the component such as the prediction model will be running once a day. The predicted weather will then be written to a CSV file. The ubuntu machine will then afterwards upload the predictions from the CSV file to the database.
The component also has functionality to update a local CSV file which the prediction model uses to make the latest predictions. That CSV file is updated once every day with the latest weather from the IoT device.
- Internal Element Designs
This section optionally specifies the internal design of the constituent elements that component.
The different elements of the component can be divided into two parts, elements which will only be used once and elements which will be used every day. The elements which will only be used once are:
- Functions for creating and design the model
- Functions for handling and managing the previous years of weather data
The elements which will be used everyday:
- Element which loads in the model and produces the latest predictions
- Function for updating the local weather data with the latest weather data from the IoT device
- Element for uploading the latest predictions to the Microsoft Azure database
As mentioned above the last three functionalities will be collaborating with each other to produce the latest predictions every day and updating the Microsoft Azure database with that data.
Appendix A - References
Use this section to give full reference details for all documents, white papers and books that are referenced by this document.
[1] Microsoft, Virtual Machines (VM), https://azure.microsoft.com/sv-se/services/virtual-machines/, read 12:15 24th of May 2022.
[2] https://www.tensorflow.org/learn, read 13:30 24th of May 2022.
[3] https://pandas.pydata.org/, read 13:30 24th of May 2022.
Abstract
| This document describes the required behavior and purpose of the IoT- device component. |
|---|
Version History
| Date | Version | Author | Description |
|---|---|---|---|
| 12/04/2022 | 1.0 | Ville Vik | First Version |
| 24/05/2022 | 1.1 | Ville Vik | Final Version |
| Introduction |
- Document Purpose
The purpose of this document is to describe the behavior and purpose of the IoT-device component in order to:
- Enable the implementation effort to be sized and managed
- Establish the dependencies that exist with other components
- Support the independent development of this component
- Provide a basis for testing that the component operates as required.
- Document Scope
The scope of this document is limited to consideration of:
- The specification of the required behaviors for this component
- The specification of the interfaces that this component must implement
- Listing the required interfaces that this component depends upon
- Optionally specifying the internal structure and design of the component.
This scope of this document does not include consideration of:
- The unit tests that required to verify that this component conforms and performs to its specification
- The specification or implementation of any other components that depend upon this component or that this component depends upon.
- Document Overview
This document contains the following sections:
- Required Behavior – behavior that is required from the component in terms of the responsibilities that it must satisfy and related requirements
- Implementation Constraints – constraints like implementation environment, implementation language and related patterns, guidelines and standards
- Provided Interfaces – the interfaces that the component must provide specified in terms of their signatures and constraints
- Required Interfaces – lists the interfaces that the component depends upon
- Internal Structure – optionally specifies the internal design structure of the component in terms of its constituent components and their relationships
- Internal Element Designs – optionally specifies the internal design of the constituent elements of the component.
- References – provides full reference details for all documents, white papers and books referenced by this document.
- Required Behavior
The IoT-device has the responsibility to provide the IoT-system with current weather data, once an hour. To send the data through the pipeline to the database the data must be in CSV format which then later gets converted to SQL for the database. Furthermore, the sensor picking up the weather data has to pick up reliable and consistent data, which means the positioning is important.
- Implementation Constraints
The script that sends the data to the cloud must be made so that it can operate on a Raspberry Pi with Raspberry Pi OS. For this action to work the Raspberry Pi has to have a stable internet connection. The IoT-system uses Microsoft Azure as the cloud service which means that the script also needs to have a way to connect to Azure services in the form of an IoT-hub. Microsoft themselves recommend using python to connect to the hub. The sensor also has its library for python which also means that all the code can be written to one single script in one single language which is also what we will do.
- Provided Interfaces
The script on the Raspberry Pi runs on a PuTTY-terminal at all times where you are able to confirm that all the data is correct and whether it successfully sends data to Azure. Azure also provides an interface for Visual Studio code where you can monitor the device to cloud messages.
- Required Interfaces
The IoT- device depends upon a connection between the device and the cloud to be able to send messages through. All the readings from the backend are made through Azure rather than the device directly.
- Internal Structure
The IoT-device consists of a Raspberry Pi to run the script and connect to Azure, a weather sensor reading the data and also the physical parts to mount the weather station at an appropriate place.
Appendix A - References
[1]
Abstract
| This document describes how the React Website is going to be built and the concerning functionalities. |
|---|
Version History
| Date | Version | Author | Description |
|---|---|---|---|
| 12/04/2022 | 1.0 | Fredrik Janetzky, Philip Hägg, Daniel Chouster | First Version |
| 24/04/2022 | 1.1 | Fredrik Janetzky, Philip Hägg, Daniel Chouster | Second version |
| Introduction |
- Document Purpose
The purpose of this document is to describe the behavior and interfaces of the React Website component in order to:
- Enable the implementation effort to be sized and managed
- Establish the dependencies that exist with other components
- Support the independent development of this component
- Provide a basis for testing that the component operates as required.
- Document Scope
The scope of this document is limited to consideration of:
- The specification of the required behaviors for this component
- The specification of the interfaces that this component must implement
- Listing the required interfaces that this component depends upon
- Optionally specifying the internal structure and design of the component.
This scope of this document does not include consideration of:
- The unit tests that required to verify that this component conforms and performs to its specification
- The specification or implementation of any other components that depend upon this component or that this component depends upon.
- Document Overview
This document contains the following sections:
- Required Behavior – behavior that is required from the component in terms of the responsibilities that it must satisfy and related requirements
- Implementation Constraints – constraints like implementation environment, implementation language and related patterns, guidelines and standards
- Provided Interfaces – the interfaces that the component must provide specified in terms of their signatures and constraints
- Required Interfaces – lists the interfaces that the component depends upon
- Internal Structure – optionally specifies the internal design structure of the component in terms of its constituent components and their relationships
- Internal Element Designs – optionally specifies the internal design of the constituent elements the component.
- References – provides full reference details for all documents, white papers and books referenced by this document.
- Required Behavior
This section specifies the behavior that is required from the component in terms of:
The website should be able to show the current weather and the nine day prediction from the Machine Learning model. All this data should be presented in an appealing way to the user. The website should fetch data from the Rest API component that will provide the data to the website. There should be a webpage that describes who each individual in the group is and what their responsibilities are. For the website there should be a statistics page that shows the user some statistics that could be compared with the predicting results.
Each react component that is developed is supposed to be dynamic and can be reused in other parts of the website. The code should be easy to understand and maintain. In order to do this the group will develop their own components so there are a small amount of dependencies to libraries. This is important so that the group won't have to change the code, due to deprecated or changed functions.
The website should be developed in a way that it can be easily maintained by other programmers and also possible to scale with new functionalities.
- Implementation Constraints
This section specifies the constraints acting upon the implementation of the component, such as:
The application will be written in JavaScript, HTML and CSS. The main framework used will be React.js. The code is required to be easy to understand in order to make it sustainable and reusable according to the sustainability plan so that anyone can easily modify it for future use or to find bugs. The developers must follow the MVC design pattern which will also contribute to a sustainable software and the entire project will be deployed using Microsoft Azure.
Furthermore, functionalities in the program need to be tested with unit tests according to the test plan to make sure that everything is in order and works as intended. This will also help the developers to find eventual bugs or logical errors that might not be obvious right away.
- Provided Interfaces
The interface will be a user friendly interface on the internet that will communicate with the end user.
- Required Interfaces
The interface requires to be understood by the user and should be easy to navigate through. This interface will also communicate with the rest API interface and therefore it should be machine to machine implementations.
- Internal Structure
Some structure should be in place, according to the architecture this view is connected to a MVC pattern. Where this component is the view. Therefore there will be no need to implement a presenter pattern in between, to make the app work correctly. The component should be split up in a specific structure, where the component library is contained inside a package and their corresponding design in another package. The same goes for the views. All files with their responsibilities are divided into separate packages.
- Internal Element Designs
As a part of the view layer, the website needs to communicate to the Rest API through a fetching function. This function is not tokenized.
The different components should be designed in a way that they can be reused by other parts of the application. Some of these components show the data that has been fetched from the Rest API.
The pages contain a composition of the components. With a navbar that are routed between sections.
Appendix A - References
Use this section to give full reference details for all documents, white papers and books that are referenced by this document.
[1]
| WeatherBrain @2022 |
|---|
WeatherBrain @2022