shravanshidruk16/te-dsbda-72311412k-shravan-shidruk

This repository is best understood as an educational monorepo, not a single application. It contains many independent lab exercises, each with its own notebook/script, inputs, and often a small write-up. There is very little shared code across folders, so the main architectural boundary is the experiment directory itself.

The top-level structure splits into three broad areas:

• DSBDA laboratory experiments (Experiment_1 through Experiment_13)

• AI and cloud computing practicals under AI_CC_PRACTICALS

• Mini projects, especially the loan approval system and other notebook-based projects

For an architecture diagram, each experiment should be shown as a self-contained pipeline: dataset or input file → notebook/script → output artifacts/plots/metrics. Most of the Group A experiments follow this pattern in Jupyter notebooks, with CSV inputs such as Titanic, Iris, Housing, Netflix, Social Network Ads, and Students Performance datasets.

The Group A notebooks are focused on data science workflows:

• data loading and preprocessing

• missing value and outlier handling

• descriptive statistics

• regression and classification

• text analysis with TF/IDF

• data visualization with seaborn and matplotlib

These notebooks are interactive analysis units rather than reusable services.

The Group B experiments introduce distributed/data-processing systems:

• Experiment 11 is a Hadoop MapReduce log analysis job using LogMapper, LogReducer, and a driver/processor class, with input log files and generated output partitions

• Experiment 12 is another MapReduce pipeline for weather aggregation using WeatherMapper, WeatherReducer, and a driver, with sample weather input and reducer output

• Experiment 13 is a Scala Spark word-count style program with a text input file

These should be diagrammed as batch-processing jobs with explicit mapper/reducer or Spark execution boundaries.

The mini project: Loan Approval System is the most complete application-like subsystem in the repo. It includes:

• app.py, which is likely the runtime entry point

• serialized ML artifacts in models/ such as logistic regression, random forest, scaler, and label encoders

• model_metrics.json for evaluation results

• assets/ for generated EDA outputs and Streamlit app resources

This looks like an inference-oriented ML app: user input or form data flows into preprocessing, then into a trained model, then to a prediction/result displayed by the app.

The loan project’s architecture is important because it separates training artifacts from runtime inference. The notebooks likely produced the models and charts, while app.py consumes the saved encoders/scaler/model files without retraining. That is the key boundary for diagramming the system.

The AI practicals folder contains classic AI algorithm demos as standalone Python scripts:

• BFS/DFS

• A* game search

• Dijkstra shortest path

• Kruskal’s MST

• selection sort

• N-Queen CSP

• chatbot

• hospital expert system

These are algorithm-centric scripts, each independent and likely console-based, so they should be represented as isolated examples rather than a single connected pipeline.

The cloud computing practicals area is minimal in the tree, but the presence of a PDF and README suggests it is documentation-driven rather than code-heavy. It appears to serve as course material or lab reference rather than a deployed service.

Across the repository, the dominant runtime technologies are:

• Python/Jupyter Notebook for analytics, visualization, and ML experiments

• Java/Hadoop MapReduce for batch distributed processing

• Scala/Apache Spark for distributed data processing

• Streamlit-style Python app for the loan approval mini project

Data flows are almost always local and file-based. Inputs are stored as CSV, TXT, or notebook-managed datasets; outputs are notebooks, plots, metrics, model files, or Hadoop output directories. There is no evidence of databases, APIs, message queues, or persistent backend services.

In practical diagram terms, the repo should be shown as a collection of independent learning modules with three major execution styles:

1. Interactive analytics notebooks

2. Batch/distributed data-processing jobs

3. ML application with saved model artifacts and a UI layer

The clearest architectural message is that this repository is a coursework portfolio: it demonstrates a progression from preprocessing and statistics, to ML and visualization, to distributed systems, to small applied ML deployment.