HealMA: a model-driven framework for automatic generation of IoT-based Android health monitoring applications.

The development of IoT-based Android health monitoring mobile applications (apps) using traditional software development methods is a challenging task. Developers need to be familiar with various programming languages to manage the heterogeneity of hardware and software systems and to support different communication technologies. To address these problems, in this paper, we first analyze the domain of health monitoring mobile applications and then propose a framework based on model-driven engineering that accelerates the development of such systems. The proposed framework, called HealMA, includes a domain-specific modeling language, a graphical modeling editor, several validation rules, and a set of model-to-code transformations, all packed as an Eclipse plugin. We evaluated the framework to assess its applicability in generating various mobile health applications, as well as its impact on software productivity. To this end, four different health monitoring applications have been automatically generated. Then, we evaluated the productivity of software developers by comparing the time and effort it takes to use HealMA compared to a code-centric process. As part of the evaluation, we also evaluated the usability of HealMA-generated apps by conducting a user study. The results show that HealMA is both applicable and beneficial for automatic generation of usable IoT-based Android health monitoring apps.

Introduction

Remote health monitoring is an essential component of a healthcare system to address the needs of growing populations located in various geographical areas (Sundaravadivel et al. 2017). This is particularly important when dealing with chronic and infectious diseases (e.g., blood pressure, respiratory diseases, HIV), which require long-term monitoring and treatments (World Health Organization Official Website 2020a).

A recent trend in remote health monitoring is to make use of the Internet of Things (IoT) (Dhanvijay and Patil 2019), which encompasses a set of technologies that connect various devices anywhere and at any time. A typical application of IoT in health monitoring is to monitor a patient’s health status using mobile applications (apps) (Islam et al. 2015). This is particularly relevant in today’s context because of the increasing number of smartphone users. According to Statista, about 3.8 billion people will have access to a smartphone by the end of 2021 (Statista Official Website 2020). The health monitoring apps market size was valued at USD40 billion in 2020 and is expected to grow at an annual growth rate of 17.7% from 2021 to 2028 (Grand View Research Official Website 2021).

The development of health monitoring apps from scratch or using domain-independent modeling languages, e.g. UML, is a time-consuming and repetitive task. The challenge is that the developers must have knowledge about the symptoms that need to be monitored, manage the heterogeneity of hardware and software systems, and understand the different communication technologies that are supported in IoT (Islam et al. 2015; Inupakutika et al. 2020; Banos et al. 2014; Qi et al. 2017). To address this challenge, in this paper, we propose a model-driven framework, called HealMA (Health Monitoring App), for rapid development of remote health monitoring apps. HealMA consists of four components: (1) a domain-specific modeling language (DSML) that supports the concepts of remote health monitoring, which we identified based on a thorough analysis of the domain, (2) a graphical editor that enables developers to model a remote health monitoring app, (3) constraints and validation rules, and (4) a model-to-code transformation engine that generates automatically the final app code from the model. These components are all packaged as an Eclipse plugin. Currently, HealMA supports the development of Android apps only, considering the fact that the Android app market accounts for 72.2% of the mobile app market share in 2021 (Statcounter Official Website 2021). The generated apps will be posted on app markets to be used by healthcare patients and providers.

The HealMA framework is very intuitive to use. Once the app requirements are defined, a developer uses the modeling editor to select the model elements relevant to the app by a simple drag and drop. After the model is validated against predefined constraints, the app code (including Java and XML files) is then generated automatically through our embedded model-to-code transformation engine. The final step is to open the generated code in an Android IDE, complete the project according to the comments provided by the HealMA framework, and customize the project as needed. As we will show in the evaluation section, HealMA simplifies greatly the development process of health monitoring apps, which should result in increased productivity.

We evaluated HealMA using two strategies. First, we implemented four case studies in which we generated four different remote health monitoring apps. The objective is to evaluate the applicability of HealMA in generating different monitoring apps, as well as assess the effectiveness of HealMA in increasing the productivity of developing health monitoring apps (i.e., effort and time-saving in the development) compared to a pure code-centric approach. The second strategy consists of conducting a user study in which we evaluate the usability of HealMA from the developers’ perspective. The results show that HealMA can help developers generate health monitoring apps with less effort, and the generated apps are usable for the end users.

The remainder of this paper is structured as follows. In Sect. 2, we address the background, define the scope of this research, and review the related work. Section 3 introduces the proposed framework, including the modeling language, graphical modeling editor, validation rules, and model-to-code engine. In Sect. 4, we discuss the evaluation of the proposed framework from different viewpoints. We also address the threats to validity in this section. Finally, we conclude the paper and elaborate on the future work in Sect. 5.

Background and related work

This section is divided into two parts. In the first part, we provide background information about model-driven engineering and remote health monitoring using IoT. We also show the role of applications in the IoT-based health monitoring process, and define the scope of this research. In the second part, we discuss about the related work.

Background

Model-driven engineering

Models are a simplified representation of reality. They make complex facts more understandable by raising the level of abstraction. In traditional software development approaches, models were used for design and documentation. In recent years, Model-Driven Engineering (MDE) has emerged as a new software engineering approach where models are key software development assets used to build the system. The code is generated from models. The aim is to reduce development complexity by focusing on models instead of code (Brambilla et al. 2017).

In MDE, the system is produced based on different abstraction levels of models and transformations. An example of this can be seen in the Model-Driven Architecture (MDA) standard proposed by the Object Management Group (OMG).1 MDA divides the development process into four levels. In the first level, the requirements of the system are defined with the highest abstraction level in a Computational Independent Model (CIM), which could be a business or domain model. In the second level, CIM is transformed into a Platform Independent Model (PIM) that represents the structure and behavior of the system without considering the execution platform. On the third level, the PIM is transformed into a Platform Specific Model (PSM). A PSM is a model of the execution platform. Finally, the PSM model is transformed into code (Brambilla et al. 2017).

An important aspect of MDE is the development of Domain-Specific Modeling Languages (DSMLs) to capture the domain concepts and their relationship. DSMLs help design the system. Same as other languages, a DSML includes three main parts, namely an abstract syntax, a concrete syntax, and semantics. The abstract syntax shows the grammar of the language and is defined using a metamodel. The concrete syntax is a graphical representation of the language elements that are defined in the abstract syntax to enable developers to use the language. Semantics capture the meaning of the elements of the metamodel, i.e., the language elements and their relationships (Van Deursen et al. 2000; Brambilla et al. 2017).

Transformations are an important pillar of any MDE approach. The generation of code requires the definition of transformation rules. A transformation rule is simply a program that takes an artifact as input and creates another artifact as output (Panahandeh et al. 2021). Considering ‘model’ and ‘code’ as the artifacts, there are four types of transformations: model-to-model, model-to-code, code-to-model, and code-to-code. To automatically generate code from the models using MDE, model-to-code transformations are used (Brambilla et al. 2017).

