Variabilities as First-Class Elements in Product Line Architectures of Homecare Systems

Transcription

1 Variabilities as First-Class Elements in Product Line Architectures of Homecare Systems Sergio T. Carvalho, Leonardo Murta, Orlando Loques Instituto de Computação - Universidade Federal Fluminense, Niterói, Brazil Instituto de Informática - Universidade Federal de Goiás, Goiânia, Brazil {scarvalho, leomurta, loques}@ic.uff.br Abstract A homecare system should adapt to changes regarding the patient needs and to variations in the residential environment. This requires a software architecture designed to support customizations before the deployment (static variability) and changes during the system operation (dynamic variability). We present a comprehensive approach in which both kinds of variabilities are seamless described by means of contracts, which are first-class elements associated with a Product Line architecture. To demonstrate the proposed approach, we present a dynamic contract developed to support a context-aware patient reminder application. Keywords-homecare systems; SPL architecture; static variability; dynamic variability; software architecture. I. INTRODUCTION The number of elderly individuals has increased considerably in the last years, putting an enormous pressure on the health care infrastructure. Home health care service is recognized as one of the ways to reduce the overloaded hospital system. In this situation, the use of remote monitoring technologies can contribute to provide better health care services. Through the use of sensors embedded in the home environment, the patient can be continuously monitored and in every part of the residence. Physiological data, such as blood pressure and heart rate, activities performed by the patient, such as walking, sleeping, and exercising, and environmental conditions, such as temperature and humidity, can be collected continuously. Caregivers, nurses, and physicians have the opportunity to monitor, by means of the telemonitoring service, the patients daily activities and adjust his/her care plan based on the treatment progress. For the patient, this can mean a smaller number of visits to the doctor and shorter periods of hospitalization. Such context introduces challenges in the design and evolution of the software architecture of homecare systems. There are issues related to the patient needs and preferences, which may change according to the health problems evolution. For example, hypertension can evolve to cardiac insufficiency, requiring a new appropriate physiological sensor, and new software resources. Additionally, such systems depend on the quality and availability of resources (e.g., sensors, devices), since they can be added, removed, or can simply fail. These changes regarding the patient needs or variations in environment require responses in terms of architectural reconfigurations. Besides allowing customizations before the deployment (static variability), the architecture should also allow changes at runtime (dynamic variability). The adoption of a Software Product Line (SPL) approach represents a potential solution, once it has proven to be an efficient way to deal with varying user needs and resource constraints [1]. When defining a product line, an architecture (called SPL architecture) should be described to capture the variabilities, i.e., the differences among the products that exist in the SPL. In the case of homecare systems, static variabilities, resolved before the deployment of a product, and dynamic variabilities, resolved just when the product is executing, should be described in a highly customizable SPL architecture. This paper is concerned with how to describe both kinds of variabilities at the SPL architecture level. Several works deal with description of static variabilities [2], [3], [4], [5]. They usually describe variabilities as variation points, included in the SPL architecture, and associated to constraint expressions. This approach may hinder the independent evolution of the variabilities and the architecture. Dynamic variabilities approaches, in turn, are mostly present in the context of Dynamic SPLs (DSPL) [6], [7], [8], [9], [1], which are SPLs aimed at adaptive systems [10]. In general, they make it difficult to describe the dynamic variabilities and their architectural adaptation in an independent way. In other words, when the architecture and the dynamic variability aspects are tangled, they have their life cycle bound to each other, forcing a co-evolution when one of them evolves. In addition, they usually adopt techniques based on feature concepts [11], differently from the above-mentioned static variabilities approaches, which use architectural models. Current approaches therefore lack a comprehensive manner to describe static and dynamic variabilities at the SPL architecture level. This paper presents a comprehensive approach for static and dynamic variabilities description. Variabilities are described as contracts, where services are defined to support architectural adaptations. Contracts are associated with the SPL architecture description of the homecare system, and define both kinds of variabilities at a higher level of abstraction. Our approach differs from the usual approaches mainly

