How to Maintain the Data of Uses' Lifelogging - Case Study Example

Design Patterns Presented by Introduction An automatic health monitoring system can contain a wide variety of wearable sensors. This system is capable of recording the distance covered by a user in a specific duration, number of steps taken by the user while walking or running on a track, and the time a user takes to cover distance from a specific point. This system is also capable of determining the activity level of a user by aggregating and analysing recorded data. In addition, this system can also determine the heart rate, blood pressure, and compare them with specific ranges. If the system detects any problem, it can alert or notify the remote hospital (Teaw, et al., 2005; Aminian & Naji, 2013). In order to develop such a system, the software development team should make use of different design patterns because these patterns help them detect problems that arise during the development. It also provides an effective solution of problems (Martin, 2000). “In object oriented architectures, a design repeats the same structures over and over again. These repeating structures of design and architecture are known as design patterns” (Martin, 2000). Additionally, there are many design patterns that are used in different scenarios. In addition, each pattern is aimed at solving a specific problem (Hauck, 2014). The objective of this paper is to discuss the pattern that can be used for an automatic health monitoring system. Design Patterns In the scenario of an automatic health monitoring system the behavioral pattern is best suited because behavioral patterns are useful for supporting communication between different objects. In software engineering, behavioral design patterns are typical design patterns, which are required for identifying common communication patterns and connecting different objects. In this manner behavioral patterns are helpful in increasing flexibility in carrying out any sort of communication between objects. In fact, this pattern offers much greater flexibility than other patterns because this pattern allows software developers to decouple objects from each other. Due to this coupling and decoupling facilities, they can be easily configured to make dynamic algorithms and methods (Schatten, 2013; Morandi, et al., 2013). In the scenario of an automatic health monitoring system there are different objects, which have various relationships and can demonstrate different results in response to different inputs. The pattern that we will use for an automatic health monitoring system is known as behavioral pattern. The working of this pattern is discussed below: MVC pattern Observer pattern MVC (Model View Controller) Pattern Model View Controller is widely used in behavioral controller. Basically, it has three aspects, which are shown in the figure1 (Burbeck, 2014): Figure 1MVC Pattern Model All the objects are represented with a model that consists of some data. When a change occurs in a state or data, the model notifies the controller. Due to this alert, both controller and view change themselves according to the information provided by the model (Dalling, 2014; Reenskaug, 2003). In the scenario of an automatic health monitoring system whenever a change will occur in user life logging data this model will notify the view or screen for the change of data. For instance, when the distance increases the information presented on the view also changes using control that is notified by model. View MVC uses a view to present the visualization of data that its users can see. In addition, this view presents all kinds of output to its users. It is like an output screen. When there is a change in output information it is controlled by the controller and it is notified by model (Cunningham & Cunningham, Inc., 2013). In the scenario of an automatic health monitoring system whenever there is a change in blood pressure of the user, the system will provide the latest information, which is notified by model or updated by the model using controller, and the user can see it on the screen or the view. Controller A controller is responsible for making and controlling all changes. In this scenario, each recommended change primarily contacts with controller, after that a controller sends commands to the model for its manipulation, and on its manipulation controller notifies the model to update the information for the user to view. Basically, it is a boundary between a view and a model. Additionally, both view and model respond immediately when the controller sends commands (Pastor, 2010). In the scenario of an automatic health monitoring system when a change occurs in user activity level, the controller detects that change immediately as the information is changed, then it sends commands to the model to update the information on user screen in order that a user can see the latest information. Problems An automatic health monitoring system can allow us to view different information, for instance the life logging data of the user, heart rate of the user, blood pressure of the user, and various other information that we can see using this system. In this scenario, the problem is that whether it uses different screens to present each view or there is any other way to change the interface of the monitoring system. Or how we can maintain the data of user life logging, data for their activity, and how we aggregate this data? What types of methods are helpful for changing data? In addition, all these problems are highly coupled and because of this coupling various cohesion problems can arise. Solution In order to address the above stated problems we can use MVC patterns because it has the ability to reduce the cohesion of different states on the same view without affecting other information (Litvin & Litvin, 2014). In addition, the code is also reduced through MVC, code can be reused, and flexibility is also increased (Burbeck, 2014; Dalling, 2014). Consequences MVC has a significant effect on data for instance, when there is a change in data, view quickly asks for updated data, which can cause major inefficiencies. So keep aware users from their results that they want, we have to trade-off between different cohesion and coupling (Burbeck, 2014; Dalling, 2014). UML Class Diagram of an Automatic Health Monitoring System of MVC Pattern Figure 2UML Diagram for an Automatic Health Monitoring System Observer Pattern The Observer is a well-known design pattern in which a list of objects depending on an object (which is also acknowledged as a subject) is maintained. In this scenario, the observer is the object which depends on the subject. Additionally, this subject automatically informs all the objects (observers) regarding any changes made to the state. In order to inform other objects or observers regarding something attractive taking place, a subject distributes an announcement or message to the observers that exist on the list of the subject. This notification can encompass particular information and facts regarding the topic of the notification. However, the subject can eliminate any of the observers from the list when there is no need for a specific observer to be informed regarding these events or changes with respect to the matter they are registered with the subject. In observer pattern there are two types of objects: one is called “subject” and other is called “observer” (Osmani, 2012): Subject: This component is responsible for managing the operation related to observers, such as facilitating, eliminating, or adding observers into the list (Osmani, 2012). Observer: This component is responsible for offering an up to date interface for observers that need to be informed regarding any change (Osmani, 2012). In the scenario of an automatic health monitoring system the observers are sensors because they take information from the user and send it to the system that updates specific information, which is related to this given information. The concept of observer pattern is shown in the figure 3: Figure 3Concept of Observer Pattern The figure 3 demonstrates two observers, which are waiting for notification or action from the subject. Whenever subject changes the state or notifies the observer the observers change them according to the subject or update the data according to the given data from subject, or perform an action according to the subject instruction. There are two other components that are used in observer patterns known as: ConcreteSubjects and ConcreteObservers: Concrete Subject: This component is responsible for managing transmission and notifications to objects regarding changes to state. It also maintains the state of ConcreteObservers (Osmani, 2012). ConcreteObserver: This component is responsible for establishing and maintaining a reference to the ConcreteSubject. In addition, it also implements a modern interface for the observer to make sure that the state is compatible with the subject (Osmani, 2012). Problem In the scenario of an automatic health monitoring system there are many objects that depend on other objects and a small change can have a serious effect on all other objects, how these changes can be controlled with observer pattern? Solution The above problem can be solved by applying loose coupling. Basically, loose coupling provides the facilities that changing the state of one object cannot affect the other objects (Pressman, 2001). UML Class Diagram of an Automatic Health Monitoring System of Observer Pattern Figure 4UML Diagram as an Observer pattern References Aminian, M. & Naji, H. R., 2013. A Hospital Healthcare Monitoring System Using Wireless Sensor Networks. Journal of Health Medical Informatics, 4(2). Burbeck, S., 2014. Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller (MVC). [Online] Available at: http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html [Accessed 13 November 2014]. Cunningham & Cunningham, Inc., 2013. Model View Controller. [Online] Available at: http://c2.com/cgi/wiki?ModelViewController [Accessed 12 November 2014]. Dalling, T., 2014. Model View Controller Explained. [Online] Available at: http://www.tomdalling.com/blog/software-design/model-view-controller-explained/ [Accessed 13 November 2014]. Hauck, T., 2014. Design Patterns. [Online] Available at: http://www.gofpatterns.com/design-patterns/module1/intro-design-patterns.php Litvin, M. & Litvin, G., 2014. The Model-View-Controller Pattern. [Online] Available at: http://apcentral.collegeboard.com/apc/members/courses/teachers_corner/185168.html [Accessed 14 November 2014]. Martin, R. C., 2000. Design Principles and Design Patterns. [Online] Available at: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf [Accessed 14 November 2014]. Morandi, B., West, S., Nanz, S. & Gomaa, H., 2013. Concurrent Object-Oriented Development with Behavioral Design Patterns. [Online] Available at: http://se.inf.ethz.ch/people/west/design-patterns-ecsa-2013.pdf [Accessed 13 November 2014]. Osmani, A., 2012. Learning JavaScript Design Patterns. [Online] Available at: http://addyosmani.com/resources/essentialjsdesignpatterns/book/ [Accessed 14 November 2014]. Pastor, P., 2010. MVC for Noobs. [Online] Available at: http://code.tutsplus.com/tutorials/mvc-for-noobs--net-10488 Pressman, R. S., 2001. Software Engineering: A Practicioners Approach, 5th Edition. London: McGraw Hill. Reenskaug, T., 2003. The Model-View-Controller (MVC) Its Past and Present. [Online] Available at: http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf [Accessed 12 November 2014]. Schatten, A., 2013. Behavioral Design Patterns. [Online] Available at: http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns_behavioral.html [Accessed 12 November 2014]. Teaw, E. et al., 2005. A Wireless Health Monitoring System. Hong Kong and Macau, China, IEEE. Read More