Original Article
Biochem Ind J, Volume: 11( 2)

Software Product Lines for Mobile Patient Monitoring Systems Using FODA a Grammar

Paliwal G Department of Computer Engineering, R C Patel Institute of Technology (RCPIT), Shirpur 425405, Dist Dhule (MS), India
Tel: 9970206604; E-mail: [email protected]

Received: February 8, 2017 Accepted: February 23, 2017 Published: February 28, 2017

Citation: Paliwal G, Bunglowala A.Software Product Lines for Mobile Patient Monitoring Systems Using FoDA a Grammar. Biochem Ind J. 2017;11(2):112.


A common Architectural design, for a diverse set of components is not a trivial task. It involves preparation for mass customization, focusing first on what is common to all products, and then in what is different. Components must be engendered for being reused by all, or most of the possible configurations. These components can be developed from scratch or derived from other platforms. This flexible design sanctions to reuse these components with different configurations for a particular solution to provide a mass customized set of well-defined products. Product Line (PL) engineering aims to fortify engenderment of wide range of customized products with flexible design. Variability design is about incorporating components that represents the range of possible configurations for a product in the PL. This variability, is defined during the domain engineering process. When we utilize the term variability we are referencing to the capability that something has to change in time, which makes it categorically appropriate for the domain of Mobile Patient Monitoring Systems (MPMs) where we require a wide range of mass customized product for different group of chronically ill patients. In this paper we have derived the Product Lines for the domain of MPMs utilizing the fodaA grammar.


Mobile patient monitoring system; Software product lines; Domain modeling; FodaA grammar; Context analysis; Feature analysis


Information and communication technology (ICT) is one of the fastest growing technologies in the world. Mobile Health (mHealth) basically denotes adoption of these (smartphones and other hand held devices) contrivances to improve to the patient monitoring services [1]. It is primarily adopted to provide efficient, economical and easily accessible health care solutions. Adoption of ICT for MPMs will benefit millions of chronically ill patient and it will provide an effective substitute for traditional patient monitoring practices.

Numerous MPMs have been designed earlier that offers a diverse range of functional and non-functional features. In this paper, we have provided PL for MPMs that basically captures the commonalities and variability’s of these systems. PL is a software design approach particularly developed for progressive domains to achieve a higher degree of reuse and customization within the budget and time limits. The elementary of a PL is an amassment of features, termed as the scope and an accumulation of reusable components known as the core assets [2].

The elementary unit of a production line is called feature. A feature can be a particular module, the utilization of a categorical technology, and in general any reusable functional component. The relationships between features in a PL builds product configurations and relationships and that features set is called feature model. The feature analysis output can be further used to explore reusable components for PL development.

Generic Architecture for MPMs

The generic architecture for MPMs [3] comprises systematic development processes for various MPM product variants. From the product perspective, the generic architecture for MPMs has two components, namely, Body area network (BAN) and back end system (BESys) as shown in (Figure 1). From product perspective BAN, can be defined as a grid of different communication devices worn on or around the body for acquiring the physiological data. The data is then transferred to mobile health service providers using different communication devices. The BESys comprises of a mobile base unit (MBU) which initially processes the data and then transfer it to back-end server. Data is then further processed by the back-end system using different health care application.

From the process viewpoint, BAN acquires the physiological data actively and passively by interacting with the patient. Data is then bundled for delivery to the caregivers and third parties applications through different communication Medias. Healthcare workers and/or algorithms interpret and review the data and evaluate if there are any areas for concern. From process perspective we can define the MPM architecture in five steps:


Figure 1: A Generic architecture for mobile patient monitoring system [3].

I. Data acquisition

II. Initial Data Processing and Transmission

III. Bio signal Interpretation and Processing

IV. Notification and

V. Intervention

This separation amongst process and product perception helps system designers to independently focus on functional and structural elements of MPMs facilitating systematic development of these systems.

Feature Analysis for Mobile Patient Monitoring Systems

Feature Oriented Domain Analysis (FODA) is a method of requirements analysis which defines both the products and the processes of domain analysis. In FODA, a feature is a prominent or distinctive user-visible aspect, a quality, or a characteristic which can be recognized as mandatory, optional or alternative property for a system [4,5,20].

Feature models were first introduced as part of the FODA method by Kang et al. [4]. FODA is a methodology originated from the study of different approaches of domain analysis. It gives a view of the requirements and architecture aspects over the assets to be built [6]. This methodology focuses on the identification of product features in a well-defined domain [5]. Moreover, the commonalities and variabilities of these features must be specified. Also, this model allows to graphically represent features and their relationships, in order to define products in a PL. The graphical structure of a FODA model is presented by a FODA Diagram. A FODA Diagram is fundamentally a graph, which is an intuitive and easy way to represent relevant information about features [7]. It represent PL features as nodes and arcs represents relationships among these features.

