software architecture for developing and deploying applications for ...

SOFTWARE ARCHITECTURE FOR DEVELOPING AND DEPLOYING APPLICATIONS FOR SMART HOMES A THESIS SUBMITTED TO AUCKLAND U NIVERSITY OF T ECHNOLOGY IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF

M ASTER OF C OMPUTER AND I NFORMATION S CIENCES

Supervisor Dr. Roopak Sinha

September 2017

By Anmoldeep Singh School of Engineering, Computer and Mathematical Sciences

Abstract Programming applications for smart homes brings their own set of problems like the absence of robust programming constructs and design patterns that also address issues like interoperability, dynamicity and reconfigurability. The literature confirms that there are gaps whereby none of the existing solutions are able to deliver a robust model primarily aimed at solving the stated problems. This research presents a software framework architecture built using robust language constructs and design patterns that supports interoperability, dynamicity and reconfiguration . The architecture can be used as first steps in development of a software framework for development of applications for smart homes. A Design Science research methodology was adopted to conduct this research under which Requirement Modeling and SAAM was used for requirement elicitation and quality attribute selection. Our approach uses F UML framework development methodology to build the framework which was later evaluated using scenario based evaluation.

2

Contents Abstract

2

Attestation of Authorship

8

Acknowledgements

9

1

2

Introduction 1.1 Background . . . . . . . . 1.2 Major Objective . . . . . 1.3 Research Direction . . . . 1.4 Research Scope . . . . . . 1.5 Research Significance . . 1.6 Research Overview . . . . 1.7 Research Project Outline

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

10 . . . . . 10 . . . . . . 11 . . . . . . 11 . . . . . 12 . . . . . 12 . . . . . 13 . . . . . 13

Literature Review 15 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 2.1.1 Smart Homes – A generic system architecture . . . . . . . . . 15 2.1.2 Language Constructs and Design Patterns . . . . . . . . . . . . 16 2.1.3 Interoperability in smart home sensors/actuators configuration and why does it matter? . . . . . . . . . . . . . . . . . . . . . . 17 2.1.4 Reconfigurability and adaptability in smart home environments and why does it matter ? . . . . . . . . . . . . . . . . . . . . . . 17 2.2 Process of Systematic Literature Review . . . . . . . . . . . . . . . . . 18 2.2.1 Planning and Scoping . . . . . . . . . . . . . . . . . . . . . . . 18 2.2.2 Search Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.3 Search Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.2.4 Search Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2.5 Inclusion and exclusion criteria . . . . . . . . . . . . . . . . . . . 21 2.3 Conducting the literature review . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.1 Search and selection . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.2 Data extraction and composition . . . . . . . . . . . . . . . . . 22 2.4 Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3

2.5

2.4.2 Research based solutions . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

Research Methodology 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Choosing the right research methodology . . . . . . . . . . . 3.3 Selected Research Methodologies . . . . . . . . . . . . . . . 3.3.1 Design science: The process . . . . . . . . . . . . . . 3.3.2 Systematic Literature Review . . . . . . . . . . . . . 3.3.3 Requirements Modeling Methodology . . . . . . . . 3.3.4 Software Architecture Analysis Method (SAAM): Based evaluation . . . . . . . . . . . . . . . . . . . . 3.3.5 Framework Development Methodology . . . . . . . 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

System Requirements 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Elicitation of Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Meta and domain level . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Goal identification from meta and domain level requirements . 4.2.3 Obtaining new goals and refining them by asking HOW questions 4.2.4 Terminal requirements for the framework . . . . . . . . . . . . 4.3 Quality Attributes & Evaluation . . . . . . . . . . . . . . . . . . . . . . 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

System Design & Development 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Interoperability, Dynamicity and Reconfiguration . . . . . 5.1.2 Application Frameworks for developing applications . . . 5.1.3 Design Patterns and Object Oriented Programming (OOP) 5.2 The framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Identification of main components . . . . . . . . . . . . . . 5.2.2 Use Case Generation . . . . . . . . . . . . . . . . . . . . . . 5.2.3 Class Diagram Generation . . . . . . . . . . . . . . . . . . . 5.2.4 Sequence Diagram Generation . . . . . . . . . . . . . . . . 5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

Analysis 6.1 Introduction . . . . . . . . . . . . . . . 6.2 SAAM based evaluation . . . . . . . . 6.2.1 Perform scenario evaluations 6.2.2 Reveal scenario interactions . 6.3 Overall evaluation . . . . . . . . . . .

4

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

23 30

34 . . . . . . 34 . . . . . . 34 . . . . . . 38 . . . . . . 39 . . . . . . . 41 . . . . . . 42 Scenario . . . . . . 42 . . . . . . 43 . . . . . . 43

. . . . .

. . . . .

. . . . .

. . . . .

44 44 45 45 45 46 47 48 51

53 . . 53 . . 53 . . 54 . . 56 . . 57 . . 58 . . 60 . . . 61 . . 66 . . 67

. . . . .

. . . . .

68 68 68 68 70 70

7

Conclusion and Further Research 7.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

References

72 72 73 73 75

5

List of Tables 2.1 2.2 2.3 2.4

Systematic Literature Review Search Sources Summary of the process of SLR . . . . . . . . Description of attributes . . . . . . . . . . . . . Summary of the Findings . . . . . . . . . . . .

4.1

Stakeholer Analysis Table . . . . . . . . . . . . . . . . . . . . . . . . . .

5.1 5.2

Unification rules for use case diagram . . . . . . . . . . . . . . . . . . . . 61 Unification rules for class UML diagram . . . . . . . . . . . . . . . . . 63

6.1

Scenario evaluations for the proposed framework . . . . . . . . . . . .

6

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . .

19 22 23 31 50

69

List of Figures 2.1

Overview of smart home . . . . . . . . . . . . . . . . . . . . . . . . . .

16

3.1

Overview of research design . . . . . . . . . . . . . . . . . . . . . . . .

43

4.1 4.2

Meta and domain level requirements . . . . . . . . . . . . . . . . . . . . Resultant soft goals for requirement modelling . . . . . . . . . . . . . .

46 47

5.1 5.2 5.3 5.4

Overall architecture of the framework . . . . . Use case diagram of the proposed framework The framework class diagram . . . . . . . . . . Sequence diagram of add new configuration .

58 62 64 66

7

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Attestation of Authorship I hereby declare that this submission is my own work and that, to the best of my knowledge and belief, it contains no material previously published or written by another person nor material which to a substantial extent has been accepted for the qualification of any other degree or diploma of a university or other institution of higher learning.

Signature of student

8

Acknowledgements I would like to express deep gratitude and respect for my research project supervisor, Dr. Roopak Sinha, for sharing his immense knowledge and continued support throughout the semester. I would like to thank my mother Nishi Verma, who despite all the up and downs in our life, supported me through out the course. I would also like to thank my friend Christopher Okhravi from Sweden who is an excellent teacher and makes very hard concepts a breeze to learn. I could not leave Barry Dowdeswell, Michaela and Nipuni Perera, who have been very supportive in helping me with tools without which this work would have been incomplete. Anmoldeep Singh, 24 October, 2017

9

Chapter 1 Introduction 1.1

Background

In recent years, the world has seen immense technological innovation in products used in living environments that are aimed at increasing the daily quality of life of people. Modern homes consist of many such smart products which are networked and can communicate with each other. Creative applications of these devices can lead to building services around them, which makes any ordinary home a "smart home". However, the implementation of such devices, which are made up of different kinds of actuators and sensors, needs logic and programming in order to glue them together. Programming these applications brings their own set of problems like the absence of robust programming constructs and design patterns that also address issues like interoperability and reconfigurability due to the dynamic and heterogeneous nature of the sensors in smart home environment. Standardization of the application code, which addresses the mentioned problems to ease the development of such applications, is crucial. Drafting a set of rules and applying them manually during development is not feasible in todays time. Even though there are existing solutions that are aimed at addressing interoperability and dynamicity using language constructs and compositions, 10

Chapter 1. Introduction

11

several gaps were identified whereby none of the frameworks delivered a robust model primarily aimed at solving the stated problems. This is detailed in Chapter 2. Hence, a framework architecture was developed that can be used to develop complex applications for smart homes, this would mean that the developer would not have to worry about the code composition and can rather focus more on the business logic aimed at building services.

1.2

Major Objective

The major objective of this research project was the design and development of a software framework architecture that would support interoperability, dynamicity and reconfiguration of the different sensors and actuators in a smart-home environment while making it efficient through the application of robust language constructs and design patterns.

1.3

Research Direction

This research aimed to answering the following two research questions: 1. Which programming language constructs and design patterns are most useful in designing software that can automatically deal with dynamicity, lack of interoperability and reconfiguration in sensor-actuator configurations of smart-homes? 2. How can we develop a programmer-friendly interface based on Research Question 1 so that the class of software identified in RQ1 can be more efficiently designed and deployed?


1.4

12

Research Scope

The aim of this study was to first identify the language constructs and design patterns that are most useful in building software that can automatically deal with dynamicity and the lack of interoperability in sensor-actuator configurations of smart-homes. This information led the researcher to identify potential gaps in the system and directed the researcher towards efficient requirement modeling. Subsequently, based on the requirements, a solution was developed in the form of a framework architecture, which can easily be implemented using an object oriented programming language.

1.5

Research Significance

1. The solution addresses interoperability, reconfiguration and dynamicity at the application level. 2. The solution generates applications that employ best practices and code compositions using design patterns. 3. The solution is easily implementable into an interface that is developer friendly whilst making it easier for them to develop complex applications whereby they concentrate on the business logic rather than the code. 4. The solution enhances re-usability by definition of abstract components that can be used to create new and highly complex applications. 5. The solution is extensible for customizations without making major changes in the core classes. 6. The solution reduces the number of code lines to enhance performance and effectiveness.


1.6

13

Research Overview

This research was conducted as follows. The researcher conducts a systematic literature review, which helps the researcher identify gaps in the current research and motivates the researcher to develop a solution to fill those gaps. Several methodologies were used in the study under the umbrella methodology of Design Science, as detailed in Chapter 3, which were carefully selected by taking several factors into consideration. The requirement modeling helped the researcher with the formation of terminal requirements, which also clarified how and what tools would be needed to develop a reliable solution. Additionally, the quality attributes were also defined using scenarios, which aided the researcher in the evaluation that is detailed in Chapter 6. The design and development of the solution framework involved a number of iterations as part of the F-UML methodology that was used to develop it, this made the solution easy to interpret and implement in future. Lastly, the conclusion in Chapter 7 highlights the future research, limitations and final words of the researcher.

