Package: breath-main
BReATH - Brazilian Research of Atmosphere Towards HealthBReATH project aims to create a interface to visualize and get insights relating asthma and weather data.It depends on our other modules:breath_api_interfaceto connect all our modules.Gitlab mirror.breath_datafor data operations.Gitlab mirrorbreath_mlfor machine learning operations.How to execute:Installbreath_main:Windows:python -m pip install breath_mainLinux:pip3 install breath_mainInstalltensorflow:Windows:python -m pip install tensorflowLinux:pip3 install tensorflowRun breath_main:Windows:python -m breath_mainLinux:python3 -m breath_mainSelect operation in the menu (enter the desired option)Features:We have some features implemented:Search for some brazilian city in the data bank, returning its position, state and population; and making it available to perform other operations. Implements#37Plot a city's history of cases of fever, cough, or sore throat. Implements#27Show a city's cases in some specific date. Implements#28View current weather data in the city. Implements#21,#13,#39.Predicts the occurrence of current cases of fever, flu or cough in the city. Implements#33. NOTE: The model is still under development, and at the moment it does not make very correct predictions.Register new user symptoms. Implements#30.Authors233840, Elton Cardoso do Nascimento218733, João Pedro de Moraes Bonucci240106, Lucas Otávio Nascimento de Araújo244712, Thiago Danilo Silva de LacerdaSoftware architectureOur software system is architected using C4 and UML diagrams. This repository contains the main application and service management, with other services separated across multiple repositories, containing our different Python modules. It was divided in this way to help manage the different activities of the disciplines linked to this project.ContextThis project context consists of 3 stakeholders, the Patient, the Health Manager, and the Physicist/Medic, which have access to 2 different sets of features: the Map visualization and the patient portal.
The first set consists of an interface with geolocalized information about climate, respiratory diseases, air quality, and history of respiratory diseases through time by city. This service also estimates the number of cases for the following days through the air quality and climate information.
The second set of features show a widget that condensates the information of the climate and air quality. It also shows the consequences of those for the patient's symptoms and offers some tips on how to avoid or mitigate them.
A Session Manager will link the frontend services to the background services of Data workflow, Prediction, and Data requests from exterior sources. In addition, it is responsible for writing and retrieving data from relational and graph databases.Container and componentsContainer diagramOur container level describes ourservice-oriented architecture. Each service performs a set of operations, and is isolated in a different Python process.Within the containers section we also have the component and code level description. We describe only the main and the already designed components of the architecture, as some are related to features not yet started.Session Manager:This container orchestrates service requests, and handles the login session.RequestSessionManager:Handles the lifecycle of a request, from receiving it to sending its response.
We used theChain of Responsibilitydesign pattern to create it, as can be seen on its code diagram. Because we use Python, which supports multiple inheritance, we use an abstract class, as there is no difference between it and an interface.Code diagramBReATH Map and Patient Portal:These containers have a Layering Structure that intends to be an MVC. Divided into View, the top layer, Model, the middle layer, and a ServiceProxy as the bottom layer and link with the session manager. We used theProxyDesign Pattern because of the service request complexity.In the current version, we are temporarily using ConsoleApplication, terminal version of the applicationDataWorflow:This container acts as a data formatter and validator before saving it into the database. Regarding this behavior, we used anAdapterdesign pattern to clean and reshape the data for the rest of the application.DataRequester:This container is responsible for requesting and receiving data from external APIs. Due to the possible asynchrony of the task, we used theObserverdesign pattern to make sure the rest of the application could continue without problems. However, we also decided to implement theabstract factorydesign once we could switch APIs or add new ones in the future.It was put together as part of DataWorkflowPrediction:The Prediction module has an ML model, implemented in TensorFlow, used to predict in real-time the consequences of the climate and air quality over the symptoms and occurrences of respiratory diseases. As this is a central point of the application, it will receive a large number of requests. For this reason, we used aProxyDesign to help handle those.BDAcessPoint:The access point uses afactoryDesign pattern for the two possible databases to make the queries faster. The Design is divided through the GraphQuerier, RelationalQuerier, and RequestProcessor, which is the factory controller.The graph database was not usedDatabases:SQL: Users, patients, symptoms and diagnosis. Also geolocated atmosphere data. It will use SQLite.Graph: Geographical information (political wise), relationship between symptoms and diseases. It will use Neo4j.