Remote health monitoring using IoT

IoT is a new trend that makes various domains smart by connecting different objects. Remote health monitoring is an example of IoT applications in the health domain. IoT helps collect data and track the patient health status, efficiently (Islam et al. 2015).

There have been many IoT-based remote health monitoring architectures that are proposed in the literature (Pathinarupothi et al. 2018; Wan et al. 2018; Al-khafajiy et al. 2019). These architectures mainly vary in terms of the devices used for sensing health and environmental parameters, the use of different communication technologies for transmitting data, and the types of applications for data analysis and visualization. Most architectures rely on mobile apps for performing various tasks. Mobile apps may are used by patients to visualize their health status and also as a gateway to transmit health information to healthcare providers. Health professionals use mobile apps and web-based systems to visualize and monitor the health conditions of patients remotely.

Figure 1 shows a typical remote health monitoring architecture which consists of three layers: (1) patient layer, (2) communication and storage layer, and (3) supervisor layer. These layers are explained in the following.As indicated in the shaded box in Fig. 1, the scope of our work (HealMA) is on the automatic generation of the apps that run on the patient’s smartphone to act as a gateway and also to provide different functionalities for the patient such as visualizing and managing their health status.

Fig. 1

A typical architecture for a remote health monitoring system (The red boxes show the role of apps in remote monitoring process. The shaded box shows the scope of HealMA) (Color figure online)

The patient layer: This layer consists of a set of physical objects (e.g., wearable sensors) that are placed on the patient to collect blood pressure, heartbeat rate, and other health-related measurements of interest. Devices can also be used to record environmental parameters such as humidity and temperature. The collected data is often sent to a gateway device that relays the information to healthcare providers. A typical gateway is the patient’s smartphone. The communication technology is selected based on the distance between the objects and the gateway. Bluetooth is used for short-range communications, such as connecting a smartwatch to a smartphone. Wi-Fi is used for longer distances such as collecting the temperature of a room in a building. In addition to being a gateway, the patient’s smartphone can do some basic processing, store the data locally, and visualize the results for the patient.

The communication and storage layer: Gateways send the collected data to the cloud servers through Internet. The data is stored on the servers and ready to be processed. Additionally, in this layer, environmental parameters such as the air quality index (AQI) and the weather status could be accessed by the patients and supervisors through online public services.

The supervisor layer: The results of processing should be reported in an appropriate format for different participants in the health monitoring process, e.g., patients, nurses, doctors, and patient’s family members. This is usually done through applications that act as an interface (mobile apps or traditional web applications).

Related work

To our knowledge, there is no work that focused primarily on the generation of health monitoring applications using an MDE approach. In this section, we considered a wider range and reviewed studies that focus on conceptual models related to IoT-based health care systems, as well as the studies that use MDE in the domains close to the IoT-based health care domain. In the following, we group these studies into three categories in terms of domain and discuss how they differ from our study.

The first category is concerned with the studies that focused on conceptualization or development of the IoT-based systems and applications. Bauer et al. (2013) worked on domain engineering and introduced the IoT-A domain model which is part of a reference architecture, designed as a common ground to show the main components of IoT-based systems. Patel et al. (2011) also focused on domain engineering and introduced another domain model for IoT-based applications, which, compared to IoT-A, is expressed in a lower level of abstraction and is able to provide more details about the domain. Ontologies have also been used to model IoT domain concepts, e.g., in the work of Bermudez-Edo et al. (2016). Einarsson et al. (2017) introduced a DSML called SmartHomeML to automatically generate smart home connectivity services. Hussein et al. (2017) used model-driven development to generate automatically Java code for self-adaptive IoT-based systems. The difference between these studies and the work presented in this paper is that these studies cover the broader domain of IoT, whereas our work has a more specific scope of IoT-based health monitoring.

The second category covers studies that focused particularly on modeling IoT-based health monitoring systems. Rhayem et al. (2017) extended the ontologies of the IoT-based systems for the health monitoring domain and introduced HealthIoT, an ontology for storing data in a structured way for semantic reasoning on health data. Gomez et al. (2016) developed a client/server architecture to monitor the patient health status and to make recommendations to improve the patient’s condition. The recommendations are based on an ontology that includes devices, persons, locations, and time parts. Chellouche et al. (2013) proposed a framework to address semantic interoperability and automatic decision taking in machine-to-machine (M2M) health care systems. To store health data in a structured way, an ontology-based data model is presented that facilitates reuse and knowledge sharing. Ajami and Mcheick (2018) introduced an ontology, named COPDology, for remote monitoring of COPD patients. COPDology represents various aspects of remote health monitoring including patient’s clinical information, patient’s physical parameters, patient’s activities, environmental parameters, disease information, location information, device information, and service information. Considering such detailed information helps do semantic reasoning more accurately. Although the abstraction level of these studies is the same as our research, the goals are different. The objective of using ontologies is to create a structural model that would allow reasoning tasks whereas our research aims to model the domain of IoT health monitoring apps and provide tools for developers to automatically create these apps using a domain specific language.

The third category of the research studies related to our work is dedicated to the studies that focus on the development of mobile apps using model-driven techniques. Among the works in this category are domain-independent languages such as IFML2 that have the potential to be used for modeling mobile applications. In some cases, such as the work done by Brambilla et al. (2014), the language (IFML) has been extended for the purpose of modeling and automatic generation of mobile apps. Other works in this category introduced a new language to support the automatic generation of mobile apps. Usman et al. (2017) proposed a model-driven approach based on feature modeling and UML profiling to generate mobile applications for different platforms such as Android and Windows Phone. Vaupel et al. (2018) analyzed the mobile apps domain and presented a feature model, a modeling language, an editor, and a code generation infrastructure for the automatic generation of data-driven applications. Gharaat et al. (2021) used a model-driven engineering approach to create geo-location apps. The authors proposed a metamodel that captures the features of geo-location apps from which various apps that support these features can be automatically generated. Núñez et al. (2020) proposed a model-driven approach to tackle the complexity of designing the data layer for native mobile applications. This approach supports both online and offline methods for data management. They also provide some transformation rules to generate code for Android and Windows Phone applications. Similar to our research, these works have also focused on mobile app development blue using model-driven techniques. We argue that, generating a health monitoring mobile app using domain-independent languages or languages that are invented for designing all types of mobile apps needs a deep knowledge about health monitoring domain. Therefore, in our work, we focused on a specific domain (i.e., the health monitoring) to reduce the knowledge and expertise which is required for designing a health monitoring app.