2 by treating variabilities and their adaptations as a firstclass concern, encapsulated into contracts described at the architectural level. This brings benefits in terms of separation of concerns and maintainability, facilitating the evolution. The paper is organized as follows. Section II describes some SPL architecture concepts, which are important for the contextualization of this work. Section III describes an overview of the homecare system, highlighting the existing adaptation requirements. Section IV presents the proposed approach and Section V presents a dynamic contract developed to demonstrate our approach. Section VI mentions related work. Finally, Section VII presents some final considerations and future works. II. SOFTWARE PRODUCT LINE ARCHITECTURE Our work deals with SPL architecture, which involves concepts of software architecture. A software architecture can be defined as a set of components, a set of connectors (interconnections among the components), and the organization of these elements (configuration) for a given software system [12]; also, the specification of the system architectural elements can be made through an Architecture Description Language (ADL). In our view, unlike the architecture designed for individual systems, the software architecture of a product line (SPL architecture) should represent the architectural elements (components and connectors) corresponding to commonalities and variabilities, providing abstractions to represent the structure and behavior of products. Thus, a specific product architecture can be derived (created) from the SPL architecture description, incorporating mandatory elements (commonalities) and selecting elements related to variabilities that should be present. Variabilities are typically described via variation points. A variation point is a place in the SPL architecture where differences exist among specific product architectures. Most of the ADL that support description of SPL architectures allow to describe a variation point as constraint expressions (Boolean guards, switches, etc.), which are attached to the architectural elements. Figure 1 shows a portion of the SPL architecture for the homecare system. There are two mandatory elements belonging to all product architectures: Decision Module, capable of identifying the patient s health situation, and Alarm, which should report alarms to a supervisory center. There are also one variant element (Sensor) composed of two optional elements: Blood Pressure and Heart Rate. In addition, but not shown, Boolean guards representing variation points are described and attached to each optional element. For example, the Blood Pressure element has the following guard condition: Careplan.healthProblem = hypertension denoting that the Blood Pressure element should be selected for a product architecture that is being customized to a hypertensive patient. Figure 1. Example of a SPL architecture. Components are represented by rectangles and connectors are represented by ellipses. Dashed elements correspond to optional and the others correspond to mandatory. The above example shows the variability being resolved before runtime (static variability). This means that the elements of the architecture are immutably bound and during the creation of a product architecture. By contrast, there are SPLs in which the architecture supports variabilities at runtime (dynamic variabilities) in order to adapt to changing requirements [10]. Sometimes called Dynamic SPLs (DSPL), they integrate concepts of SPL and adaptive systems, where the products of a DSPL can be reconfigured at runtime [13]. In the next section, we present some scenarios involving dynamic variabilities in the context of a homecare system. III. HOMECARE SYSTEM During our research we have developed a homecare system [14], [15]. Once this kind of system requires a high degree of adaptability [16], [17], we introduce it to motivate the problem of describing static and dynamic variabilities in SPL architectures. A. Overview of the System In the homecare system (Figure 2), a Home Health Station (HHS), situated at the patient residence, is provided for collecting and processing information from sensors. The overall architecture also includes a Supervisory Medical Facility (SMF), used to remotely monitor a large number of patients, and interfaces for use by doctors, caregivers, and relatives of the patients. In this scenario, the relevant physiological, behavioral and environmental data should be collected and interpreted in real-time. Figure 2. Homecare system: an overview. At the HHS, the collected data is represented by fuzzy variables and analyzed using artificial intelligence tech-

