Differences

This shows you the differences between two versions of the page.

--- tanszek:oktatas:test [2024/04/21 19:33] – [2.) Message queue] knehez
+++ tanszek:oktatas:test [2025/04/07 16:32] (current) – [1.) Water Quality Monitoring System] knehez
@@ Line 1: / Line 1: @@
-==== 1.) Prepaid Shop - Mobile Service Provider ====
+==== General requirements ====
-Create a simple HTML form where users are able to charge their mobile phones with a given amount of money.
+  * Use Docker containerization
+  * Use RabbitMQ (or similar) messaging queue
-   Possible amounts: $10, $30, $50, $100
+==== 1.) Water Quality Monitoring System ====
-   The 3 mobile service providers: "Provider A", "Provider B", "Provider C"
-   Mobile phone number: 7 numbers.
-Create a servlet which gets the HTTP GET request from the HTML form and checks the validity of the messages. If the message is invalid, then returns an "Invalid data" text, else writes "Ok".
+Develop an application that simulates monitoring and controlling water quality levels in a reservoir or river system using message queues. This system will involve three separate clients/components for generating, processing, and reporting water quality data.
-   * Create an inner class within servlet and store these payments in a java ArrayList.
-   * Create an other method to list the number of payments (with a new HTTP get request).
-==== 2.) Three colors ====
+Component 1: Water Quality Data Generation Client
+  * Client 1: Connects to the **waterQualityQueue** using a point-to-point connection.
+  * Function: Sends messages with randomly assigned water quality readings, focusing on parameters such as **pH** **levels**, every 5 seconds.
+Component 2: Water Quality Alert Processor
+  * Message Processor: Exclusively receives water quality readings from **waterQualityQueue**.
+  * Function: Monitors for critical water quality issues, such as extremely high turbidity or unsafe pH levels.
+  * Notification: After receiving 3 consecutive readings indicating critical conditions (e.g., pH below 5.0 or above 9.0), the processor sends a notification to the **waterQualityAlertQueue**, indicating that critical water quality levels have been detected.
+Create tests to validate:
+  * The functionality of sending and receiving messages correctly.
+  * The correct identification of critical water quality readings.
+  * The accurate accumulation and dispatch of alerts after detecting critical water quality conditions.
+----
+==== 2.) RGB-Colors System ====
 <mermaid>
 flowchart LR
@@ Line 54: / Line 67: @@
 Create tests to validate the original functionality
+----
 ==== 3.) Temperature Alert System ====
@@ Line 78: / Line 93: @@
   * The accurate accumulation and dispatch of alerts after every 5 abnormal readings.
+----
 ==== 4.) Humidity Control System ====
@@ Line 100: / Line 116: @@
   * The accurate accumulation and dispatch of alerts after detecting high humidity conditions.
+----
 ==== 5.) Air Quality Monitoring System ====
@@ Line 121: / Line 138: @@
   * The correct identification of poor air quality readings.
   * The accurate accumulation and dispatch of alerts after detecting poor air quality conditions.
+----
+==== 6.) Light Intensity Monitoring System ====
+Create an application that monitors indoor light levels (measured in lux). The system is composed of three separate clients: one for generating data, one for processing it, and one for alert reporting.
+Component 1: Light Intensity Generation Client
+  - Connection: This client connects to the lightIntensityQueue using a point-to-point messaging model.
+  - Function: Every 3 seconds, it sends random light intensity (lux) readings (e.g., between 0 and 2000 lux).
+Component 2: Light Intensity Processor
+  - Message Processing: This processor exclusively receives messages from the //lightIntensityQueue//.
+  - Evaluation: Determines whether the light level is too low. For example, consider values below 100 lux as "dark."
+  - Alert Trigger: If it encounters 3 consecutive readings below 100 lux, it sends an alert message to the lightAlertQueue stating, for example, “Low light alert: 3 consecutive readings below 100 lux.”
+Component 3: Alert Reporting Client
+  - Consumption: This client listens to the //lightAlertQueue// for alerts.
+  - Output: Prints any received alert to the console, for instance: "Low light alert: 3 consecutive readings below 100 lux."
+Create tests to validate:
+  * Message sending and receiving: Verify that light intensity values are correctly sent and received by the respective clients.
+  * Low light detection: Check that the processor correctly identifies 3 consecutive values below 100 lux.
+  * Alert mechanism: Ensure that the alert message is added to the lightAlertQueue and that the reporting client displays it on the console.
+----
+==== 7.) Sound Level Alert System ====
+Create an application that monitors sound levels (measured in decibels) in a given environment. It has three clients: one for generating noise level data, one for processing it, and one for reporting alerts.
+Component 1: Sound Level Generation Client
+  - Connection: This client connects to the soundLevelQueue using a point-to-point messaging model.
+  - Function: Every 2 seconds, it sends random decibel readings (e.g., between 30 dB and 120 dB).
+Component 2: Sound Level Processor
+  - Message Processing: Exclusively receives messages from the //soundLevelQueue//
+  - Evaluation: Determines if the sound level is above the threshold (e.g., 80 dB) considered "too loud."
+  - Alert Trigger: After collecting 5 “too loud” readings (either consecutively or within a certain timeframe—depending on your design), the processor sends a message to the //soundAlertQueue//: "High noise alert: 5 high decibel readings detected."
+Component 3: Alert Reporting Client
+  - Consumption: Subscribes to the soundAlertQueue
+  - Output: Prints to the console, for example: "High noise alert: 5 high decibel readings detected."
+Create tests to validate:
+  * Message sending and receiving: Ensure decibel readings flow correctly from the generation client to the processor.
+  * High noise identification: Check that readings above 80 dB are recognized properly.
+  * Alert message: Verify that an alert is sent to the soundAlertQueue and that the reporting client prints it to the console.
+----
+==== 8.) Pressure Monitoring System ====
+Develop an application that monitors fluid or gas pressure in a system. The task involves three clients: one that generates the pressure readings, one that processes them, and one that handles the alerts.
+Component 1: Pressure Generation Client
+  - Connection: Connects to the //pressureQueue// using a point-to-point messaging model.
+  - Function: Every 4 seconds, sends random pressure readings, for example, between 0 and 10 bar.
+Component 2: Pressure Alert Processor
+  - Message Processing: Exclusively receives messages from the //pressureQueue//.
+  - Evaluation: Determines if the pressure reading is dangerously high (e.g., above 8 bar).
+  - Alert Trigger: If it detects 2 consecutive readings above 8 bar, the processor sends an alert to the //pressureAlertQueue// stating: "High pressure alert: 2 consecutive readings above 8 bar detected."
+Component 3: Alert Reporting Client
+  - Consumption: Reads messages from the //pressureAlertQueue//
+  - Output: Prints the alert message to the console, for example: "High pressure alert: 2 consecutive readings above 8 bar detected."
+Create tests to validate:
+  * Message flow: Verify that pressure readings are correctly sent from the generation client to the processor.
+  * High pressure detection: Check that the processor accurately identifies readings above 8 bar.
+  * Consecutive reading logic: Ensure alerts are triggered only when there are 2 consecutive high readings.