To show the main similarities and differences between the current research and related work, we compare them in Table 1. The column “Domain” shows three categories that we used to classify related work. The “Approach” column describes the technique proposed by the studies. The “Purpose” column indicates the objective of the underlying research. The “Achievements” column summarizes the outcome of the research. All the research studies focused on domain analysis by proposing a conceptual model based on the objective of the study. For the studies that used MDE, in addition to the conceptual model, the outcome of the respective approaches are classified as either “Modeling” or “Code Generation tool”.

Table 1

Comparison between related work and current research

Research	Domain			Approach			Purpose			Achievements
	IoT	IoT + Health	Mobile apps	Domain engineering	MDE	Ontology	Domain analysis	Development	Reasoning	Conceptual model	Modeling tool	Code generation
Bauer et al. (2013)	∙	◯	◯	∙	◯	◯	∙	◯	◯	◯	◯	◯
Bermudez-Edo et al. (2016)	∙	◯	◯	◯	◯	∙	∙	◯	∙	∙	◯	◯
Patel et al. (2011)	∙	◯	◯	∙	◯	◯	∙	◯	◯	∙	◯	◯
Einarsson et al. (2017)	∙	◯	◯	◯	∙	◯	∙	∙	◯	∙	◯	∙
Hussein et al. (2017)	∙	◯	◯	◯	∙	◯	∙	∙	◯	∙	◯	∙
Rhayem et al. (2017)	◯	∙	◯	◯	◯	∙	∙	◯	∙	∙	◯	◯
Gomez et al. (2016)	◯	∙	◯	◯	◯	∙	∙	◯	∙	∙	◯	◯
Chellouche et al. (2013)	◯	∙	◯	◯	◯	∙	∙	◯	∙	∙	◯	◯
Ajami and Mcheick (2018)	◯	∙	◯	◯	◯	∙	∙	◯	∙	∙	◯	◯
Brambilla et al. (2014)	◯	◯	∙	◯	∙	◯	◯	∙	◯	∙	∙	∙
Usman et al. (2017)	◯	◯	∙	◯	∙	◯	∙	∙	◯	∙	◯	∙
Vaupel et al. (2018)	◯	◯	∙	◯	∙	◯	∙	∙	◯	∙	∙	∙
Gharaat et al. (2021)	◯	◯	∙	◯	∙	◯	∙	∙	◯	∙	∙	∙
Núñez et al. (2020)	◯	◯	∙	◯	∙	◯	∙	∙	◯	∙	◯	∙
Current research	◯	∙	∙	◯	∙	◯	∙	∙	◯	∙	∙	∙

Supported Not supported

To summarize, as indicated in the last row of Table 1, in our work we analyzed the domain of IoT-based health monitoring mobile apps and used MDE for the automatic generation of IoT-based health monitoring mobile apps. To achieve this, we designed a conceptual model (metamodel), developed a modeling editor, and provided transformation rules for automatic code generation.

HealMA framework

HealMA is a model-driven framework for the rapid development of remote health monitoring apps that run on the patient’s smartphone. It consists of four main components: (1) a DSML that describes the main concepts of the health monitoring application domain, (2) a graphical modeling editor to make modeling easier, (3) a set of constraint and validation rules to check the validity of the models, and (4) a model-to-code transformation engine to generate the application code (both Java and XML) for the Android platform. In the following Sects. 3.1–3.4, we discuss these components in more detail. Then in Sect. 3.6, we present the steps that developers should follow for developing an app using HealMA.

HealMA DSML

In order to define the HealMA DSML, we followed the phases for developing a DSML that were introduced by Mernik et al. (2005), namely Decision, Analysis, Design, Implementation, and Deployment. In the first phase, Decision, the necessity of defining the language is discussed. In the second phase, the main concepts of the domain are extracted. The objective of the third phase is to create the metamodel (the abstract syntax) of the DSML by extracting the domain concepts and their relationships. In the fourth phase, the metamodel is implemented in a tool. The last phase consists of defining the concrete syntax of the language and building a graphical editor. In the following, we describe each phase in the context of HealMA.

Decision

The emergence of remote health monitoring has created a demand for developing mobile apps for health monitoring. In general, such apps receive the measured health data and visualize it for the patient. Developing these apps needs expertise in different aspects, including programming skills to communicate with different devices and visualizing the data in an understandable format. Therefore, developing from scratch using the general-purpose languages is a time-consuming and repetitive task, which may delay the time to market. Due to the fact that these apps tend to have similar structure and behavior, defining a new DSML for the health monitoring domain can help capture common concepts. The DSML should be expressive enough to cover a wide range of health measurements such as blood pressure, heart rate, etc. Developers can use this DSML to model concepts specific to their monitoring app.

Domain analysis

To analyze the domain of health monitoring apps, we followed the feature-oriented domain analysis (FODA) methodology presented by Kang et al. (1990), which is a method for classifying features of an application by distinguishing the mandatory and optional features and their relations.

To obtain a feature model for the domain of remote health monitoring apps, we went through the following steps. First, we selected the top 20 highly ranked apps in this domain from the Google Play Store3 and the Apple Store4 and examined the concepts they support by installing and running the apps and referring to any available documentation. Table 2 shows the name, number of downloads, and satisfaction rate for the selected apps. Then, we used the research studies discussed in the related work section (see Table 1) as another source of information to uncover important concepts that may have not been implemented in existing apps. Our objective is to cover as many features as possible that would make HealMA a powerful framework for generating different types of health monitoring apps. Based on our analysis of the domain, using the apps and the research papers, we grouped the extracted concepts into 7 classes as follows.

Table 2

Selected apps for feature extraction

No.	App name	Downloads	Satisfaction rate
1	Huawei Health	+ 100 M	3.6
2	Mi fit	+ 50 M	4.6
3	Heart rate monitor	+ 1 M	4.5
4	Heart rate plus: pulse monitor	+ 1 M	4.0
5	Diabetes: M-management and blood sugar track app	+ 500 K	4.5
6	Blood pressure diary	+ 500 K	4.2
7	Blood pressure analyze	+ 100 K	4.2
8	BP journal—blood pressure diary	+ 100 K	4.8
9	Blood pressure recorder and bp diary	+ 100 K	3.9
10	Body temperature diary	+ 100 K	3.7
11	Apple health	N.A.*	–
12	Instant heart rate: HR monitor	N.A.*	4.9
13	HeartRateLite	N.A.*	4.6
14	BPMonitor	N.A.*	4.6
15	Qardio	N.A.*	4.7
16	Glucose-blood sugar tracker	N.A.*	4.7
17	Fever tracker	N.A.*	2.9
18	Glucose buddy diabetes tracker	N.A.*	4.8
19	VitalDetect App	N.A.*	5
20	Welltory	N.A.*	4.5

*No. of downloads is “not available” in app store