3 niques [14], [15]. The eventual identification of an abnormal patient condition may activate a local device (a TV, for example), increase the frequency of monitoring, or, depending on the condition severity, send an alarm to the SMF. Contextaware techniques are employed to provide access to context information, and perform the activity of discovering and monitoring resources (e.g., sensors, devices) [18]. A care plan guides the patient regarding measurements that must be done (e.g., blood pressure), medications that should be taken, and other personalized recommendations according to the treatment [16], [18]. B. Variabilities of the System In general, current homecare systems have been proposed without taking into account differences among patients [17]. Conversely, our system enables customization through the use of SPL technology, in terms of both the patient and the residence (layout of the residence, distribution and type of the sensors and devices, etc.). Consider a custom product to be deployed for a patient in his/her residence. The derivation process can select, in principle, a set of medical specialized devices for a particular disease and an appropriate set of sensors to gather relevant physiological and context data. Once selected the static variabilities, a product architecture is derived from the SPL architecture and deployed into the patient s home. The product architecture is therefore fully attached to the needs of that patient and his/her home characteristics at that point in time. In such case, if the patient s health problems change (e.g., from hypertension to cardiac insufficiency) or even if new devices are added to his/her residence, a new version of the product must be derived and deployed. On the other hand, depending on the patient needs monitoring, the delay involved in this static assessment and the perception of the need for a new deployment could result in serious consequences to the patient s health. Changes in the patient s health situation during the system operation may induce modifications in pre-configured resources (e.g., medical sensors) or in the care plan, requiring the reconfiguration of the product architecture at runtime. The care plan, a key element of the system, can interact with a notifier to remind the patient of some event or to send a message to the doctor. This feature is interesting to increase the patient s treatment adherence, warning him or her of daily tasks such as taking a medication, or remembering that it is time to measure the blood pressure. The warning messages to the patient should be shown in one or more display devices such as TV, cellular phone, tablet, PC, display of the HHS, etc. The decision of which display device to be used influences the derivation process of a product, and depends on the patient requirements and the available display devices in the residence. For example, if a patient has a TV at home, it could be selected and bound at deployment time to the product. Otherwise, if a patient has different devices available at home (e.g., TV, tablet, PC), they could be selected and bound at runtime. Context rules should be defined at deployment time to support this selection. An example of rule can be select at runtime the device that is closest to the patient and that is his/her favorite. Therefore, in terms of the SPL architecture, these display devices can be specified as variabilities whose architectural elements can be bound at deployment time or at runtime. Figure 3 shows a SPL architecture for this scenario. Section V uses this scenario to demonstrate our contract approach presented in Section IV. Figure 3. A SPL architecture for the patient reminder. HHS Display is a mandatory component. C. Describing Variabilities The homecare system requires the description of static and dynamic variabilities. For describing static variabilities, several ADLs [2], [3], [4], [5] can be used. As previously discussed in Section II, they typically distinguish commonalities from variabilities using variation points, which are represented by constraint expressions. The use of constraint expressions, however, brings problems related to lack of encapsulation, once the modeling of a desired product requires the description of several low level variation points, which are scattered throughout the SPL architecture. For example, a Boolean guard can be described for each patient s health problem (e.g., hypertension). In addition, each Boolean guard is attached to all architectural elements (e.g., medical sensors) that should be part of a product architecture aimed at patients with that health problem (e.g., hypertensive patient). Depending on the number of Boolean guards, and the how they are tangled in complex formulas, individual variation points can become extremely difficult to track. Dynamic variabilities, in turn, are described in the most DSPL approaches [6], [9], [8] using feature-oriented concepts, in contrast of architectural models. Once the feature models stay at the conceptual level [11], such technique requires the mapping of features to architectural elements. However, an extra mapping layer is not suitable for homecare systems, since their dynamic variabilities are critical and complex, and the mapping introduces an additional and unnecessary point of failure. The dynamic variabilities should be clearly and explicitly described at the architectural level, specifying the adaptations and the rules under which

