0% found this document useful (0 votes)
12 views3 pages

Architecture Document

The document outlines various architectural options for a student project, including Microservices, Event-Driven, and Serverless architectures, each with specific services and benefits. It details the database schema, including entities like USER, SAMPLE, and ANALYSIS, along with their relationships and SQL table structures. Additionally, it describes data exchange contracts, specifying the frequency, datasets, and modes of data exchanges for the application.

Uploaded by

Aryan Shahi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
12 views3 pages

Architecture Document

The document outlines various architectural options for a student project, including Microservices, Event-Driven, and Serverless architectures, each with specific services and benefits. It details the database schema, including entities like USER, SAMPLE, and ANALYSIS, along with their relationships and SQL table structures. Additionally, it describes data exchange contracts, specifying the frequency, datasets, and modes of data exchanges for the application.

Uploaded by

Aryan Shahi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Architecture Document

(The student team can select one of the following architectures for their project and they
should provide a detailed explanation: Microservices, Event-Driven Architecture,
Serverless, or Monolithic architectures. Additionally, they should create relevant
diagrams, such as use case, class, DFD, component, sequence, and deployment
diagrams, to support their project.)

1. Application
1.1 Microservices
●​ The project can adopt a microservices
architecture to decouple components like:
o​ Image Preprocessing Service:
Handles normalization and prepares
raw input images for augmentation.
o​ Model Inference Service: Deploys
CNN or Transformer networks for
feature extraction and classification.
o​ User Interface Service: Provides
tailored interfaces for farmers,
consultants, and admins for results,
trends, and system configurations
1.2 Event-Driven
●​ Implement an event-driven approach to improve scalability:
o​ Trigger events upon user actions, such as uploading images, initiating model
predictions, or saving results.
1.3 Serverless
●​ Use serverless platforms like AWS Lambda, Azure Functions, or Google Cloud
Functions for:
o​ On-demand image processing and classification to reduce operational costs.
o​ Scalable handling of user requests with automatic resource provisioning.
2. Database
2.1 ER Diagram
Entities:

1.​ USER
●​ Track who uploads samples
●​ Contains: user ID, username, role
2.​ SAMPLE
●​ Environmental sample details
●​ Includes: sample ID, type, location, image
3.​ ANALYSIS
●​ Sample analysis results
●​ Contains: contamination level, detection details
4.​ MICROPLASTIC_DETECTION
●​ Specific microplastic findings
●​ Includes: plastic type, concentration, risk level
5.​ MODEL
●​ Machine learning model metadata
●​ Contains: model name, architecture, accuracy

Key Relationships:

●​ USER uploads SAMPLE


●​ SAMPLE goes through ANALYSIS
●​ ANALYSIS produces MICROPLASTIC_DETECTION
●​ MODEL performs ANALYSIS

2.2 Schema Design


-User Table CREATE TABLE users
( user_id SERIAL PRIMARY KEY,
username VARCHAR(50) UNIQUE NOT NULL,
email VARCHAR(100) UNIQUE NOT NULL,
role VARCHAR(20) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

-- Sample Table CREATE TABLE samples


( sample_id SERIAL PRIMARY KEY,
user_id INTEGER REFERENCES users(user_id),
sample_type VARCHAR(50) NOT NULL,
location VARCHAR(100), collection_date DATE NOT NULL,
image_path VARCHAR(255), latitude DECIMAL(10,8),
longitude DECIMAL(11,8) );

-- Model Table CREATE TABLE models


( model_id SERIAL PRIMARY KEY,
model_name VARCHAR(100) NOT NULL,
architecture VARCHAR(50) NOT NULL,
training_date DATE NOT NULL,
accuracy DECIMAL(5,2), version VARCHAR(20) );

-- Analysis Table CREATE TABLE analysis


( analysis_id SERIAL PRIMARY KEY,
sample_id INTEGER REFERENCES samples(sample_id),
model_id INTEGER REFERENCES models(model_id),
contamination_level DECIMAL(5,2),
detection_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
status VARCHAR(20) );

-- Microplastic Detection Table CREATE TABLE microplastic_detection


( detection_id SERIAL PRIMARY KEY,
analysis_id INTEGER REFERENCES analysis(analysis_id),
plastic_type VARCHAR(50),
concentration DECIMAL(6,3),
risk_level VARCHAR(20),
size_range VARCHAR(50) );

3 Data Exchange Contract


3.1 Frequency of Data Exchanges:
●​ Real-Time: For uploading images and retrieving diagnostic results.
●​ Periodic: Logs and diagnostic summaries can be exported daily/weekly for analysis.
3.2 Data Sets:
●​ Input: Raw images of soil and water, metadata (e.g., location, sampling time,
environmental parameters).
●​ Output: Detection results, microplastic concentration data, and usage logs.
3.3 Mode of Exchanges:
●​ API: For real-time image uploads and retrieving results via REST/GraphQL APIs.
●​ File: For bulk uploads of images or exporting data for research purposes.
●​ Queue: For asynchronous processing, e.g., uploading images to a queue for batch
analysis.

You might also like