tanszek:oktatas:test
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| tanszek:oktatas:test [2025/03/10 11:16] – knehez | tanszek:oktatas:test [2025/04/07 16:32] (current) – [1.) Water Quality Monitoring System] knehez | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ==== General requirements ==== | ||
| + | |||
| + | * Use Docker containerization | ||
| + | * Use RabbitMQ (or similar) messaging queue | ||
| + | |||
| ==== 1.) Water Quality Monitoring System ==== | ==== 1.) Water Quality Monitoring System ==== | ||
| - | 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 for generating, processing, and reporting water quality data. | + | 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/ |
| Component 1: Water Quality Data Generation Client | Component 1: Water Quality Data Generation Client | ||
| Line 16: | Line 21: | ||
| * The correct identification of critical water quality readings. | * The correct identification of critical water quality readings. | ||
| * The accurate accumulation and dispatch of alerts after detecting critical water quality conditions. | * The accurate accumulation and dispatch of alerts after detecting critical water quality conditions. | ||
| + | |||
| + | ---- | ||
| ==== 2.) RGB-Colors System ==== | ==== 2.) RGB-Colors System ==== | ||
| Line 60: | Line 67: | ||
| Create tests to validate the original functionality | Create tests to validate the original functionality | ||
| + | |||
| + | ---- | ||
| ==== 3.) Temperature Alert System ==== | ==== 3.) Temperature Alert System ==== | ||
| Line 84: | Line 93: | ||
| * The accurate accumulation and dispatch of alerts after every 5 abnormal readings. | * The accurate accumulation and dispatch of alerts after every 5 abnormal readings. | ||
| + | ---- | ||
| ==== 4.) Humidity Control System ==== | ==== 4.) Humidity Control System ==== | ||
| Line 106: | Line 116: | ||
| * The accurate accumulation and dispatch of alerts after detecting high humidity conditions. | * The accurate accumulation and dispatch of alerts after detecting high humidity conditions. | ||
| + | ---- | ||
| ==== 5.) Air Quality Monitoring System ==== | ==== 5.) Air Quality Monitoring System ==== | ||
| Line 128: | Line 139: | ||
| * The accurate accumulation and dispatch of alerts after detecting poor air quality conditions. | * The accurate accumulation and dispatch of alerts after detecting poor air quality conditions. | ||
| + | ---- | ||
| ==== 6.) Light Intensity Monitoring System ==== | ==== 6.) Light Intensity Monitoring System ==== | ||
| Line 149: | Line 161: | ||
| * Low light detection: Check that the processor correctly identifies 3 consecutive values below 100 lux. | * 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. | * 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 // | ||
| + | - 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 // | ||
| + | |||
| + | Component 3: Alert Reporting Client | ||
| + | - Consumption: | ||
| + | - 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: | ||
| + | * 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 // | ||
| + | - 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 // | ||
| + | - 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 // | ||
| + | |||
| + | Component 3: Alert Reporting Client | ||
| + | - Consumption: | ||
| + | - 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. | ||
tanszek/oktatas/test.1741605374.txt.gz · Last modified: 2025/03/10 11:16 by knehez