4 such adaptations should take place at runtime. This strategy reduces the risks inherent in the mapping process. Current approaches lack a comprehensive manner to describe static and dynamic variabilities at the SPL architecture level. The use of a mixture of approaches can cause an extra effort during the SPL architecture development, since an approach conceived to describe static variabilities may not be appropriate to describe dynamic variabilities, and vice versa. Moreover, this makes more difficult to model a system whose behavior should be safe, an essential condition for systems that deal with human lives. Another difficulty is in the description of variabilities whose binding time is flexible (static or dynamic). This is the case of the previous mentioned homecare system scenarios, where their architectural elements can be bound at deployment time or at runtime. IV. VARIABILITIES AS ARCHITECTURAL CONTRACTS Our work proposes a comprehensive approach to describe static and dynamic variabilities at the SPL architecture level. In our approach, variabilities are described as architectural contracts, which determine the architectural adaptation actions and the required conditions for an adaptation. Contracts are first-class elements described to support adaptations at the SPL architecture level. To describe contracts we use CBabel language [19], [20], an ADL created by our research group with features to support software architecture and contract description. A. Contract Meta-model By means of a meta-model shown in Figure 4, we present the contract elements and the relationship between a contract and a SPL architecture. Figure 4. Contract meta-model. Contracts are first-class elements associated with the SPL architecture through the Variability entity. Each Service of a contract is formed by Adaptation Actions that describe CBabel primitives to adapt the architecture, for example, instantiate to add a element and link to connect elements. For a Variation Point, services can add or remove architectural elements that are variants in the context of that variation point (variant role in the meta-model). For an Optionality, services can add or remove optional architectural elements (optional role in the meta-model). Figure 5 shows an example with services describing the variation points presented in Figure 1. Figure 5. Example of services describing the variation points of Figure 1. In contrast to the description of variation points associated with architectural elements, as shown in Section II, we describe variation points separately from the architectural elements and from the SPL architecture. This approach alleviates the problem of the lack of encapsulation, just discussed in Section III, once it concentrates in an unique place both the variation point and the variant representations. According to the variability binding time, a contract can be static or dynamic. Static contracts are described to deal with static variabilities. The architectural adaptation actions described in such contracts should be applied to the product architecture during its derivation. Dynamic contracts, in turn, deal with dynamic variabilities, where adaptations should be applied to product architecture at runtime. Dynamic contracts use adaptive features to perform architectural adaptations. Due to that, the architectural adaptations described in services are performed using context information defined by Categories, and following context rules defined by Profiles. The context information is represented by properties of resources associated to the context where the product executes (e.g., location of devices). Context rules, in turn, quantify and establish conditions that should be satisfied to allow the adaptation. Logic predicates can be described involving properties values. For example, Device.location = living room means that an adaptation occurs only when the particular device is in the living room. Negotiation and Transition are also entities used by dynamic contracts. Negotiation allows the modeling of transitions among services. For example, when the product architecture is configured with the Blood Pressure Sensor component and a new sensor is configured, a transition should occur to adapt the architecture at runtime. These entities facilitate the definition of an adaptation policy for a given dynamic variability. State machines can be used to establish a particular order to deploy the services, or utility functions can be used to drive the adaptation mechanism with the aim of selecting the best variant. Although the infrastructure is not the focus of this paper, it is worth noting that the semantics of a dynamic contract should be enforced at runtime by a support framework with context monitoring and adaptation control, central tasks in a DSPL implementation [10]. Regarding the contract semantics, additional aspects are available in [21], where the authors present an operational semantics for contracts and its implementation in a prototype tool, which allows execution and analysis of contracts.