1.7

Research Project Outline

The contents of this research are broadly divided into 3 parts. Part One consists of two chapters. Chapter 1 describes the motivation, objectives, research questions and its significance. Chapter 2 consists of a systematic literature review performed for the identification of existing gaps and analyzing existing research in relation to smart home frameworks. Part 2 consists of Chapter 3 which describe the main methodologies involved in the development of the solution, Chapter 4 which is dedicated to requirement modeling and quality attribute selection, and Chapter 5 which describes the whole process of framework design and development in detail.


14

Part 3 consists of Chapter 6 which consists of the analysis and evaluation of the solution and Chapter 7 which concludes the research by listing the limitations, future work and conclusion.

Chapter 2 Literature Review This section of the research project consists of a comprehensive systematic literature review (SLR) starting with background information of the domain, relevant terminology used in this research and the detailed workflow and execution of SLR. Section 2.1 outlines the background to better understand the smart home ecosystem and associated relevant terms followed by Section 2.2 and 2.3, which describes the process of the Systematic literature review in detail. Subsequently, Section 2.4 contains the findings.

2.1

Introduction

This section of the report describes a conventional architecture of a smart home which would help obtain an essence of the research domain and terminology that was used in this report.

2.1.1

Smart Homes – A generic system architecture

Figure 2.1 on the following page is a smart home setting comprised of a kitchen, toilet and rooms equipped with different types of sensing equipment. All the sensors are 15

Chapter 2. Literature Review

16

Figure 2.1: Overview of smart home interconnected and they perform various tasks in conjunction with actuators to form smart objects that deliver some value to the user or the home. The data collected by the sensors is sent to a central processing unit that performs various functions (Suryadevara & Mukhopadhyay, 2015). A simple example of such a setting would be the temperature sensor working with the humidity sensor as a climate control system. In addition to the implanted sensors, wearable sensors can be used in a smart home environment as smart objects. The smart objects can be used to perform various functions, such as monitoring a patient living alone at home. The sensors can be used to employ an emergency system that is triggered on a pre-defined logic involving wearable sensors.

2.1.2

Language Constructs and Design Patterns

The term “language constructs” used in this research refers to the control structures or rules related to the selected language that can be efficiently used to design a solution


17

that deals with interoperability, dynamicity and reconfiguration of the smart objects configuration software in the smart homes. A “Design Pattern” is a mechanism for expressing software design structures. (Gamma, Helm, Johnson & Vlissides, 1993). Design patterns preserve the information that can be reused by registering the underlying idea behind the design (Gamma et al., 1993). Hence, they can be used to build reusable software/framework and can be applied to “n” number of situations and configurations. The patterns act as micro-architectures that can then be used to build complex smart home designs and systems.

2.1.3

Interoperability in smart home sensors/actuators configuration and why does it matter?

Interoperability in smart home sensors/actuators configuration is aimed at the development of the ability to define a sensor fusion in which the corresponding sensors act in a collaborative and independent manner to produce more value than individual observations could (Ballari, Wachowicz & Callejo, 2009). The design pattern should be able to support all types of sensors/actuator configurations. This is discussed in detail in chapter 5.

2.1.4

Reconfigurability and adaptability in smart home environments and why does it matter ?

Reconfigurability in smart homes is very important especially when it is applied to assisted living and mission-critical systems. In the event of a failure of a sensor or a smart object, the system should be able to adapt to the event and offer alternate options to enter the sensor data manually. Hence, it has to be taken into consideration while building a framework at the application level.


2.2

18

Process of Systematic Literature Review

This section of the report describes the literature review in detail. The systematic literature review was conducted as per the widely used collective guidelines provided by Siddaway (2014) and Kitchenham (2007).

2.2.1

Planning and Scoping

The SLR was planned by stating a problem definition and formulating research questions relevant to them. A search strategy was formulated by identifying potential search terms followed by a description of an inclusion/exclusion criteria which are presented below in detail:

Review Objectives and research questions Problem Definition: The sheer number of the sensors and actuators and their heterogeneity in a smart environment bring a unique set of challenges. This research is aimed at solving one such problem, i.e., an absence of robust programming constructs and design patterns allowing such software to be more easily written and deployed. Hence, the above-mentioned problem definition leads to the formulation of the following research questions: Question 1: Which programming language constructs and design patterns are most useful in designing software that can automatically deal with dynamicity, lack of interoperability and reconfiguration in sensor-actuator configurations of smart-homes? Question 2: How can we develop a programmer-friendly interface based on Research Question 1 so that the class of software identified in RQ1 can be more efficiently designed and deployed?


2.2.2

19

Search Strategy

After defining the problem and corresponding research questions, a formal search strategy was formulated which is aimed at making the SLR robust and exhaustive. After the problem definition and the research questions were defined, the search strategy was used to analyze all available research that is relevant to the research questions of this report. A search space was defined which included the electronic databases that are used to carry out the SLR. The research papers initially retrieved from the electronic databases were then used to identify more relevant documents by snowballing (searching through their corresponding referenced documents). In addition to that, related published or unpublished work of the authors of the shortlisted documents was also consulted to make the process more robust. Subsequently, the inclusion and exclusion criteria were applied to the retrieved research papers to filter out the most relevant studies.

2.2.3

Search Sources

The plan of initial search space used to conduct SLR is shown in Table 2.1: Table 2.1: Systematic Literature Review Search Sources Databases Used Types of Research Searched Search applied on Languages Period of Publications

Springer Link, IEEE Xplore, ScienceDirect all Full-Text, Titles, Abstracts English any

The three widely used Electronic databases were used to carry out SLR for this research. All kinds of research including, but not limited to Journals, Conference Papers, Workshops and Books were taken into consideration. In addition to the titles and abstracts, the search was also applied to Full-Text of the papers that would help


20

uncover any documents that did not appear using the selected search keywords in the titles and abstracts. It is to be noted that a constraint to this study is that the author is only proficient in the English language, hence, consideration was limited to papers written in English language only. All studies published at any point in time were taken into account.

2.2.4

Search Criteria

The search criteria that was formulated for this review is derived entirely from subdivision of the research questions into meaningful search terms and sub-questions. The Research question: Which programming language constructs and design patterns are most useful in designing software that can automatically deal with dynamicity, lack of interoperability and reconfiguration in sensor-actuator configurations of smarthomes? The above-mentioned Research question was used to formulate the following search terms: • Smart Homes, Internet of things, Sensors • Design Patterns, Language Constructs, Interoperability, Reconfiguration, Adaptability, Challenges, Programming Design, Dynamic, Programming, ObjectOriented. The generated search terms were then used to try a number of OR and AND combinations for forming a search query using the keywords: smart homes OR Internet of Things, interoperability, programming, software, object-oriented. The search strings were formulated based on the searching capabilities and functionality of the individual electronic databases. Each search in the database was conducted as an exploratory exercise. With continuous experimentation and agility, each subsequent search was pro-actively improved to get the best possible results.


2.2.5

21

Inclusion and exclusion criteria

Inclusion and exclusion criteria are crucial in determining whether a research paper should be included or not. Hence, the following rules were used: Inclusion Criteria: 1. The study is relevant to the search criteria defined in Section 2.2.4. 2. The study is related to the problem domain mentioned previously 3. The study is in English Exclusion Criteria: 1. Studies that are based on a viewpoint, opinion, discussions, tutorials, prefaces, editorials, workshops and presentations without references. 2. Studies that do not discuss functional terms such as interoperability, programming, smart home, sensors, design patterns. 3. Studies that do not present the substantive, object-oriented implementation which addresses RQ1 as mentioned previously. 4. Studies that do not meet the inclusion criteria.

2.3

Conducting the literature review

In this section, the findings of the SLR and extracted information relevant to design patterns in smart home environments is presented.

2.3.1

Search and selection

As mentioned previously, the electronic databases were used to find and retrieve research papers based on RQ1.


22

As shown in Table 2.2, we retrieved a total of 161 studies initially. In the first round of application of the inclusion-exclusion criteria, an in-depth and extensive inspection was carried out using the titles, abstracts and general methodologies used in the research. Duplicate studies were excluded. Most of the studies were rejected due to Exclusion Criteria 2 and Exclusion Criteria 3. After the first round, the researcher was left with eleven studies. Table 2.2: Summary of the process of SLR Database IEE Science Direct Springer Total

Initial 92 40 29 161

Round 1 9 1 1 11

Round 2 6 1 1 8

The selected 11 studies were further assessed in-depth by going through the full text and understanding the research in detail. Afterwards, three more studies were removed because they did not comply with Exclusion Criteria 3 or the design pattern was absent. Therefore, the final list of selected studies consisted of nine research papers.

2.3.2

Data extraction and composition

A data extraction process was defined to identify and extract important relevant information from the studies that were most relevant to our research questions. A table was set up to record information related to the attributes as shown in Table 2.3

2.4

Findings

This section of the report aims at answering the previously formulated RQ1 considering the observations made from the literature review.


23

Table 2.3: Description of attributes Attribute name Interoperability Design Pattern Programming Language Dynamicity Re-Configuration

2.4.1

Description How does the study solve the problem of interoperability? What design pattern is used in the study? Which programming language/framework has been used to implement the design pattern? How does the proposed design pattern address the problem of dynamicity? Does the proposed design pattern have provision for configurability?

Overview

As previously stated, eight studies were shortlisted. Very few studies were found that explicitly talked about design patterns at programming level. Hence, the studies that contained implementable architectures and could be related to design patterns while addressing the problems of interoperability, dynamicity and reconfiguration in the smart home environment were also shortlisted.

2.4.2

Research based solutions

This section of the report comprises of the studies that have been carried out to address the primary issue of interoperability, dynamicity and reconfiguration using design patterns.

A Connected Home Platform and Development Framework for smart home control applications – Connected Home Platform (CHP) CHP is a framework and a service platform that uses OSGi technology designed to build applications for smart homes. It uses a ROCob layer which is an API layer with the primary function of providing an interoperable interface. It consists of JAVA classes and interfaces which are bound with OSGi services providing transparency to all the devices


24