Figure 2 shows the resulting feature model. The importance of each feature is determined using a logical operator. The features that are marked with a solid circle (e.g., Functionality) are mandatory and must be supported by a health monitoring app. Features with an empty circle are optional (e.g., Storage). One or more sub-features that are connected by filled arcs can exist in the final app whereas an empty arc means that only one of the features should exist. Sub-features that are indicated with dashed boxes (e.g., iOS applications) are not supported by the current version of HealMA.

Fig. 2

Feature model of health monitoring domain

Data source Health tracking apps receive health data manually or automatically. In the manual way (e.g., in “Blood pressure diary”), patients themselves should measure the health parameters and enter the data into the app manually. However, some apps (e.g., “Heart Rate Puls: Pulse Monitor”) receive data from smartphone internal resources (sensors), automatically. Other apps (e.g., “Huawei Health” and “Mi Fit”) receive data from wearable devices such as smartwatches. In addition to the apps, the data could be received from an external device such as a Raspberry Pi 3 board by wireless communication mechanisms (e.g., in Swaroop et al. 2019). Also, the data could be received from storage and computational services to be visualized for the users (e.g., in Patel et al. 2011).

Platform The 20 investigated health tracking apps were developed for different platforms, e.g., Android (apps 1–10) and iOS (apps 11–20).

Storage The received health data could be stored locally on the smartphone or be stored on cloud servers. There are apps (e.g., “Qardio”) that just store the data locally, while many other apps (e.g., “HeartRateLite” and “Diabetes: M-management and blood sugar track app”) provide support for both local and cloud storage.

Functionality Applications could support different functionalities to improve self-management and supervising the patient.

Authentication (sign up and login) Most of the apps (e.g., “Glucose Buddy Diabetes Tracker”), provide authentication features to support privacy and security. Some other apps (e.g., “Heart Rate Pulse-Pulse and Heart Rate Monitor”) do not support authentication.

Profiling Getting personal information (e.g., in “Apple Health”), helps customize the app for the users by giving them better ways to manage the app features.

Analysis Simple data processing for analysis (e.g., in “Instant Heart Rate: HR Monitor”), helps to know if the health status is normal.

Alert Alerts are used in apps (e.g., “Qardio”) for reminding important tasks such as measuring health parameters and showing the measurement results. Alerts could also be used for notifying the supervisor (e.g., in Swaroop et al. 2019) of potential abnormalities and emergencies.

Advice Providing guidelines to control abnormalities (e.g., in “Diabetes: M-Management and Blood Sugar Track App”) helps manage emergencies.

Report Data visualization and report creation, in different time periods and in a user-friendly format for patients and supervisors, help track the patient health status. Some apps (e.g., “Heart Rate Monitor”) provide different types of reports for the patient, while other apps (e.g., “BP Journal-Blood pressure Diary”) create reports in different formats to be shared with the supervisor.

Learning Some apps (e.g., “Welltory”) provide information sources to inform the patient about the disease and appropriate lifestyle during the illness to increase the quality of life.

Treatment Some apps (e.g., “Diabetes: M- Management and Blood Sugar Track App”) show the process of treatment including medication, activity, and diet to be followed by the patients.

Clinical info The patient’s medical info (e.g., in Ajami and Mcheick 2018) can be combined with the measured data. This makes the analysis more accurate and this medical info is available for the supervisors.

Supervisor Most of the health tracking apps just support self-management. However, if a supervisor could be notified when abnormalities are observed (e.g., in Swaroop et al. 2019; Rhayem et al. 2017), it helps to control emergencies. The supervisor could be an organization, such as a hospital, or a person (e.g., the patient’s family members and doctors).

App domain Health monitoring apps can be used for measuring general vital signs (e.g., in Swaroop et al. 2019) or be specialized for a specific disease (e.g., “Blood Pressure Diary”).

User multiplicity The reviewed health tracking apps are used by one user (e.g., “Mi Fit”) or they are used by multiple users (e.g., “Diabetes: M-Management and Blood Sugar Track App”).

Design

We built our DSML based on the features extracted in the analysis phase. Figure 3 shows an overall view of HealMA metamodel, which consists of four main parts shown in different colors: (1) Participants (yellow); (2) Health concepts (blue); (3) Data providers (purple); (4) App functionalities (green). A more detailed view of the metamodel is presented in Fig. 17 of Appendix.

Fig. 3

Health monitoring app generation metamodel (in summary)

Fig. 17

Health monitoring app generation metamodel (in detail)

Participants refers to the roles of various participants in the health monitoring process, including patients (represented with the Patient class) whose health condition is monitored. The patient’s personal information is represented by the Profile class and a patient’s medical information is modeled using the class Medical History. We define the Supervisor role who is the participant who monitors the patient’s health condition. The supervisor can be either a person such as a physician or an organization, for example, a health care clinic.

Health concepts represent concepts related to a particular disease. Parameter list is a container that represents the different Parameters that are monitored. These include physical measurements such as blood pressure, heartbeat rate, and body temperature (represented using the Physical class) and Environmental parameters such as humidity, temperature, and AQI. The geographical location of a patient is represented using the Location class. A patient’s physical activities which are measured using step counts and acceleration are defined using the Activity class. Each parameter has an associated Units of measurement and Tags. For example, the temperature can be measured either in Celsius or Fahrenheit, which are units of measurement. Tags capture contextual information about the measurement. For example, the temperature of a patient can be taken after rest time or after doing physical exercise, etc.

However, not all physical parameters are quantifiable. For example, a headache could be something that a patient should be able to report. For such health-related physical parameters, we use the Questionnaire class, which has an association with the class Questions. These classes are used to inquire about other health conditions that cannot be captured using sensors.

Specific information about the target disease could be defined as Causes and Symptoms. If there is information that is not a symptom or cause, it could be defined using Other Info. Adding the Medication concept helps keep track of the medication taken by the patient.

The Data providers concept includes Things that are needed for data collection and communication management. Things could be either Device or Service. It means that the controlling parameters could be received from a number of devices and services. Device can be either the patient’s smartphone or an external device such as a smartwatch that pairs with the patient’s device using a Communication mechanism. In this work, we just support Bluetooth and Wi-Fi for communicating with external devices. However, it could be extended easily.

App functionalities model the app’s functionalities such as facilities for registering and logging into the app using the Signup and Login concept. The collected data can be stored in Local or Cloud storage by defining the concept of Storage Spaces. The E-Learning concept helps increase the patient’s knowledge about the disease through specific information that is added in Health concept. The Status Analyzer concept is used to define some Rules for the simple processing of the patient’s device to check parameters’ normal thresholds. The Report concept represents the different types of reports such as charts and history lists. The concepts such as User Alert, Reminder, and Supervisor Alert are used to notify the patient and supervisors in case of emergency. For example, if the collected data for a parameter violates predefined thresholds, the supervisor must be notified by a message, and the patient must receive an alert from the app. Adding the reminder concept makes it possible to add reminders for the measurement.