5 B. Describing and Using Contracts Contracts, in our approach, should be part of a process involving two major phases, described below. 1) SPL architecture description: The first phase corresponds to the design of the SPL architecture. Firstly, the architect describes the core SPL architecture with architectural elements corresponding to commonalities. Next, she/he elicits the static and dynamic variabilities, and describes static contracts for static variabilities and dynamic contracts for dynamic variabilities. During the design, all contracts (static and dynamic) are described separately from the commonalities. This separation of concerns benefits the development and evolution of both core SPL architecture and the associated contracts. This makes the contract an independent mechanism to deal with variabilities at the architectural level. 2) Product architecture derivation: The second phase of the process occurs when a new custom product architecture should be created. The derivation starts by establishing the initial product architecture from the core SPL architecture. The architect can then resolve the static variabilities according to the patient requirements. In this step, the corresponding static contracts (described in the previous phase) can be used to configure the initial product architecture. Each contract is applied by adapting the product architecture through additions and removals in an incremental way. After this step, besides the elements of the core SPL architecture, the product architecture will be constituted by elements of the resolved static variabilities. The derivation then continues dealing with dynamic variabilities in order to enable runtime adaptations. To do this, the architect should choose the corresponding dynamic contracts to be deployed with the product architecture, and the initial variants of each contract, which are deployed only at the beginning of the product execution. The derivation therefore does not take place as a whole, but occurs partially, producing a flexible product architecture (as occurs in DSPLs), which allows further adaptations in the light of demands just occurring at runtime. It is worth noting that if no dynamic variability is required, the derivation process results in a product architecture with all variabilities resolved, as occurs in static SPLs. Figure 6 shows the result of the process described above. The derivation generates an architecture for the product built with the core SPL architecture and with the resolution of static variabilities performed by contracts. If there are dynamic variabilities, the derivation generates an architecture where associated contracts can adapt it at runtime. V. CONTEXT-AWARE PATIENT REMINDER Aiming to demonstrate our contract approach, we present in this section a dynamic contract developed to support the context-aware patient reminder, discussed in Section III and shown in Figure 3. The dynamic contract contains adaptation actions and context rules with the aim of selecting, at Figure 6. Contracts in the context of SPL architecture and derivation. runtime, a display device to show notifications to the patient. Device selection considers information related to patient preferences, essential in homecare systems. The patient should receive notification messages in his/her preferred device from among those located closer to him/her, i.e., in the same room of the residence. Figure 7 shows a Category and a Profile, developed to satisfy these requirements. Figure 7. Category DeviceInfo and profile preferred device profile. The category DeviceInfo defines context information of a device, such as its location, represented through a numeric value indicating the room in the residence where it is located, and its type, for example, TV, tablet, etc. The profile preferred device profile, in turn, contains two criteria for device selection. The first criteria (line 06) selects the device only if the patient, located by a location service, is in the same room of the device, i.e., if DeviceInfo.location is equal to %patient current location. The parameter %patient current location is informed by the dynamic contract shown in Figure 8. The second criteria (line 07) selects the preferred device of the patient, respecting the precedence rule which defines the TV as the preferred device, followed by tablet, PC, and HHS display. Both criteria are used together to select the best configuration. For example, if the patient is in the bedroom and both the TV and the tablet are in the bedroom, the profile leads to the selection of the TV because it is his/her preferred device. Figure 8 shows a dynamic contract developed with CBabel primitives capable of discovering and selecting a device that meets the preferred device profile. The contract deals with the dynamic variabilities and guides the adaptation of the product architecture at runtime. The statement select (line 04) locates, through a resource discovery mechanism, the Device class instances (first parameter) corresponding to the devices deployed in the residence. Device is a superclass of TV, Tablet, PC, and HHSDisplay subclasses. The definition of these entities are not shown here.