and sensors in the smart home environment. The OSGi layer adds to the flexibility and dynamicity for new technologies at runtime (Krishna & Verma, 2016). The ROCob layer has three main components namely the Device Interface, Interface Functions and Interface Scene. The Device Interface must be implemented by each device registered on the network which executes three main registry functions to register its Unique ID, function (capabilities) and type (sensor or actuator). The OSGi EventAdmin specification driver is used to notify other services of property updates. The Interface Function is a helper interface (not implementable) which contains a number of developer-friendly fields of available ROCob function interfaces. Interface Scene: This interface is used to create a scenario which has a set of device participants. Each scene has a unique ID and properties which rely on the ROCob device function interfaces. For example, a scene is defined that when a motion sensor is triggered in a room, a ROCob function interface (Lights) is referenced by its ID and executed to do a specific function (ON or OFF). The design pattern that can be most closely related to CHP is the observer pattern (Gamma, 1995) because of the presence of Observer (OSGi) and multiple subjects (ROCob function interfaces). CHP claims to solve only one problem, i.e., interoperability using OSGi as a base library. No implementation in terms of a working prototype was mentioned where the actual design pattern could have been observed. The problems of dynamicity and reconfigurability are specified but not implemented or included in the said pattern.

An Extensible Ubiquitous Architecture for Networked Devices in Smart Living Environments The architecture proposed by Bodhuin, Canfora, Preziosi and Tortorella (2005) aims at addressing the interoperability in smart home environments where the smart devices


25

come from different manufacturers. It also adds a middleware that supports adaptability and reactivity at runtime. The architecture is divided into six primary layers from A to F. Layers D, E, F: Layers F is the bottom layer which contains all the smart devices. Layer E sits on top of E which includes the different ports and cards that facilitate the function on devices on layer F. Layer D is responsible for making the implemented software portable and has a Java Virtual Machine (JVM) which runs on an Operating system. Layers A, B, C: Layers A, B and C comprise of the primary software architecture which is subdivided into three parts: a framework based on Java’s OSGi (Alliance, 2015) which aims at code reduction while implementation and also facilitates extensibility, an Oriented Service Application (SOA) container which simplifies the interactive activities and an intelligence component which decreases the repetitive actions and adapts to the inhabitants. The author states that the heterogeneous devices in the smart home environment can be generalized independently from their kind, complexity and function. This level of abstraction is essential in creating a genuinely interoperable solution. An interface hierarchy as per Alliance (2015) is a simplified view of the actual implementation of the framework. According to the standard notation of a UML Class Diagram the interfaces multi devices, Actuator and Sensor implement the main Device Interface which has further concrete subclass implementations. The primary interface has one-to-many associations with the observer interfaces (multi devices, Actuator and Sensor), a design pattern which can be loosely related to the observer pattern. A general structure of the model where the Device would be a subject/observable with functions addDevice() and removeDevices() as Attach() and Detach() in the observer pattern. The Observers (multi devices, Actuators and Sensor) interfaces implement the principal observer and have multiple concrete classes. The implementation only addresses interoperability and does not account for other important issues such as adaptability and reconfigurability. Furthermore, the framework


26

is theoretical, incomplete and does not have any evidence of actual code that would reinforce the Object Oriented conceptualizations. A rule-based framework for heterogeneous subsystems management in smart home environment A rule mechanism in the form of Event-Condition-Action (ECA) is proposed by Leong, Ramli and Perumal (2009) to address the issue of interoperability in a smart home environment. During an operation, an event is created due to a task that must be completed which is initiated by the inhabitant of the home. The ECA framework is embedded in the database as data in the form of multiple relational tables. The implementation of the framework does not have any visible design pattern associated with it at the application level. This framework, even if implemented as a pattern would not be useful as it has concrete data as core classes. Dynamicity and adaptability are not supported by this framework. A Task-Oriented Framework for Networked Wearable Computing – SPINE2 A platform agnostic but domain-specific framework called Signal Processing Node Environment (SPINE2) that enables code reusability, portability and interoperability is proposed by Galzarano, Giannantonio, Liotta and Fortino (2016). The framework is meant to work with Wireless Sensor Networks (WSNs) and helps to develop applications in such systems. A task-oriented approach is used to model the applications for different sensors by abstraction of the low-level communication protocols using high-level programming. The author presents a table with the various methods of application development for Wireless Sensor Networks namely platform specific programming, general purpose framework, domain-specific framework and automatic code generation. Furthermore, he argues that domain specific framework is most suitable for this framework as it covers


27

most of the features such as interoperability, reconfiguration efficiency etc. However, the researcher presents no evidence or facts backed by a strong argument or rational reference to support these claims. The Coordination-Side Architecture of the paper describes the class diagram of the framework which is used by the developers to develop and deploy task-oriented applications. The architecture does not use any UML notations by which the class implementations and associations between the classes can be identified. However, it is worth noting that a potential “adapter pattern” can be identified in the communication package where the CommAdapter class acts as an adapter between the platforms and the lower level platform dependent class definitions (TinyOS and zStack). The Adapter design pattern is used to make two incompatible interfaces compatible. Other than that, no design pattern at the programming level can be identified that supports abstraction while addressing interoperability, dynamicity, adaptability or reconfigurability.

Interactive Home Supervision Application Think Visually The framework proposed in (Kantorovitch & Niskanen, 2010) is called the vantage point that facilitates the development of applications for smart home environments. The author claims that the framework supports interoperability using OSGi framework and provides support for developers and end users. The framework takes a visual intensive development approach where the application development feedback is done using graphics and home visualization in 3D. The Model View Controller (MVC) architectural approach is used to implement the framework to ensure loose coupling of the objects. Virtual sensors simulation tools such as SimuContext (Broens & Van Halteren, 2006) and Carerider bed by audioriders.fi are used to implement the framework. The tools generate events and abstract context data using virtual sensors. After analysis of the class diagram as illustrated in Kantorovitch and Niskanen (Kantorovitch & Niskanen, 2010), it is concluded that the chart does not follow any design pattern. It can be


28

observed that the direct inheritance of the subclasses from the class sensor is not considered a good practice in the composition of design patterns. For example, in cases of multiple subclasses of the sensor, which might have common properties, the properties become repetitive. Hence, a better solution, for instance strategy pattern, (Gamma, 1995), would solve the problem. The framework also fails to address adaptability and reconfigurability.

An Ontology-Driven Software Framework for the Healthcare Applications Based on ANT+ Protocol An application development framework is proposed by Mehmood, Culmone and Mostarda (2014) that classifies the smart home sensors/actuator configurations based on their function and allows the developer ignore to the technical aspects at a lower level using abstraction. The framework has three main features that allow it to provide different functional views for the same object and add new devices to the framework. The former is achieved by defining classifications for various sensors that are pre-coded into the framework by one of the three actors, i.e., Ontology Editor, the Framework Editor and Programmer. The Ontology Editor defines the general abstraction high-level classes and the implemented classifications. The author claims that Java Interfaces and Classes are used in the implementation, but there is no evidence or a UML where the design pattern can be studied. Furthermore, the author claims that the framework supports reconfigurability by monitoring the persistence of the data produced by the sensors, however, the implementation for the same is absent. The framework offers an approach whereby the programmer is bonded to OOP and not an OOP based interface, which in the researcher’s opinion is not scalable or efficient.


29

Open Home Networks: The TEAHA Approach The framework proposed by van Dijk, Scholten, Tobalina and Milanini (2007) attempts to address interoperability among heterogeneous devices in a smart home environment, which is used to deploy controlled interactions in applications, whereby, a semantic abstraction is needed. The framework also tries to address adaptability and dynamicity by the employment of a near-zero reconfigurability feature. The programming model is an event-based programming model. Five design patterns namely Proxy, Factory, Composite, Custodian and Driver Extension are used in the implementation of the framework. However, none of the patterns are directed towards interoperability or reconfiguration. The base platform has three functions that allow the devices to be dynamically loaded, unloaded and configuration of services. The author promotes the OSGi platform because of its features and flexibility, and the framework heavily depends on it. The design patterns application in this framework provide insight into the elements to take into consideration when answering RQ2.

Web of Topics: An IoT-aware model-driven designing approach An application framework based on the conceptual model of Web of Things (WoX) is proposed by Mainetti, Manco, Patrono, Sergi and Vergallo (2015), whereby the “things” are identified by two concepts namely: 1. A semantic feature of interest (sensing capability in sensors or output in actuators) 2. A URI based location, which can be any kind of a unique identifier. The framework is closely related to the publish/subscribe design pattern which itself has its roots in observer design pattern. Different types of subscribers such as Sensor Capability, Actuator Capability, Function Capability, Sensor Need, Actuator Need and Function Need implement the WoxSubscriber interface. Every time a device is discovered, it registers its capabilities (actuator, sensor distinction, etc.) and the corresponding subscriber classes are instantiated as objects.


30

On each update of the observable, all the subscribed devices are notified of the change. This framework can be used to model complex applications. According to the survey by the author, Wox helps increase the efficiency of the developers. The frameworks address interoperability and dynamicity, however, the framework doesn’t address other challenges such as reconfigurability or adaptability.

2.5

Conclusion

There have been several approaches that have been developed to solve the problem of interoperability at the service level, however, very little research and development has been carried in addressing this issue at the application level. Development of an easily implementable framework which would aid developers to develop software for smart homes that is also dynamic and adaptable at the same time is needed. Eight studies were identified that could hold some potential to answer our questions. The results of the study can be summarized in Table 2.4 below:

1

1

Meliones,

Language Eco- Java OSGi

Java OSGi Java, ANT+ Ontology-based Java OSGi

Java

(Kantorovitch & Niskanen, 2010)

(Mehmood et al., 2014)

(van Dijk et al., 2007)

(Mainetti et al., 2015)

yes

yes

Pattern identified and not mentioned explicitly are indicated with a † symbol.

server pattern)

Publish /Subscribe (based on ob- yes

todian and Driver Extension

Proxy, Factory, Composite, Cus- yes

MVC (High Level)

patibility) †

no

yes

yes

no

no

Adapter (used to for increased com- yes

Java

(Galzarano et al., 2016)

no

yes

no

yes

yes

no

yes

yes

no

no

no

no

yes

Interoperability DynamicityReConf

yes

XML

(Leong et al., 2009)

ECA (Event Condition Action)

Java OSGi

Observer †

Observer †

Pattern

(Bodhuin et al., 2005)

nomou, Karras & Liverezas, 2009)