(Figure 2) shows the feature diagram of MPMs in three levels. The level 1 of the diagram shows the components and functional features present in the system. The second level of the diagram comprises of features that are expected to be delivered by respective components and selected features has been further extended in the third level. The optional features are represented by a white circle at the end of the connector and the mandatory features are represented by a black circle at the end of the connector whereas the alternative features are represented by an arc on the connectors.


Figure 2: Feature diagram for MPMs.

The fundamental features required for MPMs are biosignal delivery and biosignal processing. Since these features are not sufficient for proactive usability we have included certain features which are not essential for the system but we have treated them as necessary features to improve the performance and accessibility of these systems. Some of these selected features are elaborated below:

• Genericity: The system should be available to a wide variety of patients, community or group of persons. It should be modified according to the patient monitoring requirements. We have introduced generosity with the help of generic architecture [3,6]. By following these architecture we can modify system functionalities and sensors according to the needs.

• Intelligence: System should provide assistance to the physician/Doctor/Caregiver in understanding the physiological data, decision making and mechanizing the monitoring process through data management systems [7-9] and artificial intelligence. The system should be capable of data extraction, data interpretation and effectively encapsulating the actual context aware information to ensure the correct data delivery every time. Clustering algorithm technics for predicting current health status [10] of a patient have been proposed to support these type of functionalities.

• Unique patient identification: Patient should be globally uniquely identified with a patient ID. The most promising choice for the feature is RFID [11] tags; in addition to unique identity to a patient it also provide solution for patient tracking and security issues.

• Availability and Speed: The System should be capable of processing tones of data in real time and should be available 24*7. Cloud servers are the most viable options due to its theoretically unlimited processing power and it can also ensure the availability of the system.

• Data delivery: For these type of systems accurate biosignal data delivery is very important since clinical decision making can be affected with a minor amendment. Looking at the Goodput requirements and availability 3G/4G connections are most viable options to fulfill the requirements.

• Multi-touch support: Medical images needs to be interpreted in more than one dimension for clinical decision making called as multimodal analysis. For multimodal analysis devices must have multi touch support feature.

• Biosensors: Biosignals are acquired using different type of biosensors. The biosensors deployed in MPMs should be accurate, easily wearable, power efficient and, small in size.

• Medicine infusion capability: The ability of medicine infusion is very important for cardiac, diabetic [14], and asthmatic patients. It can improve the emergency response time and quality of scheduled medications by mechanically triggered infusion.

Translation rules for FODA diagram to FODA language

Using the classical Process Algebras notations, we can translate any FODA diagram into a FODA a formal language. This approach was defined by Carlos Camacho [15-17] using Process Algebras as basis to build a formal representation of FODA graphics, which in the first place, lacks of a formal representation. Let us note, that FODA methodology was originated from a study of different approaches of domain analysis. It provides an assessment of the requirements and architectural aspects of the assets to be constructed [18-22]. In particular, FODA can represent different relations between features belonging to a PL [23,24]. These relations are: optional, mandatory, choose 1, and parallel. It also represents requires and excludes constraints. This section describes the steps of FODA formalization methodology consists of representation and translation from FODA diagrams to fodaA terms in Table 1 and translation from FODA Diagrams into fodaA grammar in Table 2.

Type FODA Diagram fodaA term
Choose 1

Table 1. FODA diagram to FodaA term [15].

Sr. No. FODA Diagram fodaA grammar

Table 2. FODA diagram to fodaA grammar [15].

Deriving the product lines from feature mode

In Product Line software development methodology, we consider all phases of production life-cycle of the system development process [21]. PLs are established with a purpose to describe experience of system builders in the areas of data management, requirements, human-computer interactions, procedure, testing, design procedures and validation of a product [19,22].

In this section, we describe PLs for the MPMs using fodaA grammar. Here we are demonstrating product variability observed in MPMs using Extended Modal Transition Systems [15,16].

In the product lines from PL1 to PL9, feature are identified using a feature identifiers. Mandatory and optional feature are represented by respectively. Conjunction and choose-one operations are represented by ∧ and γ respectively. In the design process of different variant of MPMs the variability’s exhibited through these PLs will play an important role.

Conclusion and Future Directions

The techniques developed in the field of mobile communication can be effectively used for MPMs. However, development of these systems carries the challenge of varied requirements. For successful development of mobile patient monitoring systems and to overcome the various challenges we suggest adoption of product line approach for the development of these systems. Millions of chronically ill patients will get better healthcare services at reduced cost with the successful development and deployment of MPM systems. The MPMs have both, potential and capability to change the face of customary patient care but some issues like patient privacy and system security still requires the attention. To accomplish a better response from the end user user-friendliness is another area of MPMs which should be improved. We have considered almost every technical issue but non-technical issues such as economical, managerial, and legal, that we have not included in this paper should also be taken into account for end user deployment of these systems.