43.Requirements Models at 43.Run-time to Support Consistent System Evolutions

Requirements Models at Run-time to Support Consistent System EvolutionsPaola InverardiDip.di Informatica,Universit`a dell’AquilaL’Aquila,Italypaola.inverardi@di.univaq.itMarco MoriIMT Institute for Advanced Studies LuccaLucca,Italymarco.mori@imtlucca.itAbstract—Self-adaptive systems call for run-time manage-ment because of the environment uncertainty.In addition users may put forward new needs while the system is in execution possibly in response to environment variations.This means that a self-adaptive system needs to evolve at runtime accordingly to the user and context variations.We propose a context-aware framework that is inspired by the feature engineering perspective,and brings requirements specifications at run time by emphasizing the requirements that are context-dependent.We support system evolution by proposing a notion of correctness which is based on our context requirements.Our framework is generic and it is amenable to augment the system with new requirements arising at run-time.Since new requirements may interact with deployed requirements we provide the support to keep those entities at run-time and check their correctness jointly.Furthermore we identify the characteristics that a requirement language should have,to manage and check requirements at run-time in our framework.Keywords-Adaptive systems,requirements engineering,con-sistent evolutionI.I NTRODUCTIONAs Ubiquitous computing is becoming increasingly popu-lar,software systems have to deal with the uncertainty shown by the environment.The information about the system’s surrounding is not always complete thus making the system more likely to be inconsistent with its context.In this sce-nario self-adaptive systems have been presented as systems that are able to modify their structure and/or behavior as a consequence of different variability dimensions.Self-adaptive systems can be defined as follows[19]:Self-adaptive systems aims to adjust various artifacts or attributes in response to changes in the self and in the context of a software system.By self,we mean the whole body of the software,mostly implemented in several layers, while the context encompasses everything in the operating environment that affects the systems properties and its be-havior.Self-adaptive systems require different methodologies and theories in order to address the evolution at design time and run-time phases.Systems have to be validated statically at design time considering the foreseen context environment. On the other hand,systems have to be validated at run-time phase by considering un-anticipated behaviors requested by the user as a consequence of the unforeseen context environment.Hence,self-adaptive systems have to manage dynamically the system behavior and/or the system struc-ture considering requirement,design and implementation artifacts at run-time[7].Among these three abstraction levels,we believe that requirements play a key role to support the development and the evolution of self-adaptive systems.Requirements evolution should be supported by concrete mechanisms to check the system consistency.These mechanisms should be available not only at design time but also at run-time in order to evaluate un-anticipated behaviors that cannot be statically analyzed.It is not always possible to foresee all the requirements at design time because new unpredictable environmental conditions may give rise to new user requirements at run-time.In addition it is not always possible to stop the execution of a system to update it to take into account the new requirement.In spite of this,it is emerging from the requirement engineering community a big consensus on moving some of the requirement activities from design time to run-time[5],[20].Our paper defines a framework to support consistent context-aware systems evolutions.The framework considers both foreseen and unforeseen evolutions.The former handles design-time activities while the latter handles run-time ac-tivities.In this scenario we provide the support to statically analyze foreseen behaviors and to dynamically analyze new emergent behaviors.In order to check if the system can be augmented with a new requirement,we provide a notion of consistent evolution for the requirements speci-fication.Whenever the new requirement does not interact correctly with the current deployed ones,we consider the evolution to be inconsistent.As a consequence current deployed requirements have to be kept at run-time in order to perform the joint consistency check.To this end,we adopt a system notation which is inspired by the feature engineering perspective.Following this vision we provide different notions of consistency and we support one of this notion in our framework.Furthermore we make explicit the traceability between the system implementations models and the requirements entities maintained at run-time.In the literature,there exist different approaches that face requirement engineering problems for context-aware systems [2]and for self-adaptive systems[8],[20].There are differ-ent characterizations for requirements suitable for adaptive systems[22],[23],[9],[11].These approaches only consider requirements specifications at design time while they do not propose any run-time activity.The framework[18]separates requirements activities at design time from requirements activities at run-time.The authors devise a process to evolve the requirements specification with un-anticipated behaviors arising from the user.The paper does not provide a definition of correctness to prevent the selection of interfering services. In our opinion,including new behaviors that are unknown at design phase is a process that should come along with a mechanism to verify high-assurance.To this end,we believe that managing requirements entities at run-time is a key issue for validating the evolution and consequently supporting the software adaptivity.In the remainder of this paper we describe a case study to illustrate our approach in Section II.Section III presents our evolution framework along with a notation for the requirements specifications.In Section IV we formalize the notion of consistent unforeseen evolution while in Section V we identify the characteristics for requirements languages required by our framework.In Section VI we present the interface architecture of the framework.Finally,we present in Section VII how the unforeseen evolution is actually achieved for the e-Health application beforefinal discussions and future work in Section VIII.II.M OTIVATING S CENARIOWe will explain our approach by means of a context-aware adaptive application for the medical domain.We propose an eHealth application to support the doctors activity by monitoring some vital parameters belonging to elderly peo-ple.Probes sense patient’s information and transmit them to the hospital through a home gateway.Doctors using their mobile or desktop devices can visualize elaborated graphic or numerical data for pulse oximetry and heart rate parameters.The screen visualization is performed following different alternatives each one requiring different hardware resources.In order to view real-time data it is necessary to run the application through a device connected to the network.Whenever this is not possible the most recent memorized graph is shown to the doctor.While the system is running and all the system alternatives have already been defined it could be the case that the remote monitoring system is augmented with a new unforeseen sensor for monitoring the respiratory rate.As a consequence the doctor may guide the evolution by requiring a new monitoring activity and by selecting the way in which he prefers to display the new patient data.III.E VOLUTION F RAMEWORKOur evolution framework is based on a requirements model that has to be manageable at run-time.Preliminary ideas of the framework have been presented in[13].We have devised two different kinds of evolutions:foreseen evolution and unforeseen evolution.The former depends directly by foreseen context variations.The software designer provides a set of system alternatives at design-time having in mind a partial vision of context.He defines how context explicitly guides the evolution.On the contrary,unforeseen evolutions depends by unforeseen context variations.An automatic process augments the set of system alternatives at run-time, by considering the user needs variation in the unforeseen context.The logic of this evolution is not completely known at design time and the user takes part to the evolution feedback loop.As a consequence of an unforeseen context variation,the user specifies a new requirement for the running system.While in our preliminary work we have provided the pro-cess for achieving foreseen and unforeseen evolutions,in this paper we discuss how we solve specific requirement engineering problems to provide high-assurance for adaptive systems.The notion of requirement that we adopt throughout this paper is based on the notation proposed in[12].The authors devise a requirements taxonomy starting from the concept of concern that is a matter of interest in a system. Each kind of requirement is then defined based on the cor-respondent kind of concern to which it pertains.Functional requirements pertain to functional concerns,performance requirements pertain to performance concerns and specific quality requirements pertain to quality concerns.In the same taxonomy,constraints are defined as requirements that restrict the solution space beyond what is necessary for meeting functional,performance and specific quality requirements.In our approach we consider as crucial the subset of constraint requirements which are expressed in terms of context entities.We will name these requirements with the term context requirements.They will be generated either by analyzing the resources required by the implemen-tation or by extracting the context entities from functional, quality or performance requirements.For thefirst option, the implementation may be analyzed by means of different methodologies such as workbench analysis or by static analysis like proposed in various approaches,in particular [3],[4].This approach analyzes the code by exploiting the annotations of resources consumption included in the code. For the second option,quality,functional and performance requirements have to be analyzed to extract the portion that refers to the context entities.These elements have becomefirst class entities within requirements specifications as devised by different approaches to the elicitation of context-aware requirements,e.g.[11],[9].Our requirements models relies on the Software Product Line Engineering(SPLE)perspective.SPLE vision breaks the system complexity through basic units of behavior and it support a generic notion of consistency.For this reason we believe that SPLE can support the evolutions for our requirements models.In SPLE the basic units of behavior isFigure1.Context Modelthe so called feature which is the smallest part of a service that can be perceived by the user.System configurations are obtained putting together two or more features.Inspired by SPLE we adopt as our notion of consistency for a certain configuration the feature interaction phenomenon. This property is shown whenever two or more features run correctly in isolation but they give rise to undesired behavior when jointly executed[16],[1],[6].Our framework is suitable for high-configurable software systems that are feature-based and it assumes the availability of requirements beyond the implementation artifacts.Our goal is to manage requirement at run-time,thus we focus on the unforeseen evolution which causes requirements to change at run-time.We support the run-time evolution by checking the consistency which depends on the feature structure we propose.In Section III-A we propose a context model to support the definition of our context requirements (III-B),whereas in Section III-C we introduce our notion of feature-based system along with a requirements specifi-cation.A.Context ModelWithin the evolution process,the context model plays a crucial role in supporting a notion of evolution free from interactions.The context model is the portion of the environment that is beyond the control of the system but may influence the system evolutions.It contains the set of entities based on which our context requirements are defined. Inspired by the classification proposed in[21]we adopt a generic classification of system and user context types.Each entity is represented as a key-value pair that can be assigned with a generic natural value.Each different combination of assignments for the context entities expresses a different context state.Figure1shows an instance of context model for the e-Health application we propose.The software engineer defines the context at design time whereas an automatic process may update it at run-time. The model extension is caused either by new unforeseen resources that appear in the environment or by new require-ments that may refer to new context entities.B.Context RequirementsIn Figure2it is shown the syntax that we use to express context requirements starting from the context entities.Each expression generated by the grammar refers either to a single feature or to a system configuration that has to be evaluated in order to assess its consistency in a certain context state.<C>::=<ContextEntity><rel−op><value>|<C><log−op><C> <rel−op>::=≥|≤|<|>|=<log−op>::=AND|OR<value>::=<natural>Figure2.Syntax of context requirementsC.System Notation1)Feature:In our vision we represent the adaptive ap-plication in terms of sets of features that is a service unit perceived by a user that can be implemented with a compo-nent and/or a service.A feature is a triple f i=(R i,I i,C i) where each component is defined as follows:•R i represents a functional,performance or a specific quality requirement•I i is the component/service implementing the feature.•C i represents a context requirementThe definition above is inspired by[10]which has been in turn inspired by the Problem Frame approach defined in [15].Differently from these approaches we refer to C as the context requirements instead of the domain assumptions.In our approach C is created by analyzing functional,quality and performance requirement R,and the implementation I. Example:In the e-Health application we define the feature to view the graphical oxygenation rate in terms of the three components as shown in Figure3.R graphOx:I f Oxygenation data are a v a i l a b l e Receive Oxygenation r a t e and View i t on the g r a p h i c a l widget−I f”OxygenationProbe”then(Each10times”getOximetryData”f o l l o w s a”displayGraph”)I graphOx:public class GraphOximetryViewer{XYDataset oximetryDataset=new XYSeriesCollection();...public void viewGraphicalOximetry(Graph g){Annotation.resources(”mem(50),CPUClockRate(1000)”);...for(i n t i=0;i<10;i++){XYDataItem dataOx=O x i m e t r y R e t r i e v i n g.getOximetryData(); dataVectOx.add(dataOx);}g.displayGraph(dataVectOx);}...}C graphOx:mem≥50Kb∧CP UClockRate≥1000Khz∧oxygenationP robe=trueFigure3.Example:feature f graphOxR graphOx entails two parts.Thefirst part is a simple textual representation.The second part is defined in terms of context entities and operations in I graphOx,it enables the traceability from R graphOx to I graphOx and from R graphOx to C graphOx.The context requirement C graphOx belongs to the feature implementation I graphOx and to the requirement R graphOx. The implementation is automatically annotated with the con-text entities consumption by following the CHAMELEONframework as presented in[3].We simply include in C graphOx the annotation for memory and CPU clock rate as extracted by analyzing the code in I graphOx.On the other hand by looking at the requirement R graphOx we extract the portion that refers to each context entity.Since R graphOx refers to the context entity”OxygenationProbe”,we insert it into the context requirements.Only if this variable is true,then oxygenation data are retrievable from the remote monitoring system.2)System Configuration:We represent system variants by assembling a set of features.Each configuration expresses the set of functionalities that a system shows to a user. Given the set of features F a system configuration is a triple obtained combining each feature in F:G F=(R F,I F,C F)(1) At this level of description we do not explain how to combine features.We just suppose to have an abstract union operator among features which is defined in terms of union operators for requirements,context requirements and imple-mentation components.The actual implementation of these union operators will depend on the specific formalisms that may be used to express requirements,context requirements and implementation.Given two features f1=<R1,I1,C1> and f2=<R2,I2,C2>their union is defined as:f1∪f f2=<R1∪R R2,I1∪I I2,C1∪C C2>(2) The software engineer combines the features at design time in order to obtain a set of alternatives requirement speci-fications.At run-time these alternatives may be augmented considering an un-anticipated feature that arise from a new user need.Each context requirement is computed combining the con-text requirements belonging to each single feature within the configuration.We have considered a union operators ∪C to merge context requirements depending on the nature of resources.For example if we have two requirements demanding bandwidth for20kbps each one,their union will express a demand of bandwidth for40kbps.The approach in[17]proposes a technique to create our context requirements.The problems of combining requirements R and implementation artifacts I are not our main focus.We will only give a brief explanation on how to achieve a possible system reconfiguration at implementation level in Section VII-B.As it will be clearer in the next section we mostly focus on context requirements.Example:We represent a possible system configuration G4to visualize the graphical and textual oxygenation rate (Fig.4).The system model we propose links requirements entities to the implementation artifacts.Evolutions of re-quirements may be easily mapped to the correspondent classes variations in terms of elements to deploy and un-deploy.As it is shown by the example,in a feature(R,I,C) requirements R and context requirements C correspond to an actual Java class implementation I.The context requirement expresses the combined request of resources as they appear in each feature.Each feature is mapped to the corresponding java class except for the V ariantG4class,which represents the entry point for the whole system configuration.R G4:R graphOx∪R R textOx∪R R getOxDataI G4:public class V a r i a n t G4{s t a t i c Graph myGraphViewer;s t a t i c Text myTextViewer;public s t a t i c void Execute(){myGraphViewer=new Graph();myTextViewer=new Text();GraphOximetryViewer graphOx=new GraphOximetryViewer(); TextOximetryViewer textOx=new TextOximetryViewer(); graphOx.viewGraphicalOximetry(myGraphViewer);textOx.viewTextualOximetry(myTextViewer);}...}public class GraphOximetryViewer{XYDataset oximetryDataset=new XYSeriesCollection(); ...public void viewGraphicalOximetry(Graph g){Annotation.resources(”mem(50),CPUClockRate(1000)”);...for(i n t i=0;i<10;i++){XYDataItem dataOx=O x i m e t r y R e t r i e v i n g.getOximetryData(); dataVectOx.add(dataOx);}g.displayGraph(dataVectOx);}...}public class TextOximetryViewer{...public void viewTextualOximetry(Text myTextViewer){ Annotation.resources(”mem(20),CPUClockRate(100)”); XYDataItem dataOx=O x i m e t r y R e t r i e v i n g.getOximetryData(); myTextViewer.d i s p l a y T e x t(dataOx.getYValue());}...}public class O x i m e t r y R e t r i e v i n g{...public s t a t i c XYDataItem getOximetryData(){Annotation.resources(”conn(t r u e),b(20)”);t r y{socket=(StreamConnection)Connector.open(connectionURL, Connector.READ WRITE);}catch(Exception ex){System.out.p r i n t l n(”Err.Open.Conn.To”:+connectionURL); System.out.p r i n t l n(ex);}...\∗Get Oxygenation Data oxData∗\...DataOxymetryMeM.add(OxData);return oxData;}...}C G4:mem≥70Kb∧CP UClockRate≥1100Khz∧oxygenationP robe=true∧conn=true∧b≥20KbpsFigure4.Example:System Configuration G4IV.S YSTEM E VOLUTIONWe are interested in supporting the unforeseen evolution by updating the current configuration with a new feature and by checking the correctness of the evolution.Inspired by the SPLE we adopt the absence of feature interaction as the notion of correct evolution for a system configuration G F. The correct evolution we propose entails different problems.Starting from the configuration G F =(R F ,I F ,C F )and from the new feature f New =(R New ,I New ,C New )we list the following notions of correctness:(i)(C F ∪C C New )[c s /x ]This formula checks the joint context requirement assigning the current context values c s to the formal parameters x.If the formula is true,the evolution occurs in an ”adequate”context state.(ii)R F ∪R R New is SatisfiableThis formula checks if the incoming requirement in-teracts with the already existent ones.(iii)I F ∪I I New R F ∪R R NewThis formula validates the augmented system imple-mentation against the augmented requirements specifi-cation.Our new configuration G F U f f New may be considered ”completely”consistent by checking these three formulas.Each of them differs in the needed algorithms and in the required computational effort.This is not a negligible issue since we are considering to perform the checking of correctness at run-time.Check (i)is the less expensive and it can be considered as a first step that precedes the other two checks.It is a necessary but not sufficient condition for the complete definition of consistency we propose.It can be exploited to discard the features that cannot be deployed in the current system configuration because of the current context state.Since the Ubiquitous computing is mainly characterized by the serendipitously of the environment we think that checking context requirements (i)plays a key role for such systems.Nevertheless we cannot neglect to consider the conflicts among canonical requirements (ii)and a notion of system validation (iii).In [14]we have provided the support to validate requirements with respect to Java artifacts through model checking;we have shown the feasibility of the approach on a eHealth application as described in this paper.Our contribution in this paper consists in providing a weak notion of correct evolution which is based on the satisfiability of context requirements (i).Example:Let us consider that the context requirement C G x has to be checked with C New x at the system context state c sx :C G x=mem ≥70∧CP UClockRate ≥1100∧conn =true ∧b ≥20∧oxygenationP robe =trueC Newx=mem ≥50∧CP UClockRate ≥1000∧b ≥20c s x =(mem (100),CP UClockRate (10),conn (true ),b (100),oxygenationP robe (true ))We simply obtain the union of the two context requirements exploiting the operator ∪C :C G x ∪C C New x=mem ≥120∧CP UClockRate ≥2100∧conn =true ∧b ≥40∧oxygenationP robe =trueWe consider the joint constraint to be not valid in c s x since the formula (C G x ∪C C New x )[c s x /x ]is false.V.R EQUIREMENTS F OR R EQUIREMENTS AT RUN -TIME In this section we identify which are the characteristics that a requirement language should have in order to manage and to check the requirements specifications we propose.In our approach requirements have to be managed at run-time.Moreover the set of system’s functionalities is not always provided once and for all at design time.While the system is running,users may require new functionalities that should be included into the system through an on-line process.Hence,it should be possible to add or delete requirements R while the system is running.New functionalities,added at run-time,may provoke inconsistencies of different nature.We have discussed in Section IV the three different problems that we consider to avoid inconsistent evolutions at run-time.To address these problems,the requirement portion R has to be expressed through a language that supports the satisfiability checking and a process to validate R with respect to the implementation I .Furthermore,the context requirements C should be expressed in quantitative terms in order to quantitatively limit the resources.Consequently it should be possible to validate C by checking the current assignment of context resources.To address all the above issues we propose a generic meta-layer to manage the requirements entities at run-time.This meta-layer is generic as it is independent by the adopted requirement and implementation languages.It defines which are the operations that have to be provided by any require-ment language for our framework:•Add /Delete a requirement R ;•Check requirement satisfiability for R ;•Validate R with respect to the correspondent implemen-tation I ;•Check a quantitative requirement C in a context state;We only focus on the operations on requirements specifica-tion that have to be provided at run-time;we do not consider the operations that are required at design time.VI.E VOLUTION F RAMEWORK FOR R EQUIREMENTS The interface architecture shown in Fig.5represents a possible implementation for our generic evolution frame-work.The framework is defined through a set of abstract classes each one providing a set of interfaces.Within the framework we will discuss only the classes which enable the management of requirements entities at run-time.Therefore we have highlighted the abstract classes of interest in red color.The most left red classes manage the feature elements and the system configurations.Here we are only interested in defining the languages for the requirement specification (R and C )and in checking a quantitative requirement C with respect to a context state.Figure5.Generic Requirement FrameworkThe UnforeseenEvolution module has to look for a new feature(SearchEngine module)in response to the ad-dition of a new requirement by the RequirementManager module.Through this last module,the user can specify a new requirement.He may ask for a requirements variation whenever the context model changes unforeseeable.Finally, the ContextManager abstract class triggers the variations of context by monitoring the ContextModel module.VII.C ASE S TUDYWe design the e-Health application by defining the single features which represent the basic behaviors.The features f textHeart and f graphHeart visualize the heart rate either as a numerical number or as a graphic picture.In the same way, the two features f textOx and f graphOx visualize the oxy-genation data.The features f getOxData and f getHeartData perform the connection to the remote monitoring system in order to obtain the oxygenation and heart rate data respectively.Finally the two features f sumGraphOx and f sumGraphHeart visualize a memorized graphical version for the two vital parameters of the patient.The software engineer combines the features in order to define a set of system alternatives.Each alternative is a different set of features which corresponds to an alternative requirements specification.Table I shows the6variants along with their context requirements C.Each of them is ex-pressed in terms of context entities,i.e memory(mem),CPU speed(CP UClockRate),network availability(conn),net-work bandwidth(b),heart rate probe(heartRateP robe)and oxygenation probe(oxygenationP robe).We have omitted the requirements R since in this paper we do not implement the notions of consistency that relay on R.A.Scenario for the Unforeseen EvolutionIn this section we will explain how we achieve the unforeseen evolution for the e-Health applica-tion.Let us suppose that the configuration G3=Table IS YSTEM C ONFIGURATIONSConfiguration Context RequirementG1={f textHeart,f getHeartData}b≥20kbps∧mem≥20Kb∧CP UClockRate≥100Khz∧heartRateP robe=true∧conn=trueG2={f textOx,f getOxData}b≥20kbps∧mem≥20Kb∧CP UClockRate≥100Khz∧oxygenationP robe=true∧conn=trueG3={f textHeart,f graphHeart,b≥20kbps∧mem≥70Kb∧f getHeartData}CP UClockRate≥1100Khz∧heartRateP robe=true∧conn=trueG4={f textOx,f graphOx,f getOxData}b≥20kbps∧mem≥70Kb∧CP UClockRate≥1100Khz∧oxygenationP robe=true∧conn=trueG5={f textOx,f graphOx,f textHeart,b≥40kbps∧mem≥140Kb∧f graphHeart,f getOxData,f getHeartData}CP UClockRate≥2200Khz∧heartRateP robe=true∧oxygenationP robe=true∧conn=trueG6={f sumGraphOx,f sumGraphHeart}mem≥100Kb∧CP UClockRate≥2000Khz{f textHeart,f graphHeart,f getHeartData}is currently de-ployed at the doctor device.The context requirement for this system alternative is:C G3=CP UClockRate≥1100∧mem≥70∧conn=true∧b≥20∧heartRateP robe=true The current context state is:c curr=(CP UClockRate(3000Khz),mem(100Kb),conn(true),b(100Kbps),heartRateP robe(true)) At a certain point in time a new sensor to monitor the respiratory rate is added to the remote monitoring system as a new UPnP device(respRateP robe).When this happens the doctor is notified about the new gathered data.As a consequence the doctor requires to visualize the patient respiratory rate.This is expressed as a new requirement that has to be considered into the system:R viewRespRate:Receive and view the respiratory rate data A search phase takes place in order to discover which feature implements R viewRespRate.The searching phase responds with a set of features that satisfy the following condition: R New implies R viewRespRateTwo different features are proposed each one implementing a different visualization modality:•R graphRespRate:if”respRateProbe”then(Each10 times”getRespRData”follows a”displayGraph”)•R textRespRate:if”respRateProbe”then(”getRespR-Data”follows a”displayText”)Let us suppose that the doctor chooses thefirst alternative since he wants to see the respiratory trend as a graph.The application should be augmented with the feature shown in Figure6.。