Weather Monitoring System UML design

Abstract:

The report presents the usage of patterns in the UML layered class design of the weather monitoring system. The weather monitoring system is based on the weather condition changes, the sensors that read these changes are connected to the system and the system reads the values from these sensors. The users of the system can check the readings of the sensors in a presentable format. There are two main categories of the usage of the system by the users. First is the usage of the system as a monitor that display the sensor reading and the calculated readings from these sensor reading on the display device as they change. This is a live view of the sensor readings. The second usage category is the reports that the system can generate. The system can generate many reports based on the historical data stored in the system. The Report presents the UML design of the system that caters these functionalities in the weather monitoring system.

Introduction:

The Weather monitoring system is designed in the report using the layered design class diagram and the patterns that can be used in the design of the class. The weather monitoring system has a use case of displaying the latest readings from the sensors to the monitoring display device to the user. The report also includes the sequence diagram of this use case. Furthermore the report includes the state chart diagram for the states of the major classes involved.

The classes in the class diagram are distributed in a layered architecture to make the design use of patterns like MVC Model View Controller. The Model has the core functionality of the system, to provide low coupling in the system the model is implemented through the Controller and presented the functionality to the users. The system has a functionality to update the live view of the readings from the sensors on a display screen. This functionality involves no input or interaction from the users, the syst4em automatically updates the display reading to the display device as they change and the system is intimated by the change in the sensor. For this kind of functionality the Observer pattern is used to perform this function, the observer pattern is implemented where there is very little or no input from the users. The report uses patterns where necessary and also presents the description of the functions and procedures In the Design. 

Layered Design Class Diagram:

The class diagram presented above is the layered class diagram of the weather monitoring system presents in a Model UI and Controller Architecture.

1.1: Design Class diagram discussion:

The class diagram is distributed as the architecture of the system suggests the partition of classes for the User Interface, Model and Controller classes. The classes are named using the prefix “cls” before their names. The classes for the User Interface are placed in the UI layer. The UI layer is responsible for displaying the data on the display screen and the printing data. This layer also gets the inputs from the users for the calibration of the values. There are three classes in the UI layer. ClsReportsUI class which has functions to display report options, get user choice for report viewing, and display two types of report.

The other class in the UI Layer is the clsValuesCalibration. This class is responsible for updating the default values of the sensors. This class has functions to get and set the values.

The third class in the UI Layer is the clsDisplaySensorvalues. This class has functions get sensor values; this gets the latest sensor values when intimated by the Observer class. The displaySensor values are responsible for printing values on the screen. The Update screen is responsible for updating the user screen when new values are arrived.

The controller layer is responsible for management of the system the controller as classes, clsReportDataController and clsValueCalibrationController. clsReportDataController has methods to get Values to get values of individual sensors and get Report Values to get the values for presenting the reports.

The clsReportCalibrationController calss has function which sets the values of the sensors.

There is an interface for the observer pattern in the controller layer named iSensorValues. This invokes the User Interface Change when the model is changed; it has a function notifySensorVAlueUpdate which is called when the sensor values are changed in the model.

In the model layer we have defined the core functionality of the system. The functions related to the calculations of derived values and the management of time and values read on a specific time. All these are defined in the model layer.

The model layer has classes related to the sensor and the observer pattern. The class for the core values that need to be stored is clsSensorValue class. This class has methods getDateTimeValue and serDateTeimValue to get and update the date and time of the system. getWindSpeedValue and setWindSpeedValue to get and update the WindSpeedValues. setHumidityValue and getHumidityValue to update and get the Humidity, setBarometricPressureValue and getBarometricPressureValue to get and set the Barometric Pressure values. setTemeratureValue and  getTemeratureValue to get and update the Temperature. setWindDirectionValue and getWindDirectionValue to get and update the Wind direction values.

The second class is clsSensorValueRecord is the which has the functions getValues that  gets the values of individual sensor values. The hetHighLowReportValues and getMinMaxReportValues for the data of the reports. The setValues function that stores the default Values for the sensors.

The third class is clsUpdateSensorValues, this class works with the Observer Interface and provide functions as attachObserverClass to attach the observer, deattachObserverClass, NotifyObserverClass to notify for any changes in the values, getStateObserverClass and setStateObserverClass to get and set the states of observer. getensorValue Records to get the Values of the sensors.

1.2: Usage of Pattern:

The UML model has employed MVC, Observer, controller and low cohesion as the patterns for the weather monitoring system design, the justification of their use is described below.

Model View Controller:

The Model view controller is used for the layered architecture of the model the model is based on the layers for creating the User Interface, model that depicts the core functionality of the system and the controller that controls the working of the system. The model view controller is the pattern that fits for development of the system that has low coupling and high cohesion. The classes are implemented in a way that the functionality that they provide is coherent and their dependency on each other is minimized; the classes’ indifferent layers are not dependent directly on the other classes in other layers and the User interface is not directly interacting with the model. This makes Model View Controller as a best choice for the implementation of such system.

Observer:

The observer pattern is used for the display values use case implementation, the use case does not have an interactive functionality thus the values when changed should automatically updated on the user screen, to implement this functionality the observer pattern is he best choice, the model view controller is also use full in the implementation and these both patterns works well together.

The other patterns used are low coupling and controller pattern. These are used in the classes to minimize the class dependency and providing the functionality through standard practices.

2: Sequence Diagram for the Use Case Display Sensor Values:

The sequence diagram of the display fresh sensor values use case of the system is presented in the above diagram. The clsDisplaySensorValues class is notified by the observer for any change in the readings through the method notifySersorValueUpdate( ). The display Values class calls the getSensorValuesRecords function of clsUpdateSensorValues class to get the updated values. The clsUpdateSensorValues class calls the getValues function of the clsSensorValueRecord class. Then the clsSensorValueRecord class calls the getDateTimeValue, getWindSpeedValue, getWindDirectionValue, getTemperatureValue, getBarometricPressureValue, getHumidityValue, functions of the clsSensorValue class. The clsSensorValueRecord class returns the SensorValueRecord to the clsUpdateSensorvalues class which returns the values to clsDisplaySensorValues class. This class presents the records on the user screen.

3: State Chart Diagram:

The above diagram depicts the state diagram of the Weather monitoring system class states. When the user opens the system, the user can choose among two options, this is the user Selection state. If the user selects the report to view then the user will go to displayvalues state. The observer will change this state once the new values are updated in the model. The Update Observer state goes to getData state once the values are updated, then it goes to make report state and the report is then presented in the UpdateObserver state.

On the other hand if in the user selection state the user chooses to view a report the system goes to Report selection state, and from then when the data is received the system goes to format and load report state.

Recommendations:

The system implementation has fairly used patterns in the UML design of the weather monitoring system. the implementation should take advantage of the patterns and make the low coupling and high cohesive system in order to add new sensors or interfaces in the system in future, To implement the system in the layered architecture and using patterns the benefits of the scalability and adaptability will become part of the system.

Conclusion:

The report has presented the UML design of the weather monitoring system using patterns from our study, the observer is used with Model View Controller and Controller and low coupling is also used to implement the functionality at different layers of the system.

The report has presented the model diagrams as well as the discussion and justification of the patterns used. The report ends with recommending the implementation of the system as a model view controller based and describes the future benefits that we can harvest through using this model.