6 Figure 8. Dynamic contract to select the display device. After locating the devices, the statement select chooses among these devices the one closer to the patient and preferred by the patient, according to the context rules defined in preferred device profile (second parameter). The selected device is then dynamically linked to the notifier component (line 07), causing the adaptation of the product architecture. It is important to notice that this contract receives a numerical context variable (patient current location in line 02), which is used by preferred device profile aiming to identify the patient location at home. A location service keeps track of this variable. The service select device is capable of verifying the context changes continually, through the resource monitoring mechanism. For example, if the TV in the bedroom is turned off or not operational, the service dynamically links the tablet to the notifier component because it is also in the bedroom. However, if, at any time, no device meets the context rules described in the profile, the no service state is reached according to the negotiation clause (line 11). In such case, the notifier component can use the mandatory component HHS display. Details about the resource discovery and monitoring mechanism are available in [19], [18]. VI. RELATED WORK The initial notion of contracts is defined in previous works of our research group [19], [20], which leveraged the concept of contract as proposed in [22]. This kind of contract establishes a formal relationship among the parts that use or provide resources, where constraints and negotiation rules over the used resources are expressed. In the context of our work, contracts allow to define a relationship between variabilities and adaptation actions, where the variabilities are treated as a specialized view of a given SPL architecture. From the SPL concepts, several works have emerged aiming to develop adaptive systems. Such works follow two main directions to describe dynamic variabilities: based on feature models or on architectural models. Feature models are used by [6], [9], [8], which do not adopt an architectural representation. Conversely, our architecture-centered approach describes dynamic variabilities as first-class elements that specify adaptations at the architecture level. The works based on architectural models allow, in general, to specify adaptation rules for reconfiguring components. Hallsteinsein et al. [1] use SPL techniques for building of adaptive systems, where variabilities are modeled as part of the architecture. This work uses property annotations on components in order to describe their quality of service. These properties are used together with utility functions to perform adaptations at runtime. In our approach, the adaptation information is isolated from the architectural elements using contracts, including the properties and adaptation policies such as utility functions. This feature facilitates the independent evolution of both the architecture and the adaptation issues of the dynamic variabilities. In [7], four aspects are considered in the adaptation: variability, environment and context system, system architecture, and adaptation logic. Architectural adaptations are built using techniques based on aspect-oriented modeling. Conversely, our approach provides separation of concerns through other mechanisms, since contracts represent variability in a high level of abstraction and can be described regardless of the architecture. The proposal described in [13] distinguishes two types of variability: environment variability that defines the conditions under which a system must adapt, and structural variability that defines the resulting architectural configurations. Reconfiguration is done through a componentbased middleware and uses an adaptation policy based on state machine. However, it is unclear whether the adaptive behavior specification can be made to deal with changes related to availability and quality of resources, and to the user needs, as proposed in our approach. VII. CONCLUSION The design of homecare systems requires techniques to create highly customizable architectures. SPL techniques allow such customization, but current approaches lack a comprehensive manner to describe, at the architectural level, variabilities with different binding times. We presented an approach that allows the description of static and dynamic variabilities as contracts. The contracts are first-class elements capable of representing the variabilities as adaptation actions to be performed at the SPL architecture level. The main contribution of the proposed approach is the possibility of expressing static and dynamic variabilities at a higher level of abstraction, and separately from the commonalities, bringing benefits in terms of separation of concerns. Moreover, this property also facilitates the evolution of both the SPL architecture and the contracts, because the SPL architecture is not aware of the existence of contracts. Due to that, additional contracts can be created and associated to the SPL at anytime. For dynamic variabilities, this flexibility demands, however, a strict configuration management support to avoid incompatible bindings of SPL components and contract versions. A contract description language underpins our approach for development and evolution of a SPL architecture for homecare systems. Furthermore, the semantics of the contracts can facilitate verification procedures and formal