(Papadopoulos,

Study

Table 2.4: Summary of the Findings

Chapter 2. Literature Review 31


32

Which programming language constructs and design patterns are most useful in designing software that can automatically deal with dynamicity, lack of interoperability and reconfiguration in sensor-actuator configurations of smart-homes? It can also be observed that seven out of eight studies use Java as the programming language for the implementation of the framework. four out of eight studies use Java’s OSGi framework for implementation as it is claimed to provide excellent support for building modular applications. Different forms of design patterns were derived from the studies, however, the observer pattern was used thrice in the papers and hence, is considered useful in designing applications for smart homes. The observer pattern is based on the fact whereby, one subject transmits its state to other observers who are subscribed to it when it updates rather than iteratively updating the peers. Hence, it perfectly fits into the smart home application domain. The author in van Dijk et al. (2007) uses a combination of Proxy, Factory, Composite, Custodian and Driver Extension patterns to address various aspects of functionalities in the framework. The patterns are mainly aimed at improving security, and dynamic object creation through abstract classes. However, they are not used to address high-level architectural problems like interoperability which this study is primarily aimed at.The Adapter Pattern is used in Galzarano et al. (2016), for platform independence so that the applications designed for the smart homes are able to run on multiple operating systems. The Adapter Pattern introduces a common adaptable interface that the incompatible interface can plug into to talk to the other interface. It can be useful in the solution, however, there is no evidence of the semantics of the classes and composition in the given study. As mentioned previously, the class compositions and patterns used in the research papers such as Leong et al. (2009) and Mehmood et al. (2014) are not efficient and unsuitable for answering RQ2. Additionally, none of the studies address the problem of reconfiguration as seen in Table 2.4. In conclusion, no design pattern alone can be used to address all the problems. Hence, the patterns and


33

language constructs utilized in the studies that are listed in the table do not adequately describe the whole system, Therefore, a new architecture, which employs a combination of patterns is needed for a complete solution that can be used to build a framework to be used by developers to develop applications for smart homes.

Chapter 3 Research Methodology 3.1

Introduction

This chapter aims at planning the research methodology and associated tools that would be utilized to solve the research questions formulated in the previous section. Additionally, the rationale to support the chosen method is also included whilst contrasting it with other potential candidates for this research. A Systematic Literature Review (SLR), as used in the previous chapter, is also discussed in this chapter.

3.2

Choosing the right research methodology

This study seeks to identify language constructs and design patterns that are most suitable for building a framework that would aid software developers design applications for smart home environments whilst addressing the problems of interoperability, dynamicity and adaptability. Selection of the right research mythology is instrumental in planning and conducting the research to achieve effective and well founded results. Choosing methods and methodologies for a research project is often considered a difficult task. As stated by Håkansson (2013), the first decision when selecting a relevant research method

34

Chapter 3. Research Methodology

35

is, whether the research concerns proving a phenomenon by experimentation with data (quantity) or, it is more relevant to studying a phenomenon or a piece of technology to create products and inventions by exploring the terrain (quality). A framework proposed by Håkansson (2013) that aids a researcher in the selection of the most suitable research method was used in this study. The following factors elaborate the various factors that a researcher must investigate before selecting a research methodology: • Philosophical Assumptions: Several assumptions such as Positivism, Realism, Interpretivism and Criticalism (Myers, 2013) exist that need to be taken into consideration. As quoted by Myers (2013): “Interpretivism assumes that the reality is accessed only via social constructions. They attempt to understand phenomena by exploring richness, depth and complexity, often in an inductive manner, to discover the meanings people assign to the phenomenon. The view of interpretivists is used in projects with opinions, perspectives, and experiences characters to get context for phenomena. Works well in developing computer systems and artefacts.” Of all the assumptions, Interpretivism aligned perfectly with the goal and the research questions formulated in this study as this study builds on the deductions, solutions and gaps identified in existing literature related to smart homes, interoperability, adaptability and reconfiguration. Hence, the RQs in this study are based on the same assumption. Therefore, it was taken into consideration when selecting the methodologies. • Research Methods: The formal procedures or set of rules that facilitate initiation, carrying out and completing the research tasks are Research methods. Some of the most common research methods comprise of Experimental, Non-Experimental, Applied, Conceptual and Empirical.


36

Applied Research deals with answering specific research questions and problems in practice and builds on existing research. This research is often based on a particular application, which in our case is smart homes. In this study, conceptual research methods were used by conducting a systematic literature review in Section 2 in order to interpret existing concepts through critical analysis. • Research Approaches: Concluding the findings and development is an essential step in conducting research. Two main approaches, namely inductive and deductive approaches (Trochim & Donnelly, 2001), can be used to derive conclusions. The Inductive method is most suitable for our research as it mostly deals with the development of an artefact based on the critical analysis of findings based on existing research. Hence, inductive approaches were taken into consideration. • Research Design: The following research strategies as suggested by Håkansson (2013) were thoroughly and independently examined: Experimental research is mainly used to study the "cause and effect" behaviors of the systems. In involves defining variables and keeping one of them constant to examine the others. This method does not align with our current research goal. Surveys or Case studies are used to evaluate and investigate the characteristics of systems in many disciplines. The variables in surveys are analyzed against their occurrence and their relationships with other variables. Inferences are made about functions that cannot be observed directly. Conducting surveys and case studies in this research would not be useful because of the little research that has been done on this subject and there is an absence of adequate materials. Action research is a systematic method wherein planning, action, observation, evaluation and critical reflection are iterated in several cycles. It can be both used as quantitative and qualitative method by applying it to various situations (Avison,


37

Lau, Myers & Nielsen, 1999; Runeson & Höst, 2009). The evaluation criteria of action research are not that well established, and, although there are frameworks that help with evaluation done specific to this particular method, they are vague or subjective (Easterbrook, Singer, Storey & Damian, 2008). Exploratory research, as the name suggests, deals with exploring the prospect of obtaining as much information about the problem domain and establish relationships between the variables. Surveys are a popular source of information in exploratory research (Håkansson, 2013). Grounded theory aims at the development of a theory that derives from reliable data. To achieve this, a formal method is employed, where data is collected and analysed critically. Subsequently, the insights generated from the data helps form a theory or a concept. The data is gathered through formal inductive methods and can be qualitative. Ethnography is a form of research method that employs field observations from a social point of view (Easterbrook et al., 2008). A community of scientists or experts in the particular area builds a culture of practices for collaboration. The clear constructivist stance that ethnography takes deems it unsuitable for the problem domain this paper is trying to solve. Design science is another popular framework that has been widely used in software engineering and computer science for the development of new artefacts. Primarily, there are three main stages, where a theory is built in the first phase which involves the evaluation of existing frameworks. Step 2 requires experimentation, followed by case studies, evaluation or surveys. Step 3 reinforces the assessment of artefacts. This particular strategy is most suitable and fits well into the research goal because of its robustness and evidence of successful use by other researchers in the field of information systems for building and delivering


38

artefacts. • Data Collection: Once the research strategy has been chosen, relevant data collection methods are applied for the study’s unit of analysis. Data collection can vary with the selected plan. For instance, a lot of insights are generated from the SLR conducted in Section 2 that helped the researcher by pointing him in the right direction for design and development. • Quality assurance and evaluation of the research material is crucial for a quality research project. Qualitative research carried out with an inductive approach needs to establish its dependability, confirmability and transferability (Håkansson, 2013). Most design strategies have evaluation criteria that help fulfill the stated quality attributes. The selected design plan’s evaluation criteria was adapted as per this research goal and constraints, which are also discussed in the following section.

3.3

Selected Research Methodologies

As mentioned previously, this study aims at designing a commonly accepted framework that would serve as an initial step of building a tool for developing and deploying applications in smart home environments that support interoperability, dynamicity and reconfigurability. Design Science Research Methodology (DSRM) is a research methodology that aims at building unequivocal solutions to problems using design. Design is a well-accepted research pattern in many other disciplines because of its solutions based on incremental problem-solving. DSRM has been successfully applied in disciplines such as computer science through information systems to produce robust artefacts that are pertinent to research or practice (Peffers, Tuunanen, Rothenberger & Chatterjee, 2007). DSRM incorporates a solid process of designing artefacts to create


39

solutions to problems and make research contributions. The produced artefacts may include methods, models or frameworks (Hevner & Chatterjee, 2010). Hence, after careful examination of the factors defined in section 3.1, DSRM was used for reaching the goal of this project. In the paper by Hevner and Chatterjee (2010), guidelines have been proposed that must be kept in mind whilst using DSRM for carrying out proper research. The relevance of the solution to the problem that is embedded in the artefact is the foremost and most important attribute. Additionally, the quality and potency have to be evaluated carefully. Hevner and Chatterjee (2010) also add that, while in the development phase the researcher should employ a search process that draws from the existing literature and theories that point and help the researcher to produce a solution. In this research, a robust SLR process has already been applied for an initial search process that guided the researcher into the right direction by providing insights into the problem domain. Lastly, Hevner and Chatterjee (2010) states that the presentation of the research document has to be effective so that it is seamlessly communicated to the audience.

3.3.1

Design science: The process

The framework proposed by Peffers et al. (2007) incorporates principles and procedures that are consistent with prior literature related to DSRM. Hence, it has been used widely as a reference pattern for conducting a DSRM and was also used to engineer this research. DSRM consists of six main steps as described in Peffers et al. (2007) that would steer this research towards a reliable solution: Problem definition and motivation is generally the initial step with which most of the research projects commence. A problem definition is defined that leads to the development of an artefact that solves it. This, in turn, motivates the audience and the researcher himself to undertake further research in the area and build on top of


40

it. In Chapters 1 and 2, a problem definition has already been defined. The resultant solution of our research would help understand the rationale associated with the solution from the perspective of the researcher towards the problems addressed previously. It would also make clear the constraints, resources required, general feasibility and initial expectations. Definition of objectives for a solution ascertains the major objectives of the solution and its viability. The objectives can be qualitative or quantitative. A high level view of the objectives were defined in Chapter 2 in the form of Research Questions after a careful examination of literature and its viability. Additionally, a detailed list of system requirements, objectives and quality attributes were developed based on the Research Questions and are mentioned in the subsequent sections that would answer the question: “How will the proposed artefact be able to support solutions to the problems addressed in Chapter 1 and Chapter 2 ?” Design & Development creates an artefact that can be in the form of a model, method or instantiations (Hevner & Chatterjee, 2010). This phase is dedicated to research, and building functionality wherein, different insights from the literature review, architectural approaches and patterns in software engineering were researched and consulted for methods that helped the researcher develop the artefact as detailed in Chapter 5. The Demonstration phase is dedicated to the implementation of the created artefact in the real world to solve the problems addressed previously. This phase requires a significant amount of time and considering the time constraint in this study this cannot be fully integrated with this study. The Evaluation phase of DSRM is designed to appraise the ability of the artefact to support the solution to the problems. The objectives defined previously are compared to the solution. In our case, the evaluation is qualitative and based on appropriate logical proof derived from previous studies, existing solutions and gaps identified through SLR.


41

Additionally, the solution was evaluated based upon the qualitative performance of the artefact in terms of the quality attributes defined in Chapter 4 which will be supported by appropriate evidence and logical proof from multiple areas of research (design patterns, frameworks etc.). As stated by Hevner and Chatterjee (2010), “At the end of this activity the researchers can decide whether to iterate back to step three to try to improve the effectiveness of the artefact or to continue on to communication and leave further improvement to subsequent projects. The nature of the research venue may dictate whether such iteration is feasible or not.”. Hence, due to time constraints because of the ad hoc nature of this Research project the researcher needed to cut back on the iterations (back to design and development) which are generally done based on the effectiveness of the artefact as analysed in this phase. Communication is the last phase of the DSRM. In Hevner and Chatterjee (2010), the author stresses the importance of the presentation of the structure of the research for effective communication to its audience. The rigor of the research design can be enhanced by following a structure which includes a problem definition, a literature review, research design, analysis, result and conclusion. A Systematic Literature Review has been used in this paper which is also discussed in the following section.

3.3.2

Systematic Literature Review

Chapter 2 is dedicated to the Systematic Literature Review (SLR) method which helped in the definition of Research Objectives (as mentioned in the previous section), identifying gaps and gaining valuable insight into the problem domain, which would assist the researcher in the conduction of design and development of the artefact. The SLR is based on the guidelines provided by Siddaway (2014) and Kitchenham and Charters (2007), both of which are considered rigorous and robust in the research


42

community of Information Technology. The SLR involved a series of steps starting from planning and scoping, review of objective and research questions and then defining a formal search strategy. The strategy included the details of the databases used and the search criteria which helped modularize the objectives by creating search terms and queries based on binary operators. Exclusion and inclusion criteria were defined which was used to filter out research papers that did not align with the research objectives.

3.3.3

Requirements Modeling Methodology

Section 4.2 of this research is dedicated to the requirement elicitation. The conceptual model of eliciting requirements as described by Dardenne, van Lamsweerde and Fickas (1993) was used to elicit and document requirements for the proposed framework. The said method has been widely used to elicit requirements for systems and this research uses an adaptation of the same. The method involved defining the primary goals of the framework at a meta level first from which the domain level goals were formulated. Next, the meta and domain level goals helped the researcher define primary requirements. The requirements were further refined by carrying out exercises like "asking HOW questions". Hence, obtaining terminal requirements.

3.3.4

Software Architecture Analysis Method (SAAM): Scenario Based evaluation

Examination of the proposed solution to decide how much it meets the quality criteria is fundamental for evaluation. A methodology proposed by Kazman, Abowd, Bass and Clements (1996) called the Software Architecture Analysis Method (SAAM) was used for defining quality attributes which were later evaluated in Chapter 6 of this study. The methodology was adapted as per the research goals of this paper.


3.3.5

43

Framework Development Methodology

The framework development methodology presented in Ben-Abdallah, Bouassida, Gargouri and Hamadou (2004) was used for guiding the framework development. The unification principles used in the method provided an excellent and systematic way to map and present the different components of the proposed system using UMLs. The guidelines were used to create use cases, class diagrams and sequence diagrams which can be easily used as a reference for the easy implementation of the proposed solution. The use cases were derived from the scenarios defined during SAAM (refer to Chapter 4 Section 4.3). The class diagrams were composed using the design patterns derived from research.

3.4

Conclusion

To summarize, the overview of the research design can be seen as illustrated in Figure 3.1. DSRM is used as the primary methodology for carrying out this research. It is composed of Problem Definition and Definition of Objective which is partly achieved by Systematic Literature Review, Requirements Modeling Methodology and SAAM. Design and Development is done using the Framework Development Method and research as mentioned previously. Lastly, the solution is analyzed and evaluated using SAAM and additional qualitative methods.

Figure 3.1: Overview of research design

Chapter 4 System Requirements 4.1

Introduction

This section of the research aims at exploring the system requirements of the proposed solution. As mentioned previously, the objective of this study is to develop a framework architecture so that the class of software identified in RQ1 can be more easily designed and deployed in smart-home environments whilst addressing the problems and gaps designated as the result of SLR conducted in Chapter 2. System requirement modelling is an important activity in the development of a software framework. As stated by Bullet (1987), requirements modelling is the most important aspect that has the potential to cripple the whole system if done wrong. Therefore, it is important that the requirement modelling is done with great care. In Dardenne et al. (1993), the researchers present a requirement modelling methodology called Goal Directed Requirement Acquisition (GDRA) which is used in this research as it covers gaps of other requirement modeling methods, such as incomplete scope problem and acquisition problem.

44

Chapter 4. System Requirements

4.2

45

Elicitation of Requirements

The conceptual meta-model as described in Dardenne et al. (1993) consists of two main levels which help derive requirements for the system: 1. The meta-level presents a high-level abstract view of meta-concepts and relationships that are independent to the domain. In our case, it is the type of framework in general that makes software more easily designed and deployed. 2. The domain level view is the instantiation of the meta-level with domain specific requirements. Our research domain is smart home applications that address interoperability, dynamicity and reconfigurability.

4.2.1

Meta and domain level

Figure 4.1 on the following page depicts the meta and domain level view of the requirements whereby, the developer uses an interface framework to generate applications. The abstract view has an agent that performs an action on a system. The system then processes that information and inputs code and creates value. The corresponding domain level shows the instantiation of the meta level with a developer using the interface of the framework and the framework generating an application.

4.2.2

Goal identification from meta and domain level requirements

The first set of requirements is derived from the available knowledge at domain and meta levels, which in our case is also derived from the problem definition and SLR as mentioned in Chapter 2. The soft goals hence identified are shown in Figure 4.2 on page 47: The goals are related to each other, and some have dependencies depicted by arrow keys. The diagram depicts that the framework will be driven by design patterns keeping


46

Figure 4.1: Meta and domain level requirements diagram in mind the “composition over inheritance” principle as stated in Gamma (1995) which will be achieved by using design patterns through object-oriented programming. The resultant framework will help address the problems of interoperability, dynamicity and reconfigurability. Additionally, extensibility, code re-usability and inversion of control can be achieved by using OOPs. The number of lines of code will be reduced hence increasing the efficiency of the applications.

4.2.3

Obtaining new goals and refining them by asking HOW questions

The next step is the identification of subgoals by asking “how” questions on the higherlevel goals, which helps the researcher break down the problem and formulate new goals. How will the framework be designed? The framework reference architecture was developed by using the guidelines provided by Ben-Abdallah et al. (2004). The architecture can then be used and implemented into the code. The framework architecture will be composed of use cases, scenarios, class diagrams based on design patterns and sequence diagrams.


47

Figure 4.2: Resultant soft goals of requirement modelling How will the Design Pattern be designed? UML is an excellent syntactic way to describe class and method architectures, which can be directly implemented on top of other frameworks and languages in future. The OSGi framework identified in SLR is a good candidate for implementation. Hence, UML will be used to describe the core design.

4.2.4

Terminal requirements for the framework

From the exercises carried above, the researcher was able to derive the following list of functional terminal requirements, which our artefact would be based on: • The framework should address interoperability whilst adding new smart objects to the smart home environment.


48

• The framework should address automatic reconfiguration and dynamicity. • The framework should incorporate best practices using design patterns. • The framework should have an interface and should be developer friendly whilst making it easier for them to develop complex applications whereby they concentrate on the business logic rather than the code. • The framework should have a high-level architecture designed with the help of UMLs. • The framework should have a low-level architecture consisting of the design patterns clearly describing the abstract classes, methods and instantiations using UML. The non-functional requirements identified as a part of the above exercise are: • Re-Usability: The framework should enhance re-usability by definition of abstract components that can be used to create new and highly complex applications. • Extensibility: The framework should be extensible for customization without making major changes in the core classes. • Efficiency: The framework should reduce the number of code lines to enhance performance and effectiveness.

4.3

Quality Attributes & Evaluation

Investigation of the proposed programming framework to determine the degree to which it meets the quality criteria is essential for evaluation. However, it is often hard to analyse and evaluate any architectural framework solely based on abstract quality attributes, which are too vague and do not provide sufficient backing for evaluation (Kazman


49

et al., 1996). The guidelines given by Kazman et al. (1996), based on the Software Architecture Analysis Method (SAAM), which is a scenario-based architectural analysis method was used to elicit the quality attributes of the proposed system. This will later be used for its evaluation. Scenarios were used widely to elicit requirements which take into consideration all the stakeholders of the system. All roles relevant to the system (eg., developer, end user) were taken into account when making design decisions. SAAM has been adapted as per the research goals of this paper and was used as a foundation for evaluation of the properties of the proposed framework. The following steps involved in SAAM that were followed by this exercise contain: • The Describing Architecture: As mentioned previously, UML will be used to describe the architecture framework which contains simple lexicon that depicts the different components, relationships and the state, control and flow of data clearly. Additionally, as mentioned by Kazman et al. (1996), simple representations using UML does not limit SAAMs efficiency in performing evaluations. • Scenario Development: This phase contains the various kinds of features that the system must contain and the changes that are expected to take place in the near future. All-important users and the actors involved must be thoroughly documented to put together all possible scenarios. The proposed framework is aimed at helping developers build applications for smart home environments whilst addressing the problems of Interoperability, Dynamicity and Reconfiguration. The applications can then be deployed in the smart homes in any manner (using a smartphone or a central server connected to smart devices) and can be utilized by the inhabitants of the smart home. Hence, there are two main stakeholders in the system that need to be taken into account as shown in Table 4.1.


50

Table 4.1: Stakeholer Analysis Table Stakeholder Developer

Inhabitants of the smart-home

Role The developer will use the framework to create highly complex applications that would be deployed in a smart-home environment. The developer has basic programming knowledge. The developer will be able to add different smart devices, sensors and actuators and add logic to it using the framework. The smart-home inhabitants are the people living in the smart homes. They are the people from where the business logic for the applications that are created by the developers originate. Their need will result in the development of the applications using the proposed framework. They will be able to interact with the system interface to view updates and do minor operations.

The tasks stated below are elicited using the exercises carried out in this chapter and insights generated from SLR in Chapter 2. Scenarios for Developer: – Add a new actuator/sensors to the application: Code for new sensors/actuator is generated using an interface of the framework, and the corresponding logic is generated using OOPs. The code generated addresses interoperability, dynamicity and reconfiguration. – Delete a sensor/actuator from the application: An existing sensor/actuator configuration is removed from the application when it is no longer needed. – Add functionality to an existing sensor/actuator and connect it to other sensor/actuators. Scenarios for User: – If a sensor fails, the framework provisions for manual entry of sensing information.


51

– The user is able to replace the sensor/actuator. • Scenario Evaluations and interactions: Each scenario is individually evaluated after the design of the framework keeping in mind the following properties: It is determined whether the goal of the scenario can be achieved directly or if it warrants an in-direct change (switch to the components of the framework). The latter signifies an undesirable framework. As advised in Kazman et al. (1996), a tabular representation of the given evaluation is helpful in summarizing the impact and quality of the system. • Scenario Interactions: Different scenarios may overlap in changes and function to the components and hence interact with each other. Changes affecting common set of elements may lead to conflicts. This identification helps in determining the quality of the framework as the fewer the scenario conflicts, the more desirable the system is. This phase is carried out in Chapter 6 of this paper after the design and development of the overall evaluation. • Overall Evaluation: The overall assessment is a subjective process and is done keeping in mind the weight of each quality attribute and scenario. Hence, the weight and interactions are used to determine the overall effectiveness and quality of the system. As mentioned previously, this phase is carried out in Chapter 6.

4.4

Conclusion

To conclude, this chapter contained the different methods used for requirement elicitation as well as quality attribute development for evaluation. These exercises provided the researcher with information for designing and development of the framework, which is detailed in the next chapter, and the evaluation which is stated in Chapter 6: Analysis. It can be observed that there is overlap between the scenarios and the terminal


52

requirements which is due to the fact that scenario enumeration is a type of requirement elicitation as well (Kazman et al., 1996).

Chapter 5 System Design & Development 5.1

Introduction

This section of the report describes the different components of the proposed framework architecture. The framework has been developed based on the requirements elicited using requirement modeling exercises carried out as mentioned in Chapter 4.

5.1.1

Interoperability, Dynamicity and Reconfiguration

Smart homes consist of "n" number of different smart devices that are made up of different types of sensors and actuators. The function of sensors is to sense their environment and give out a response. For instance, a simple example would be a motion sensor that senses some movement in a room before it goes off and notifies the system, it can either be binary i.e., 0 or 1 where it is idle and sensing nothing or sensing something in room respectively. Actuators on other hand are objects that are invoked by the sensors to do a particular job. Again, if the motion sensor is taken into account, it can be programmed to invoke upon an actuator which can be a light bulb which can be turned on and off. Hence, if we have a number of actuators and sensors in a smart home environment, the resultant application code needs to be flexible enough and the 53

Chapter 5. System Design & Development

54

actions should not be hard coded but rather be based on an invoker and instantiated using dependency injection. If a new invoker/actuator is introduced into the smart home environment, that is not a motion sensing equipment but some other kind of smart device from a different manufacturer, the same architecture should work with it without having to rewrite any core libraries. Hence, the framework architecture should address interoperability at the software level which would make the system work regardless of what kind of device is plugged into the smart home environment. The dynamic nature of the sensors warrant change in the configuration at run time. Instantiations are used and classes are composed in a way where the objects can be instantiated and passed into other objects at runtime without changing the code. This research also addresses Smart-home applications that care for the inhabitants. A number of sensors and actuators are employed to monitor the health of the inhabitants. Such applications warrant mission critical functionality where the delivery of data is very important. Sensing devices are hardware that have a certain life span, which can fail because of a number of reasons, such as electricity surge or expiration. In such situations, the functionality of reconfiguration, which should alert the inhabitant to enter data manually or prompt to take relevant action for continued operation of the system, has to be added to the core of the framework and cannot be left to the discretion of the software developer.

5.1.2

Application Frameworks for developing applications

As stated by Murray, Carrington and Strooper (2004), “a framework is a reusable design that requires software components to function”, whereby the developer must provide the business logic in code by either writing it or using a user interface to generate it. A framework is represented by a set of abstract classes and their instances interact with each other and the system to generate some value (Johnson, 1997). A framework


55

can also be defined as a skeleton of a software application that can be customized as per need of the client by a software engineer. There are numerous frameworks that have been developed and which provide tools and components that help make application development easy, efficient, maintainable and reliable (Johnson, 1997). The framework describes the whole architecture of the resultant application that is common to our research domain and will help define its skeleton, classes, objects and their collaboration with each other. The predefinition of these design parameters was done by the proposed framework for designing and deploying smart home applications. A framework can be divided into three main categories: blackbox framework, white box framework and a greybox framework (Fayad & Schmidt, 1997). A Blackbox framework provides ready to use objects and functionality to the developer and no prior knowledge of the programming language used is required while a whitebox framework provides source code and class libraries that the developer needs to learn to use. Greybox is a mixture of blackbox and whitebox components. The proposed framework is similar to a greybox application generator, which compiles high level language to a standard architecture based on the Object Oriented Design patterns. A single framework is usually made up of a number of design patterns which are micro architectural components knitted together strategically to deliver optimum performance and efficiency using inheritance and composition. All frameworks are driven by certain development rules i.e., the developers have to follow certain patterns to make use of the framework to solve problems (in our case interoperability, dynamicity and reconfiguration) and reduce design decisions by rather focusing on the business logic. The rules in our framework are enforced by using an interface (not to be confused with Java interface keyword which has its own properties). The framework sits in a layer between the smart home platform architecture (hardware and OS) and the application code generated by the framework. It is responsible for compiling high level constructs specified by the developer into low level language


56

constructs that would be deployed in smarthomes. Hence, the developer will not have to worry about the efficiency of the program code or any other problems like interoperability or reconfiguration as specified earlier. The framework will be coded for most common application domains by combining the best features, language constructs and design patterns. The efficiency of code is of paramount importance. Hence, the resultant software for smart homes can be more efficiently designed and deployed.

5.1.3

Design Patterns and Object Oriented Programming (OOP)

Writing object oriented code for applications is not easy for new developers, which leads to a lot of problems and loopholes within the applications. The objects, classes, interfaces and inheritance used in OOP are some of the elements that are used to write OOP applications. Getting the design right the first time is nearly impossible. Experienced developers may be good at OOP, however, novice developers may take a lot of time and redesign to get it right. Despite this, there is still a chance of error. Our domain is Smart homes wherein, the applications that would run are mission critical. The applications would be responsible for not just switching on the light when someone walks in, but also for more complex tasks such as elderly care and live monitoring of their vitals. Hence, the application development for smart homes has to be controlled in some manner. As mentioned previously, the use of framework for the generation of software can improve the developer productivity, performance, interoperability and controlling the application development quality at the same time. The proposed OOP framework works on a strategic amalgamation of different design patterns that would control the application code and structure while making it simpler for the developers to develop applications for smart home environments. As defined by Gamma (1995), a design pattern defines an abstract problem that has occurred in the past repeatedly, and proposes an OOP pattern to solve it in the best possible manner by reducing coupling


57

and fostering code re-usability. A pattern skeleton generally consists of a name, the problem and its context, a solution usually depicted by UML and its trade-offs. OOP, as the name suggests, is composed of objects that may be data or class instantiations. Decomposition of the problem domain into objects is a challenge because its needs in-depth understanding of OOP principles, such as inheritance, polymorphism and compositions, etc. Design patterns solves these problems by specifying the object granularity, interfaces and implementations whilst addressing the problems at hand in the best possible manner (Gamma, 1995). Additionally, in today’s time where agile application development is practiced whereby change is embraced, it is important that the framework is open to changes in the future. Subsequently, a change in the framework would lead to the evolution of the resultant applications. Hence, loose coupling of the framework is important and can be complimented using design patterns (Gamma, 1995) . The guidelines provided by Gamma (1995) “Gang of four”, are used to select and use design patterns that are well respected and known in the computer science community. The advantages, domains, pairing with other design patterns and repercussions associated with each pattern has been carefully studied and used while designing the proposed framework. The proposed framework will be used to make the User Interface (UI) component out of the smaller components and interfaces. The UI class would provide the specifications and a template for implementation of the functionality. The same class will be used to parameterize the framework to generate code and compose behaviors for the application using a rule engine specified on the front end.

5.2

The framework

This section describes the different components of the proposed framework, their relationships with each other followed by sections describing the process of development.


5.2.1

58

Identification of main components

The main components as per the requirements elicited in the previous section are: • Class Libraries • UI Interface • Code generator

Figure 5.1: Overall architecture of the framework As shown in Figure 5.1, the framework is intended to sit between the "application layer" and "runtime components layer". The business logic layer contains the logic that is decided by the developer on how the sensors and the actuators in the smart home should function. The Runtime components layer contains the operating system and other services that help the framework communicate with the hardware layer underneath.


59

The proposed framework is composed of two types of classes: abstract classes and concrete classes and their relationships with each other. Furthermore, the framework is divided into two parts, namely a core also know as a frozen-spot which is common to all the applications that will be developed using the framework and a hot-spot which is variable and parameterized as per the problem domain (Ben-Abdallah et al., 2004). The hot spots thus defined can be further divided into whitebox and blackbox hotspots wherein the variables are implemented using methods, classes and composition. All the classes and hotspots are depicted using UML diagrams. F-UML proposed by BenAbdallah et al. (2004) increases the descriptiveness of the diagrams by clearly depicting the classes and their relations, core and hotspots (instantiations). F-UML design process employs three steps that guides the researcher to structure the model by eliciting the core, blackbox and whitebox hotspots. The process, as described in Ben-Abdallah et al. (2004) consists of a use case design to extract common use cases which helps the designer to put the classes in the core. Various use cases are identified as hotspots and are tagged as the same. The next step involves the design of the class diagrams from the previous steps. The last step involves the design of sequence diagrams and the identification of optional messages to tag them as hotspots. Each step involves a unification exercise of all the possible use cases using a set of unification rules based on semantic comparison criteria which knits them together. In the following sections, the following notations would be used to express different components of the process: • Class and Object of Application: An → CAn (OAn ) • Use Case and Actor (AC) of Application A: An → UA n(ACA n)


5.2.2

60

Use Case Generation

The elicitation of the case diagrams is driven by the relationships between the actors and the use cases of the application. The following notation and rules are used iteratively to unify the use cases: • N_equiv (AA 1...AA n) depicts that the actors are identical/synonyms: The resultant actors and use case is added to the framework core. • N_var(AA 1...AA n) depicts that the actors are a variation of a functionality in the system: The resultant actor and use case is added as an inheriting use case to the generic core actor use case. • Gen_Spec (AA 1; AA nAA 2...AA n) is the generalization of names: the resultant actors use case is added into the framework with a general relation to the other actor use cases. • N_dist (AA 1...AA n) depicts the use cases which do not specify any of the above criteria: The resultant actor and use case is added as a hotspot away from the core. In the previous chapter, scenarios were defined for the proposed framework. Scenarios consists of many actors that act upon the functionality to perform a certain action or read a goal. Use cases are not much different but are more granular than scenarios. A set of use cases can be created to define a scenario. Hence, the use cases elicited below have been derived from the scenarios defined in the previous chapter. The following unification rules as show in Table 5.1 are applied to the use cases and a resultant use case diagram is generated (Figure 5.2 on page 62). Figure 5.2 on page 62 presents the use case diagram of the proposed framework. As illustrated, the two actors are the developer and the user (the smart home inhabitant). The methods tinted in light blue are the identified hotspots of the framework.


61

Table 5.1: Unification rules for use case diagram Rule N-equiv (Developer) N-equiv (User) Nequiv(addNewConfig) N-equiv(deleteConfig)

N 1 1 1 1

N1 equiv(automaticReconfiguration) N-dist(addNewSensor) 4 Ndist(addNewActuator) N-dist(addRule) Ndist(displayStatus)

5.2.3

Framework Actor Developer is added to the core Actor User is added to the core Use case add new config is added to the core Use case delete a config is added to the core Use case add auto reconfiguration is added to the core Use cases for adding new sensors, actuators, add Rules and displaying status and information added to framework hotspots.

Class Diagram Generation

This section of the report consists of the main class diagrams of the framework that are implementable for creating the class libraries of the framework. The composition has been carefully created by applying the design pattern knowledge to solve the problems in the domain of smart home environments. Similar to Step 1, this section also has a set of rules that drives the unification of different class diagrams. The following notations, classifications and rules were used iteratively to unify the different classes and their relationships: • N_comp (CA0; CA1 . . . . CAn ) depicts the different objects or components: The component A0 is composed of A1 — An • Att_equi (CA1 . . . . CAn ) depicts the "n" number of classes: The classes have methods with same name with same type. • Att_inter (CA1 . . . . CAn ) depicts the "n" number of classes: The classes have methods in intersection with other classes.


62

Figure 5.2: Use case diagram of the proposed framework • Att_conf (CA1 . . . . CAn ) depicts the "n" number of classes: The classes have methods with same name with different type. • Att_dist (CA1 . . . . CAn ) depicts the "n" number of classes: None of the above attribute criteria is satisfied • Op_equi (CA1 . . . . CAn ) depicts the "n" number of classes: The classes have operations with the same name and with the same type. • Op_inter (CA1 . . . . CAn ) depicts the "n" number of classes: The classes have operations that intersect with other classes. • Op_conf (CA1 . . . . CAn ) depicts the "n" number of classes: The classes have operations with the same name yet with different type. • Op_dist (CA1 . . . . CAn ) depicts the "n" number of classes: None of the above Operation criteria is satisfied


63

Table 5.2: Unification rules for class UML diagram Rule N-equiv (Interface Config) N-equiv (Interface actuator) N-equiv(Interface sensor) N-equiv(Interface observable) N-equiv(interface observer) N-equiv(interface configurationFactory) N-dist(concSensor) N-dist(concActuator) N-dist(concDisplay) N-dist(main outputCode)

N 1

N-dist(Handler Class)

1

1 1 1 1 1 3

1

Framework Interface Config is added to framework core Interface actuator added to framework core Interface sensor added to framework core Interface observable added to framework core Interface observer added to framework core Interface configurationFactory added to core. Classes are added to framework blackbox hotspots. Classes are added to framework whitebox hotspot as there are instantiations of the classes. Handler class is added to the framework as whitebox hotspot as it instantiates classes and adds code to main function in output class.

The diagram was put together by application of the unification rules(table 5.2) previously stated as well as careful consultation and research on design patterns. The classes have been made as abstract as possible which reduces coupling and boosts code re-usability and extensibility. The following classes are added to the framework: • Class Handler is the main class of the framework which is composed of methods like addDevice(), deleteDevice(), addNewConfiguration(), modifyConfiguration(). Add devices is used to create concrete implementations of actuators, sensors and different display devices. addNewConfiguration() and modifyConfiguration() instantiates the Interface configuration for adding new configuration and modifying them respectively at runtime. The instantiations made in class handler are used


64

Figure 5.3: The framework class diagram to generate code for the main() class which is the actual output application that would run in the smart home. • Interface Configurations is used for creating new configurations using the concrete classes of the devices listed as hot spots. It is composed of Interface actuator and Interface sensor. Their instantiations are passed in the configuration factory where the business logic is set. The access to method addReconfiguration() is coded into each instantiation of any new configuration created by the factory. Any sensor can be set and an invoker and sensors can be instantiated and passed into the function at runtime. • Interface Actuator is composed of two methods doOperation() and undoOperation(). Several concrete actuator classes implement this interface. The doOperation() method is instantiated for any arbitrary action the actuator does that can be


65

attached to the invoker through dependency injection. Similarly, an undoOperation() undoes the operation. This architecture will remain consistent as a core class regardless of what type of concrete class is instantiated and what thing is plugged into a smart home. • Interface Sensor is composed of a doOperation() similar to the actuator except its method receives any arbitrary response which the concrete sensor class return which may or may not be binary. The getState() function gets the current state of the sensor. This is primarily used to check the “live” state of the sensor and any other information that the sensor may provide. • Interface Observable and Interface Observer is used for adding reconfiguration to the framework. N number of devices and displays can be added to the framework which will be used to manually add data to the system in case any sensor goes down. Interface display can have different types of implementations composed of different displays and devices used for output.

Patterns The following patterns have been used in the framework as shown in Figure 5.3 on the previous page in the previous section to implement the introduced concepts: Strategy pattern: The strategy pattern is used by composing the Actuator and Sensor strategies with a common configuration interface. A strategy pattern declares a common interface whereby, the context uses it to instantiate the code defined by concrete classes that inherit from the strategies (Gamma, 1995). Command pattern: The command pattern is used by "encapsulating a request as an object, thereby parameterizing the client with different requests" (Gamma, 1995). It has an invoker (configuration) has interface command (interface sensor) with concrete implementation of sensor classes with different commands. That command acts upon


66

a particular receiver (actuator) to do some operation. It is integrated into the strategy pattern. Observer pattern: The observer pattern is used to address reconfiguration. It uses the concept of Push vs. Pull whereby, the sensor is responsible for notifying the system or other sensors when it has changed/failed rather than the other way round. All sensors/actuators need to be registered to the system. There is a one to many dependency between objects. Whenever a sensor fails it notifies the system and the registered displays and asks for a manual entry. Factory pattern: The factory pattern is used when the configuration methods are instantiated. Factory helps and makes it more abstract by building various configurations with actuators and sensors. The same configurations can be used in multiple rooms or situations in smart homes. The business logic can be encapsulated by using factories.

5.2.4

Sequence Diagram Generation

Figure 5.4: Sequence diagram of add new configuration Figure 5.4 presents the sequence diagram of adding a new configuration into the framework which has been derived from the class diagrams mentioned in the previous section. The class Handler has a method called addNewConfiguration() that instantiates the Interface Configuration. Instants of Actuators and Sensors are instantiated through the factory based on the parameters passed in the function. On instantiation of the factory


67

the sensors used in the configuration are added to the observable and corresponding observers (Displays) are instantiated which have relevant logic of alerts and entering manual data.

5.3

Conclusion

This section described the design of the proposed framework and its architecture in detail. The rationale and the significance of OOPs, interoperability, reconfiguration and design pattern were also discussed in this chapter. The framework design method provided by Ben-Abdallah et al. (2004) provided the researcher a systematic way to map the important components of the architecture using different exercises and building use case, class and sequence diagrams which would make implementation easier.

Chapter 6 Analysis 6.1

Introduction

This section of the report consists of the analysis and evaluation of the proposed framework that evaluates it based on the scenarios evaluations and interactions as defined previously.

6.2 6.2.1

SAAM based evaluation Perform scenario evaluations

As mentioned previously in chapter 4, the researcher used scenarios to express instances of quality attributes that are critical to the system. This section analyzes the proposed framework under consideration of how well the framework satisfies the limitations imposed by each scenario. The scenarios previously elicited were classified into direct or indirect as shown in Table 6.1. The direct scenarios are the ones that can be easily executed by the proposed framework without any modification. Indirect scenarios warrant a change to the composition

68

Chapter 6. Analysis

69

Table 6.1: Scenario evaluations for the proposed framework Description Add a new actuator/sensors to the application

Direct/ Indirect indirect

Delete a sensor/actuator from the application Add functionality to an existing sensor/actuator

direct

If a sensor fails, the framework provisions for manual entry of sensing information.

direct

The user is able to replace the sensor/actuator regardless of the manufacturer.

indirect

direct

Changes This will require the addition of concrete sensor/actuator classes in the whitebox hotspot of the framework. This will depend entirely on the type of smart device introduced into the smart home. no change required no change required as this can be done by changing the instantiation of the existing configurations that is stored in the database no change required as the reconfiguration is instantiated with each instantiation of the configuration by default provided a device is already instantiated for display. This will require changes in the concrete classes of the whitebox hotspot.

of the proposed framework. The resultant classification helped the researcher evaluate the fitness and desirability of the proposed system. As illustrated in table 6.1, only two scenarios warrant indirect changes to the framework. The first scenario where a new actuator or sensor has to be added to the system require changes to the concrete classes that inherit from the sensor/actuator interfaces. As mentioned in the previous chapter, these classes were already designated as hotspots of the framework and this change was anticipated. The implications of this scenario are moderate as adding new classes is essential as abstraction to the level of functionality of all smart devices cannot be defined in the sensor/actuator interface

Chapter 6. Analysis

70

class. This will be handled by the user interface’s underlying code in class Handler. The second scenario which has indirect classification deals with the replacement of the sensor/actuators, which is again a form of problem addressed in scenario 1 and hence a new concrete class has to be defined for a new sensor.

6.2.2

Reveal scenario interactions

Each scenario performs a task and necessitate changes in the system both direct and indirect in nature. Scenario interactions are used to track these changes and identify any overlaps with other scenarios. High scenario interactions equals high coupling between modules and low cohesion within modules which is an undesirable architecture. As per the analysis of the proposed framework, having used design patterns and good composition in development, the coupling of the classes was reduced and hence, the execution of individual scenarios did not result in any change in the core classes of the framework or affect any other class.

6.3

Overall evaluation

In the previous sections, the researcher used SAAM to analyze the proposed framework using scenario based evaluation methods. It can be concluded that the proposed framework is desirable as per the guidelines of Kazman et al. (1996). The scenarios were elicited as form the point of view of both the user and the application developer. Most of the scenarios resulted in direct execution and the scenarios that needed indirect changes to the classes were already identified during development and designated as hot-spots. The proposed framework is able to accommodate interoperability at software level as it abstracts the classes to an extent where minimal changes are required to the framework. Reconfiguration is instantiated by default which strengthens the fail-safe

Chapter 6. Analysis

71

nature of the application which is not addressed in any existing frameworks. As soon as a configuration is added, the participating sensing devices are added as observables. The framework incorporates best practices using design patterns whereby each request is encapsulated by instantiation and dependency injection which makes the framework truly dynamic. A programmer-friendly interface can be developed on top of the handler class which can be used to develop highly complex applications. Re-usability of the components is enhanced because everything is treated as an object and instantiated. Extensibility is enhanced through designating hotspots and no changes are needed to be done in the core classes as mentioned previously. The framework is highly efficient as it greatly reduces the number of code lines. To conclude, the proposed framework fills the gaps identified in the SLR in chapter 2 where no existing research was found which completely defined the design using patterns and composition that can be used for implementing the framework in future.

Chapter 7 Conclusion and Further Research This section of the research discusses the limitations, potential future works and conclusion of the research.

7.1

Limitations

Although the proposed framework helps fill most of the gaps identified in chapter 2 of this research, this research also faces some limitations that need to be taken into account. As mentioned in the previous sections, there were time constrains because of the nature of the research project. The implementation of the framework into a language was not possible which could have led to a more comprehensive demonstration of the framework. Secondly, as mentioned previously, the iterations involved in DSRM which involved going from design and back to requirements were cut back, again, due to time constraints. Increasing the number of iterations could have refined the framework more.

72

Chapter 7. Conclusion and Further Research

7.2

73

Future Work

The future work of this research would involve implementation of the proposed framework into programming language and creation of class libraries. Subsequently, those libraries will be used to create a user interface which will utilize the full potential of the class compositions formulated in this study. The user interface will let the developer create class instantiations and add concrete classes to the framework hotspots which will be used as reusable objects. Additionally, in future this a working prototype of this framework will be coded using a language/framework preferably OSGi as identified in chapter 2. It will be used for a case study by applying it to a particular situation.

7.3

Conclusion

In this paper, we presented an architecture that addresses interoperability, dynamicity and reconfiguration issues of sensors and actuators operating in Smart Home environments. We identified relevant research methods in a systematic way and selected design science to develop our framework. Systematic literature review allowed the researcher to identify gaps in the current research related to frameworks that address problems like interoperability, dynamicity and reconfiguration. Additionally, the SLR also helped identify various issues that come up at the software level due to these problems and what would be needed to address them. We used Requirement Modeling to elicit requirements for the framework solution which also helped the researcher draw a clear picture of the research that was needed to be done for design and development. SAAM scenario based evaluation method was used to develop scenarios for the framework at early stage which helped the researcher with the design and development. It also helped create use cases during the design and development phase. F-UML framework development methodology helped the researcher systematically research and design the framework

Chapter 7. Conclusion and Further Research

74

which provided elements like use case, class diagrams and sequence diagram that will prove useful while implementing the architecture into code in future. In addition to SAAM, we also compared the said architecture to the frameworks identified using SLR and evaluated the framework architecture. The analysis suggested that the proposed architecture fills all the the gaps identified previously.

References Alliance, O. (2015). Open services gateway initiative. URL: http://www. osgi. org. Avison, D. E., Lau, F., Myers, M. D. & Nielsen, P. A. (1999). Action research. Communications of the ACM, 42(1), 94-97. Ballari, D., Wachowicz, M. & Callejo, M. A. M. (2009). Metadata behind the interoperability of wireless sensor networks. Sensors, 9(5), 3635-3651. Ben-Abdallah, H., Bouassida, N., Gargouri, F. & Hamadou, A. B. (2004). A uml based framework design method. Journal of Object Technology, 3(8), 97-120. Bodhuin, T., Canfora, G., Preziosi, R. & Tortorella, M. (2005). An extensible ubiquitous architecture for networked devices in smart living environments. Lecture notes in computer science, 3823, 21. Broens, T. & Van Halteren, A. (2006). Simucontext: Simply simulate context. In Autonomic and autonomous systems, 2006. icas’06. 2006 international conference on (pp. 45–45). Bullet, N. S. (1987). Essence and accidents of software engineering, fp brooks. IEEE Computer, 20(4), 10-19. Dardenne, A., van Lamsweerde, A. & Fickas, S. (1993). Goal-directed requirements acquisition. Science of Computer Programming, 20(1), 3-50. Easterbrook, S., Singer, J., Storey, M.-A. & Damian, D. (2008). Selecting empirical methods for software engineering research. Guide to advanced empirical software engineering, 285-311. Fayad, M. & Schmidt, D. C. (1997). Object-oriented application frameworks. Communications of the ACM, 40(10), 32-38. Galzarano, S., Giannantonio, R., Liotta, A. & Fortino, G. (2016). A task-oriented framework for networked wearable computing. IEEE Transactions on Automation Science and Engineering, 13(2), 621-638. Gamma, E. (1995). Design patterns: elements of reusable object-oriented software. Pearson Education India. Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1993). Design patterns: Abstraction and reuse of object-oriented design. In European conference on object-oriented programming (p. 406-431). Springer. Hevner, A. & Chatterjee, S. (2010). Design science research in information systems. In Design research in information systems (p. 9-22). Springer. Håkansson, A. (2013). Portal of research methods and methodologies for research projects and degree projects. In Proceedings of the international conference on

75

References

76

frontiers in education: Computer science and computer engineering (fecs) (p. 1). The Steering Committee of The World Congress in Computer Science, Computer Engineering and Applied Computing (WorldComp). Johnson, R. E. (1997). Frameworks=(components+ patterns). Communications of the ACM, 40(10), 39-42. Kantorovitch, J. & Niskanen, I. (2010). Interactive home supervision application think visually. In Advanced information networking and applications (aina), 2010 24th ieee international conference on (p. 698-704). IEEE. Kazman, R., Abowd, G., Bass, L. & Clements, P. (1996). Scenario-based analysis of software architecture. IEEE software, 13(6), 47-55. Kitchenham, B. & Charters, S. (2007). Guidelines for performing systematic literature reviews in software engineering (Tech. Rep.). Krishna, M. B. & Verma, A. (2016). A framework of smart homes connected devices using internet of things. In Contemporary computing and informatics (ic3i), 2016 2nd international conference on (p. 810-815). IEEE. Leong, C. Y., Ramli, A. R. & Perumal, T. (2009). A rule-based framework for heterogeneous subsystems management in smart home environment. IEEE Transactions on Consumer Electronics, 55(3). Mainetti, L., Manco, L., Patrono, L., Sergi, I. & Vergallo, R. (2015). Web of topics: An iot-aware model-driven designing approach. In Internet of things (wf-iot), 2015 ieee 2nd world forum on (p. 46-51). IEEE. Mehmood, N. Q., Culmone, R. & Mostarda, L. (2014). An ontology driven software framework for the healthcare applications based on ant+ protocol. In Advanced information networking and applications workshops (waina), 2014 28th international conference on (p. 245-250). IEEE. Murray, L., Carrington, D. & Strooper, P. (2004). An approach to specifying software frameworks. In Proceedings of the 27th australasian conference on computer science-volume 26 (p. 185-192). Australian Computer Society, Inc. Myers, M. D. (2013). Qualitative research in business and management. Sage. Papadopoulos, N., Meliones, A., Economou, D., Karras, I. & Liverezas, I. (2009). A connected home platform and development framework for smart home control applications. In Industrial informatics, 2009. indin 2009. 7th ieee international conference on (p. 402-409). IEEE. Peffers, K., Tuunanen, T., Rothenberger, M. A. & Chatterjee, S. (2007). A design science research methodology for information systems research. Journal of management information systems, 24(3), 45-77. Runeson, P. & Höst, M. (2009). Guidelines for conducting and reporting case study research in software engineering. Empirical software engineering, 14(2), 131. Siddaway, A. (2014). What is a systematic literature review and how do i do one. University of Stirling, 1-13. Suryadevara, N. K. & Mukhopadhyay, S. C. (2015). Smart homes: design, implementation and issues (Vol. 14). Springer. Trochim, W. M. & Donnelly, J. P. (2001). Research methods knowledge base.

References

77

van Dijk, H. W., Scholten, H. J., Tobalina, A. & Milanini, S. (2007). Open home networks: the teaha approach. In Networking, 2007. icn’07. sixth international conference on (p. 53-53). IEEE.

software architecture for developing and deploying applications for ...

software architecture for developing and deploying applications for ...

Suggest Documents

Developing and Deploying Siebel Business Applications - Oracle ...

Developing and Deploying Sensor Network Applications ... - CiteSeerX

A Software Architecture for Multidisciplinary Applications ... - CiteSeerX

an autonomic software architecture for distributed applications

Deploying Componentâbased Applications - Generative Software ...

A Software and Hardware Environment for Developing AI Applications ...

Developing and Deploying High Performance PHP Applications - Oracle

030-29: Developing and Deploying Java Applications around SAS ...

[PDF] Download Using Docker: Developing and Deploying Software ...

Read Using Docker: Developing and Deploying Software with ...

Software Architecture for Automated

PDF Download Using Docker: Developing and Deploying Software ...

Developing an architecture for the software subsystem of a learning ...

Implementing Agile Processes for Deploying Software ...

MDC: A Software Tool for Developing MPEG Applications

MDC: A Software Tool for Developing MPEG Applications

Developing Specialised Software for Real Estate Applications A Case ...

Developing Locally Relevant Software Applications for Rural ... - Core

A generic software architecture for portable applications in ...

Developing and Deploying Multihop Wireless Networks for Low ...

DRIVE: A tool for developing, deploying, and managing ... - Google Sites

A user-centric approach for developing and deploying service front ...

PDAgent: a platform for developing and deploying mobile agent

DRIVE: A tool for developing, deploying, and managing ... - IEEE Xplore

software architecture for developing and deploying applications for ...