Implementation

We designed our metamodel using the Eclipse Modeling Framework (EMF).5 EMF is a well-known open-source modeling framework and code generation facility, used in building app generation tools (Eclipse Official Website 2021a). This framework allows defining metamodels using the domain concepts and their relationships.

Deployment

The last phase is to make the DSML available for use by deploying it. For this, we created a modeling editor and defined a set of graphical notations. This modeling tool has to be installed in Eclipse IDE. Then, the developer could model the applications using the proposed graphical notations. The created models must conform to the metamodel. Figure 4 shows the concrete syntax of the language. More details on the editor are provided in Sect. 3.2.

Fig. 4

The language concrete syntax

Graphical modeling tool

To create health monitoring app models in a user-friendly environment, we developed a graphical modeling editor using Sirius.6 Sirius is an Eclipse-based tool that allows the creation of customized modeling editors. We selected Sirius because of its flexibility in supporting a wide range of customization when defining modeling editors. The modeling editor is added to Eclipse as a plugin to make it possible to easily create models by dragging and dropping the language elements to the modeling area. The resulting models are saved in an XMI file.

As shown in Fig. 5, our modeling tool consists of three main parts: (1) Palette, (2) Canvas, and (3) Properties, as described in the following.

Fig. 5

Environment of HealMA modeling editor

Palette This part provides the language elements categorized into four categories: participants, health concepts, data providers, and app functionalities. This palette helps to learn the language faster and makes modeling easier. In addition to these four categories, there is another category with an element named Default that enables the developer to create all the necessary parts of each model (mandatory features in the feature model) in the shortest time, automatically.

Canvas To create a model, the developer adds the model elements to a canvas through a drag-and-drop mechanism. Then, the editor shows the graphical representation of the model to the developer. Each of the four main parts of the application model is indicated by the corresponding color that we used in explaining our metamodel (see Fig. 3).

Properties This part provides the attributes of each model element to be filled. After the developer adds model elements to the canvas, the required fields must be filled to complete the application model.

Constraints and validation rules

We defined many constraints and validation rules to prevent the creation of incomplete and invalid models. To this end, we added 38 AQL (Acceleo Query Language) rules to the modeling tool to catch potential faults. The faults are categorized into three levels of severity: information, warning, and error. Error messages are generated to prevent the user from creating the same elements which must be unique in the application model. Warning messages are generated to prevent important fields from being left blank. Information messages are generated to express the description needed to fill a field. As a result, during modeling, if any rule is violated, the editor shows an appropriate message based on the severity level of the rule. Table 3 shows the number of rules defined for each level, while Table 4 shows the rules with the highest severity.

Table 3

The number of rules for different severity levels

Error	Warning	Information
9	25	4

Table 4

The rules with highest severity level which causes error

No.	Rule	Target class	Usage reason
1	not(self.siblings())→collect(i|i.isdefaultuser) →includes(self.is default user)	User	To prevent defining more than one default user
2	not(self.siblings())→collect(i|i.name) →includes(self.name)	Paired device	To prevent defining the same devices
3	not(self.siblings())→collect(i|i.name) →includes(self.name)	Parameter	To prevent defining the same parameters
4	not(self.siblings())→collect(i|i.value) →includes(self.value)	Unit of measurement	To prevent defining the same units of measurement for a parameter
5	not(self.siblings())→collect(i|i.value) →includes(self.value)	Tag	To prevent defining the same tags for a parameter
6	not(self.siblings())→collect(i|i.value) →includes(self.value)	Cause	To prevent defining the same causes
7	not(self.siblings())→collect(i|i.value) →includes(self.value)	Symptom	To prevent defining the same symptoms
8	not(self.siblings())→collect(i|i.title) →includes(self.title)	Info	To prevent defining the same topics of information
9	not(self.siblings())→collect(i|i.question) →includes(self.question)	Question	To prevent defining the same questions

For example, for each instance of the class Parameter, we can issue an error message when the developer creates a parameter that already exists. Figure 6 shows different steps to define this error message and the result of validating a model against this rule. Figure 6a shows the required AQL query to prevent defining the same parameters. Figure 6b shows the customization of the message level and message text. Figure 6c shows an error message when the developer tries to define duplicate parameters. In addition to the error message, we can show an ‘information’ message to help a developer choose the type of parameters and ‘warn’ the developer when he/she forgets to enter the required fields. These messages are defined following the same process as the error message is defined.

Fig. 6

Process of defining and showing an error message to prevent creating duplicate parameters

Model-to-code transformation engine

To generate the code from the model, we developed a model-to-code engine. We used Acceleo model-to-text language (Eclipse Official Website 2021b), which is a template-based code generator tool, to create the engine. The engine includes several transformation rules that take the model as an XMI file and returns the required files for the Android app as output. The app logic code is generated in Java, and the user interface is generated in XML. In addition, the transformation rules generate comments to help developers fill some parts manually, fix errors, and complete the Android project. Listing 1 shows a code excerpt that is written in Acceleo. This template generates the required Java method to insert measured data into the corresponding table in the local database.

Architecture of HealMA-generated apps

The health monitoring apps generated by HealMA follow the Model-View-Controller (MVC) architecture pattern. As it can be seen in Fig. 7 based on the MVC architecture each app is divided into three main layers: (1) Model (2) View (3) Controller.In an Android project, activities are used for both the view and controller layers. To be more precise, the view layer consists of a combination of XML layout resources and the parts of Java activities files that update the user interface. However, the parts of the activities that update the object classes and handle the logic of the program are related to the controller layer. The Java classes from which objects are built are in the model layer (Lou et al. 2016).

Fig. 7

Architecture of health monitoring applications generated by HealMA

Model layer is responsible for storing/retrieving data in/from database and cloud storage services using object classes.

View layer is responsible for visualizing the appropriate user interface to the user based on the user command.

Controller layer is responsible for getting the user commands and updating the model layer based on the command. It is also responsible for application logic.

Development process using the proposed framework

Figure 8 shows a detailed process that developers should follow to generate an Android health monitoring app using HealMA. This process consists of the following steps.

Fig. 8

Development process of health monitoring applications using HealMA

In the Requirement Gathering step, the developer should determine the requirements of the application. However, HealMA does not provide any facility for doing this step. Therefore, this step is considered a prerequisite step.

The next step is Modeling, in which the developer should model the application using the modeling editor. The model elements can be added in three ways. They can be added by utilizing the default parts, they can be designed from scratch, or they can be created by the combination of these two approaches.

In the Automatic Code Generation step, the app code (including Java and XML files) is generated automatically by the model-to-code transformation engine.