7 validation of its specifications, even before the software product deployment. We are currently investigating the use of contracts to describe the constraints and the dependency relationship among the variabilities of a SPL architecture. An alternative is to define contracts that may depend on other contracts, aiming to represent the dependency among variabilities. We are also working on an evaluation involving software architecture practitioners using our contracts with the aim of consolidating our approach. As a next step, we intend to apply our contracts in a prototype support tool that we are currently building to support the design of pervasive homecare applications. With such support, the application developer is able to create a specific operation scenario (a residence with a particular patient, for example) and distribute sensors and devices across the environment, following the previously described SPL architecture and contracts. Thus, each installation of the product can be simulated before it is deployed in the target residential environment. ACKNOWLEDGMENT The authors would like to thank the financial support provided by CNPq and FAPERJ. REFERENCES [1] S. Hallsteinsen, E. Stav, A. Solberg, and J. Floch, Using Product Line Techniques to Build Adaptive Systems, in 10th SPLC, Washington, DC, USA, 2006, pp [2] E. Dashofy, A. van der Hoek, and R. Taylor, A Comprehensive Approach for the Development of Modular Software Architecture Description Languages, ACM Trans Softw Eng Methodol, vol. 14, pp , [3] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch, COV- AMOF: A Framework for Modeling Variability in Software Product Families, in 3rd SPLC, 2004, pp [4] A. Garg, M. Critchlow, P. Chen, C. Van der Westhuizen, and A. van der Hoek, An Environment for Managing Evolving Product Line Architectures, in 19th ICSM, 2003, pp [5] R. van Ommering, F. van der Linden, J. Kramer, and J. Magee, The Koala Component Model for Consumer Electronics Software, Computer, vol. 33, pp , [6] C. Cetina, P. Giner, J. Fons, and V. Pelechano, Using Feature Models for Developing Self-Configuring Smart Homes, in 5th ICAS, Valencia, Spain, 2009, pp [7] B. Morin, O. Barais, J. Jézéquel, F. Fleurey, and A. Solberg, Models at Runtime to Support Dynamic Adaptation, Computer, vol. 42, no. 10, pp , [8] J. Lee and K. C. Kang, A Feature-Oriented Approach to Developing Dynamically Reconfigurable Products in Product Line Engineering, in 10th SPLC, Washington, DC, USA, 2006, pp [9] P. Trinidad, A. R. Cortés, J. Peña, and D. Benavides, Mapping Features Models onto Component Models to Build Dynamic Software Product Lines, in Workshop on DSPL, Kyoto, Japan, 2007, pp [10] S. Hallsteinsen, M. Hinchey et al., Dynamic Software Product Lines, Computer, vol. 41, no. 4, pp , [11] K. Kang, S. Cohen, J. Hess, W. Nowak, and S. Peterson, Feature-Oriented Domain Analysis Feasibility Study. SEI (Carnegie Mellon), Pittsburgh, PA, Tech. Rep., [12] N. Medvidovic and R. Taylor, A Classification and Comparison Framework for Software Architecture Description Languages, IEEE Trans Soft Eng, vol. 26, no. 1, pp , [13] N. Bencomo, P. Sawyer, G. Blair, and P. Grace, Dynamically Adaptive Systems are Product Lines too: Using Model-Driven Techniques to Capture Dynamic Variability of Adaptive Systems, in 2nd Works on DSPL, Limerick, 2008, pp [14] A. Copetti, O. Loques, J. Leite, T. Barbosa, and A. Nóbrega, Intelligent Context-Aware Monitoring of Hypertensive Patients, in Workshop for Situation Recognition and Medical Data Analysis Healthcare, [15] A. Copetti, Intelligent Context-Aware Monitoring in Remote Assisted Living Applications (in Portuguese), Ph.D. dissertation, Institute of Computing, Fluminense Federal University, Niterói, Brazil, [16] O. Loques and A. Sztajnberg, Adaptation Issues in Software Architectures of Remote Health Care Systems, in 2nd SEHC, Cape Town, South Africa, 2010, pp [17] M. Eslami and M. van Sinderen, Flexible Home Care Automation Adapting to the Personal and Evolving Needs and Situations of the Patient, in 3rd PervasiveHealth, Los Alamitos, 2009, pp [18] A. Sztajnberg, A. Rodrigues, L. Bezerra, O. Loques, A. Copetti, and S. T. Carvalho, Applying Context-aware Techniques to Design Remote Assisted Living Applications, Int. Journal of Functional Informatics and Personalized Medicine, vol. 2, no. 4, pp , [19] L. Cardoso, A. Sztajnberg, and O. Loques, Self-adaptive Applications Using ADL Contracts, Lecture Notes in Computer Science, vol. 3996, p. 87, [20] O. Loques, R. Cerqueira, A. Sztajnberg, and S. Ansaloni, A Contract-based Approach to Describe and Deploy Nonfunctional Adaptations in Software Architectures, Journal of the Brazilian Computer Society, vol. 10, no. 1, pp. 5 18, [21] C. Braga, F. Chalub, and A. Sztajnberg, A Formal Semantics for a Quality of Service Contract Language, Electron. Notes Theor. Comput. Sci., vol. 203, no. 7, pp , [22] S. Frølund and J. Koistinen, Quality of Services Specification in Distributed Object Systems Design, Distributed Systems Engineering Journal, vol. 5, no. 4, pp