Finally, in the Code Customization step, the developer has to transfer the generated code into the Android Studio IDE, complete the project according to the comments, and customize the project as needed.

Evaluation

In this section, we evaluate the HealMA framework using three criteria: (1) Applicability, (2) Productivity, and (3) Usability. More precisely, we answer the following research questions:To answer the first two questions, we adapted the guidelines introduced by Runeson and Höst (2009) to the current research, and implemented four case studies. The detail of this part of the evaluation is explained in Sect. 4.1. To answer the third research question, we conducted a user study to assess the usability of one of the generated apps (COVID-19 monitoring app) from the users’ perspective, following the guidelines proposed by Wohlin et al. (2012). Our usability measures are based on the ones proposed by Hussain et al. (2013) and Gharaat et al. (2021). These measures are then structured using the goal question metric (GQM) approach (Basili et al. 1994). The detail of this part of the evaluation is explained in Sect. 4.2.

RQ1 (Applicability): Can we use HealMA to generate different Android-based health monitoring applications?

RQ2 (Productivity): Does HealMA increase the productivity of developers?

RQ3 (Usability): How usable are the apps generated by HealMA?

Case studies

In the following sections, we address the first two research questions: RQ1 and RQ2.

RQ1 (Applicability): Can we use HealMA to generate different Android-based health monitoring applications?

To answer this question, we present four case studies in which we use HealMA to automatically generate four different monitoring apps for the following diseases: (1) Chronic Obstructive Pulmonary Disease (COPD), (2) High Blood Pressure, (3) COVID-19, and (4) Diabetes. To show how HealMA can be used to generate a monitoring app, we explain the details of the development process for the first case study. The same approach was followed for the other three case studies.

COPD monitoring COPD is a chronic disease that makes breathing difficult (World Health Organization Official Website 2020b). Despite its progressive nature, it could be managed and controlled. Early diagnosis, continuous monitoring, and reducing risk factors can help patients control COPD (Vogelmeier et al. 2017). This disease can be caused by tobacco smoking, indoor and outdoor air pollution, occupational dust, respiratory infections, chemicals, and so on. The symptoms can be dyspnea, chronic cough, shortness of breath, sputum production, wheezing, and chest tightness (Vogelmeier et al. 2017; Harris 2019). A set of environmental parameters such as temperature, humidity, and rising levels of some pollutants (e.g., CO, PM2.5, and PM10) exacerbate COPD. Such exacerbation can be detected by monitoring physical parameters such as heartbeat rate, blood pressure, body temperature, respiration rate, and blood oxygen level (Ajami and Mcheick 2018; Tomasic et al. 2018; de Miguel-Díez et al. 2019). These parameters should be monitored continuously in the case of COPD.

Based on the development process described in Sect. 3.6, to generate a COPD monitoring mobile app by HealMA, we follow the following steps.

Step 1 In the first step, we defined the requirements for the COPD monitoring app. Figure 9 shows the requirements of this app as a use case diagram.

Fig. 9

Requirements of the COPD monitoring app

Step 2 We used the HealMA modeling editor to design the COPD model. Then, we applied the validation rules to correct and complete the model. Figure 10 shows the application model for the COPD monitoring app.

Fig. 10

COPD application model

Step 3 After the model is completed, with the help of the transformation engine, the XML and Java files of the application are generated automatically.

Figure 11 shows the generated packages based on the MVC architecture. The controller package consists of several sub-packages. The adapter package consists of adapter classes that act as a bridge between the model layer and the view layer. The alarm notification handler consists of classes that make it possible to add the alarm and notification in the app. The communication handler is responsible for handling the network communications. The Bluetooth/Wi-fi handler is used to receive health data from external devices. The public services handlers contain classes to receive data from public services such as services providing air quality index. The server storage handler consists of classes that are responsible for communicating with the storage cloud server. The computational services package implements services for mathematical and logical operations to check the patient health status. The database handler consists of the classes that are responsible for storing/retrieving on/from the SQLite database. Finally, the send SMS handler package contains a class to send SMS to observers.

Fig. 11

Generated packages for the COPD monitoring application

The model package consists of Java classes to create the objects for handling the logic of the program.

The presentation package consists of activities and layouts. The Activities are Java classes that are responsible for both updating the user interface and some tasks which are related to the controller layer. The layouts package are XML layout resources for the user interface.

There is one more package that includes the required manifest file of the project.

step 4 We opened the generated code as an Android project in Android Studio. Then, we completed the project by addressing the comments that are generated by HealMA. Finally, we generated the APK file for the COPD monitoring app. The COPD monitoring app APK file is available at this address.7

Figure 12 shows different pages of the generated COPD monitoring app. Figure 12a shows three main parts of the app including the signup and login page, dashboard, and drawer. After the user signs up and logs into the app, he/she should use the drawer to fill out the profile, medical history, and supervisor information. Then, he/she can use other parts of the app. Figure 12b shows the measurement page, which is the most important part of the app. After the user device is paired to the external devices, it can receive the measured data, check the thresholds, and return the result to the user. To test the storage and retrieval of the data on the cloud, we developed a local PHP server. Also, to test Bluetooth and Wi-Fi communications, we developed an Android app that sends data to the generated COPD monitoring application via Bluetooth and Wi-Fi. Then, as depicted in Fig. 12c, the stored data can be shown to the user and can also be sent to the supervisor as a report. The user can obtain information about COPD and improve his/her knowledge as shown in Fig. 12d, and can also define his/her medications in pages depicted in Fig. 12e. Additionally, the user has the option to set a reminder for the measurement time or other important times in the reminder part which is shown in Fig. 12f.

Fig. 12

The screenshots of COPD monitoring app: a main pages b measurements c reports d learning about disease e medication storage f reminder

Blood pressure monitoring Blood pressure is measured as the blood circulates from the heart to other parts of the body through the vessels. Blood pressure rises and falls during the day. However, if it stays too high for a long time, it is called hypertension and raises the risk of heart, brain, and kidney problems. This condition is the main reason for premature death worldwide (CDC Official Website 2020; WHO Official Website 2020a). Recently, many applications have been developed to monitor hypertension. We used existing apps to collect requirements about blood pressure monitoring. More specially, we chose three most popular blood pressure monitoring apps from Google Play as a reference, which are shown in Table 5 along with their number of downloads and ratings. We aggregated the functionalities supported by these apps and added other requirements such as automatic data recording and alerts to come up with a full set of features for the HealMA-generated app.

Table 5

Functionalities for blood pressure monitoring app

App name	Blood pressure	Blood pressure tracker and bp diary	Blood pressure tracker	Our app
Downloads	10M+	1M+	500k+	–
App functions↓ rate→	4.2	4.1	4.6	–
Profile	◯	◯	◯	∙
Data recording
Manual	∙	∙	∙	∙
Automatic	◯	◯	◯	∙
Storage place
Local	∙	∙	∙	∙
Cloud	∙	◯	∙	∙
Data visualization
History list	∙	∙	∙	∙
Charts	∙	∙	∙	∙
Supervisor notification
Report	∙	◯	∙	∙
Alert	◯	◯	◯	∙
Reminder	∙	◯	◯	∙
Learning about disease	◯	∙	◯	∙

Supported Not supported

Following the same process as for the COPD app, we generated the blood pressure app simply by dragging and dropping the relevant model elements using the HealMA modeling editor. Figure 13 shows the main screenshots of the HealMA-generated Blood Pressure monitoring app. The app APK file is available at this address.8

Fig. 13

The screenshots of blood pressure monitoring app

COVID-19 monitoring COVID-19 is a new infectious disease that mainly causes respiratory problems. Fever, dry cough, and tiredness are the most common symptoms of COVID-19, and based on the latest research, factors such as age, gender, heartbeat rate, respiratory rate, oxygen saturation, and chronic kidney problems affect the COVID-19 mortality rate (WHO Official Website 2020b; Rechtman et al. 2020). However, due to the infectious nature of COVID-19, direct nursing of patients and controlling such factors is dangerous for the patient’s family members and the medical staff. Remote monitoring not only helps supervisors to be safer but also provides stored data for researchers to study the disease. Due to the fact that at the time of writing this paper, there is no well-known COVID monitoring app available on the Google play store, we relied on the research articles to extract the features and functionalities of such an app.

Figure 14 shows some screenshots of the COVID-19 monitoring app generated using HealMA. It should be noted that this app is generated following the same process as the previous case studies. The app APK file is available at this address.9

Fig. 14

The screenshots of COVID-19 monitoring app

Diabetes monitoring Insulin is a hormone that moves the sugar (glucose) from the blood to body cells to be used as energy. Diabetes occurs when the body is unable to produce or use insulin properly (CDC Official Website 2021a). There are three types of diabetes, type 1, type 2, and gestational. However, type 2 diabetes is the most common. Continuous controlling of some physical parameters such as blood glucose, blood pressure, and cholesterol besides improving the lifestyle by quitting smoking, controlling the weight, and healthy eating help to manage type 2 diabetes (CDC Official Website 2021b). Health monitoring apps can be helpful by providing facilities for the mentioned guidelines. To develop an application to help people with type 2 diabetes, we selected three diabetes tracking apps with a high number of downloads from the Google play store, and considered their main functionalities as the requirements of our application. Table 6 shows the apps and their number of downloads, ratings, features, and the features we considered for our app. Figure 15 shows some screenshots of the Diabetes monitoring app generated using HealMA. The app APK file is available at this address.10

Table 6

Functionalities for diabetes monitoring app

App name	Diabetes diary-blood glucose tracker	Blood sugar log-diabetes tracker	Blood sugar tracker: diabetes test glucose logger	Our app
Downloads	100k+	100k+	100k+	–
App functions↓ Rate	4.6	4.5	4.6	–
Sign up and log in	◯	◯	◯	∙
profile	◯	◯	∙	∙
Medical history	◯	◯	◯	∙
Data recording
Manual	∙	∙	∙	∙
Storage place
Local	∙	∙	∙	∙
Data visualization
History list	◯	◯	∙	∙
Charts	∙	∙	∙	∙
Supervisor notifications
Report	◯	∙	◯	∙
Alert	◯	◯	◯	∙
Reminder	∙	∙	∙	∙
Learning about disease	◯	◯	◯	∙
Medication	∙	∙	◯	∙

Supported Not supported

Fig. 15

The screenshots of diabetes monitoring app

We believe that the four apps that were generated using the HealMA framework demonstrate the applicability of HealMA to generate different health monitoring apps for various domains. This results in the ‘yes’ answer to our first research question, RQ1.

RQ2 (Productivity): Does HealMA increase the productivity of developers?

To answer the second research question, we compared the “number of automatically generated lines of code” with the “manually added lines” for each case study. Table 7 shows the numbers, and Fig. 16 shows the percentage of these numbers. As we can see, in all cases, more than 90% of the code is automatically generated, and this shows that HealMA helps developers build the apps in a more efficient manner.

Table 7

Automatically generated code versus manually added code for each case study

Case study	Automatically generated code		Manually added code		Total
	Java	XML	Java	XML
COPD	6438	3107	350	272	10,167
Blood pressure	2110	1261	58	13	3442
COVID-19	2699	1584	43	24	4350
Diabetes	4838	2291	205	186	7520

Fig. 16

The percentage of automatically generated code versus manually added code for four case studies

In addition, to compare the development time when using HealMA compared to creating the apps from scratch (i.e., following a pure code-centric approach), we used the heuristic presented by Kung (2013) which claims that an average developer can write 100 lines of code (LoC) per day. Based on this heuristic, we compared the time it takes to develop each of the apps from scratch, with the time of developing the same apps using HealMA. As it is shown in Eq. 1, to obtain the time for the code-centric method, the total number of LoC for each project should be divided by 100. However, when HealMA is used for development, as it is shown in Eq. 2 the modeling time will be added to the time needed for manual LoC added to complete the project. Table 8 shows the results.

Table 8

Comparison between the time of automatic implementation by HealMA and manual implementation for each case study

Case study	Manual implementation (Days)	Automatic implementation by HealMA
		Modeling (minutes)	Completing and customization (days)
COPD	101	120	~ 7
Blood pressure	34	30	~ 1
COVID-19	43	40	~ 1
Diabetes	75	60	~ 4

To summarize, as depicted in Fig. 16, at least 92% of XML code and 95% of Java code is generated automatically for each case study. Based on these results, we conjecture that HealMA increases productivity during development, which results in the ‘yes’ answer to RQ2.

RQ3 (Usability): How usable are the apps generated by HealMA?

To evaluate the usability of the apps generated by HealMA, we selected one of the apps that was generated using our framework (COVID-19 Monitoring app), and conducted a user study following the guidelines provided by Wohlin et al. (2012), ISO 9241-11 quality model (ISO Official Website 2020), and measures proposed by Hussain et al. (2013) and Gharaat et al. (2021). The user study consists of three steps: (1) Scoping and planning, (2) Operation, and (3) Discussion. In the first step, we defined the goal, set up the experiment, and chose the participants. In the second step, we conducted an online questionnaire with the participants. Then, in the third step, we discussed the results achieved from the questionnaire. These three steps are explained in more detail in the following sections.

Scoping and planning

According to ISO 9241-11 (ISO Official Website 2020), usability is considered as user-friendliness and ease of use for the users. Therefore, end-users (COVID-19 patients) should be satisfied with the generated app. In order to define the goals, we followed the GQM approach (Basili et al. 1994). This approach helps find the factors that may have an effect on usability and define a set of questions to make usability more quantifiable. We adapted the goals defined by Hussain et al. (2013), by focusing on simplicity, accuracy, time taken, and attractiveness as the goals of the study. Then we set up a questionnaire with 12 questions to evaluate these goals. The answer to each question has to be selected amongst these options: ‘very little’, ‘little’, ‘moderate’, ‘much’, and ‘very much’. Then, to evaluate the goals, we asked 20 participants to answer the questionnaire. The participants have been selected from people who experienced COVID-19, either themselves or their close family members. They were of different age groups from 15 to 50 and had different education levels.

Operation

The experiment was conducted online because of the current pandemic. We provided the COVID-19 monitoring app to participants, which is generated as the third case study. Then, we asked the participants to install the app and use it. After that, we asked them to fill out the online questionnaire to evaluate the usability of the app. Table 9 shows the questions and the extracted results from the answers.

Table 9

Questionnaire results

Measure	Goal	Question	Answer
			1 (%)	2 (%)	3 (%)	4 (%)	5 (%)
Effectiveness	Simplicity	How simple is the installation process of the app?	0	0	5	5	90
		How simple is it to learn the app functionalities?	0	0	0	50	50
		How simple is it to use the app?	0	0	5	50	45
	Accuracy	How accurate are the results provided by the app about health status?	0	0	5	50	45
		Is the app able to prevent errors and guide users with appropriate messages?	0	15	15	35	35
		Is the app able to complete given tasks successfully?	0	0	0	50	50
Efficiency	Time taken	Does the app respond in a reasonable time?	0	0	0	80	20
		Does the app complete the given tasks in a reasonable time?	0	0	5	5	90
		Does the app take a reasonable time for monitoring the user’s health status?	0	0	10	45	45
Satisfaction	Attractiveness	How pleasant is the UI of the app?	0	0	10	40	50
		How satisfied is the user with colors, font size, and icons in the app?	0	0	5	20	75
		Does the user enjoy working with the UI of the app?	0	0	10	30	60

1 = Very little, 2 = Little, 3 = Moderate, 4 = Much, 5 = Very much

Discussion

As mentioned earlier, the answers to each question vary from ‘very little’ to ‘very much’. If the ‘very much’ and ‘much’ answers are considered as the users’ satisfaction, in general, users’ satisfaction varied between 70 and 100% for each question. To achieve user satisfaction for each goal, i.e, Simplicity, Accuracy, Time taken, and Attractiveness, we averaged the user satisfaction for the questions of that goal. Table 10 shows the general user satisfaction for the goals. It can be seen that 96.6% of users believed that working with the COVID-19 monitoring app is easy and 88% of them considered it Accurate. 95% were satisfied with the response time, and 91.6% of them believed that the COVID-19 monitoring app is attractive.

Table 10

User satisfaction for each goal

Goal	Satisfaction percent (%)
Simplicity	96.6
Accuracy	88
Time taken	95
Attractiveness	91.6

The results show that the COVID-19 monitoring app is considered usable by the users, which answers RQ3.

Threats to validity

In this section, based on Runeson and Höst (2009) we describe the threats to validity.

Construct validity

Construct threats refer to differences between theoretical assumptions and the results observed. We evaluated the framework from different perspectives based on well-known methods. To evaluate the applicability of HealMA, we implemented four case studies with different requirements. We measured the development time for each case study to measure productivity. The results for measuring productivity may be different by changing the implemented cases.

Internal validity

Internal threats refer to factors that affect the evaluation and change the results. Automatic code generation reduces the need for programming skills and development time. However, different programming styles may increase the time to customize the code, which in turn can affect the development time. To mitigate this threat, an effort was made to generate code that is easy to understand with added comments to help developers complete the project.

External validity

External threats refer to factors that prevent generalizing the findings and results. To mitigate this threat, we generated four different apps that cover various health monitoring aspects.

Reliability validity

Reliability threats refer to the dependence of the results on the researchers. In this research, for the evaluation of applicability, we analyzed the health monitoring app domain by reviewing several applications and academic studies and designed the language based on the common features. However, we may have missed some studies and apps. Therefore, all the features in health monitoring applications may not be implemented in the current version of HealMA. On the other hand, for the evaluation of usability, the sample size is not large enough. To mitigate this threat, we chose people from different age groups with various education levels.

Limitations

In this section, we discuss the potential limitations of the HealMA framework and the apps generated using HealMA.

Limitations of HealMA

As we stated in Sect. 3.1.2, we relied on the analysis of several apps and academic research work and extract the main concepts of the remote health monitoring domain. These concepts form the foundations on which HealMA metamodel is built. However, we can not claim that HealMA can generate any health monitoring mobile app. It is only limited to the generation of apps with the features defined in the HealMA metamodel. To support additional concepts, we need to extend the HealMA metamodel, which will result in changing other parts of the framework, i.e., the modeling editor, validation rules, and code generator. This said, we believe that the current version of HealMA covers a wide range of standard features for creating useful health monitoring apps.

Limitations of the apps generated by HealMA

The monitoring apps generated by the current version of HealMA have the same UI design, and there is no support for UI customization in the modeling step. The only way to modify the UI is to change the generated code itself, which may create inconsistencies with the models created using HealMA DSML. To support UI customization at the modeling level, we need to improve the DSML. This will require a good understanding of UI design concepts.

Conclusion and future work

In this paper, we presented HealMA, a model-driven engineering framework for generating Android-based remote health monitoring apps. HealMA consists of a domain-specific modeling language, a modeling editor, validation constraints, and a model-to-code transformation engine, all packaged in an Eclipse plugin. The modeling language includes the main concepts of the IoT-based health monitoring apps as well as the relationships between them. The modeling editor makes modeling easier. It includes some predefined AQL rules to avoid creating wrong and incomplete models. The model-to-code transformation engine takes the designed model of the app as input and returns the generated XML and Java code of the app as output, which then is imported to the corresponding Android project for generating the APK of the app.

We evaluated HealMA from three different perspectives: applicability, productivity, and usability. To show that HealMA is applicable, we implemented four different case studies. Then, we compared the development time when we used HealMA to a code-centric approach. We also evaluated the usability of HealMA-generated apps by conducting an experiment and asking 20 participants to provide their feedback through a questionnaire. The results of the evaluations showed both the applicability and usefulness of the HealMA framework.

In the future, we plan to extend HealMA with a focus on a wider range of diseases, communication methods, protocols, and standards. We also intend to add a set of transformations to our engine to generate iOS applications too. Then, we want to conduct more studies to assess the effectiveness and usability of HealMA.