The Dynamic Variability for Complex, Adaptive Systems

1 Introduction The Dynamic Variability for Complex, Adaptive Systems (DiVA) project aims to produce a new tool supported methodology with an integrated framework for managing dynamic variability in complex, adaptive systems. The project is comprised of a number of workpackages, each focusing on a particular façade of this problem. The present work is carried out under the workpackage dedicated to the issues of Requirements Engineering for DiVA (workpackage 1). The present survey aims to contribu
of 5
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  1 Introduction The  D  ynam i  c V  ariability for Complex,  A daptive Systems (DiVA)  project aims to produce a newtool supported methodology with an integrated framework for managing dynamic variability incomplex, adaptive systems. The project is comprised of a number of workpackages, eachfocusing on a particular façade of this problem. The present work is carried out under theworkpackage dedicated to the issues of Requirements Engineering for DiVA (workpackage 1).The present survey aims to contribute towards the tasks of: ã identifying requirements relevant for Requirements Engineering in presence of variabilityand dynamic changes ã understanding requirements configuration management and configuration dependencyanalysis techniques in presence of dynamic variability; ã sketching the initial outlining for addressing challenges pertaining to analysis for dynamicvariability requirements and co-existing, co-dependent configurations of variants at runtimein the DiVA Requirements Engineering Approach which will be developed as part of DiVA project.Moreover, since DiVA intends to devise an approach based on Aspect-Oriented SoftwareDevelopment (ASOD) and Model-Driven Development (MDD) techniques, work onRequirements Engineering in both of these areas is also of high relevance to the survey.Thus, in order to understand the issues related to managing requirements variability in presenceof dynamic change using AOSD and MDD techniques, this report needs to survey the currentwork related to the individual components contributing to this issue. These components arework on:1.  Requirements Engineering for Variability which is being addressed in the area of SoftwareProduct Lines;2.  Requirements Engineering for Dynamic Change which is being actively addressed in thearea of Ubiquitous and Mobile Computing, in particular Context Modelling for these;3.  Requirements Configuration Management and configuration dependency analysis which is being addressed in the area of Requirements Configuration Management;4.  Aspect-Oriented and Model-Driven Requirements Engineering  techniques addressed inthese two respective areas. 1.1 Requirements Engineering In (Lamsweerde 2000) Requirements Engineering is defined as an intertwined combination of the following activities: ã  Domain analysis which refers to study of the environment of the system to be, whereby therelevant stakeholders are identified and interviewed, the problems with the current systemare their improvement options are investigated, and the objectives of the future system aredefined; ã  Elicitation : alternative models of the target system are analysed with the aim of fulfillingthe previously identified objectives. Requirements and assumptions for these models areidentified. ã  Negotiation and agreement  : the identified alternatives and risks are evaluated to select the best alternative; ã Specification : requirements and assumptions are formulated precisely; ã Specification analysis : specifications are checked for inconsistencies, incompleteness,conflicts, and feasibility; ã  Documentation : decisions and their rational and related assumptions are recorded; Version 0.1: Draft 20.10.2008D1.1: Deliverable title Page 7 of 48 ã  Evolution : requirements are modified to accommodate corrections, changes or newobjectives.  As summarised in (Lapouchnian 2005) all these activities are centred around the modelling of requirements, i.e., “building abstract descriptions of the requirements that are amenable tointerpretation.” (Buhr and Casselman 1996). From perspective of DiVA, domain analysis,elicitation, negotiation and agreement and evolution are the most critical activities, as theyrelate to problem identification, definition of solution variants, variant selection, and further change adaptation in the selected solution respectively. 1.2 Requirements Engineering for Dynamic Change The main body of Requirements Engineering work is concerned with static elicitation,representation, and analysis of requirements (Nuseibeh, Kramer et al. 1994; Jackson 2001;Sommerville 2004). The issues of handling changing requirements have also been mainlystudied within the context of a static set of requirements. With the recent emergence of anumber of continuously dynamically changing mobile and ubiquitous systems the need for consideration of dynamic change at requirements level has also emerged. In this report weconsider the work on requirements and dynamic change from three perspectives:1. identifying requirements (in sense of characteristics) that are necessary to supportdynamic change at requirements level (Strang and Linnhoff-Popien 2004; Henricksen,Indulska et al. 2005);2. developing Requirements Engineering approaches for handling dynamic change at therequirements level (Berry, Cheng et al. 2005; Kolos-Mazuryk, Poulisse et al. 2005;Goldsby and Cheng 2006; Kolos-Mazuryk, P. A. T. van Eck et al. 2006; Sitou andSpanfelner 2007; Xu, Cheung et al. 2007).3. understanding as to how does the present-day RE work relate to the dynamic change,or, more specifically, to the characteristics of such change defined in above point 1.In the rest of this report we consider each of the above perspectives. The characteristicsrequired to support dynamic change in requirements (Point 1) are discussed in section 2 of thisreport. The currently available work on dynamic RE (Point 2) is discussed in section 3. Theissue as to how the existing RE approaches satisfy the characteristics required for dynamicchange (Point 3), is presented in section 4. Here the present-day RE approaches are groupedinto 5 categories in accordance with the way that requirements are structured: a) goal-basedapproaches; b) feature-based approaches; c) use case-based approaches; d) viewpoint-basedapproaches; and e) aspect-oriented approaches. Some representative approaches from each of these groups are then evaluated against the criteria defined in section 2. Section 5 considers thecurrent state of research and practice in requirements configuration management to shed somelight on the way that change is currently supported in RE. In order to provide a manageableand reversible run-time re-configuration support for requirements, the DiVA RE approachwould need to handle at least a minimal set of requirements configuration managementactivities. Finally, section 6 concludes the report by presenting the initial outline of Diva REapproach which aims to build on the strengths of the RE approaches discussed in section 4 andaims to satisfy the criteria of section 2 as fully as possible. Version 0.1: Draft 20.10.2008D1.1: Deliverable title Page 8 of 48 2 Characteristics to be supported for DiVA systems: dynamicallychanging systems with variability As noted above, DiVA focuses on systems and configurations of systems (with variability)that dynamically adapt to environmental or system-internal changes. All these characteristicsare also native to mobile and ubiquitous computing systems. In this section we draw on therelated surveys (Strang and Linnhoff-Popien 2004; Henricksen, Indulska et al. 2005; Rigole2007) and present some of these issues from the perspective of Requirements Engineering for DiVA. Context Awareness : since DiVA systems will adapt in response to context change, they need to   be aware of the context (Rigole 2007). This criterion related to general environmental influences , modelling of data and histories, and the quality of context. Modelling  Data and  Histories is relevant since, while some context information can be considered static in the sensethat its value is unchanging, the majority of context information is dynamic. As a consequence,if not appropriately updated, context information can quickly get outdated. Moreover, thecontext histories of some activities could be used for forecasting certain events e.g., steadydecline in quality of some service may be used to expect and prepare for a change of service provider. Thus requirements for need of data update (e.g., location change) and historymodelling should be considered explicitly (Henricksen, Indulska et al. 2005; Rukzio, Hamard etal. 2006). The Quality of Context (QoC) is relevant since context information might beunavailable, or out of date, and additional crosscutting requirement arises in adaptive systemsdemanding that they evaluate the quality of context information at system run-time and toresolve any conflicts identified due to this. In (Buchholz, Kupper et al. 2003) a number of attributes (i.e.,  precision, probability of correctness, resolution, up-to-dateness, refresh-rate ) are presented to reason about information persistence and quality of contexts. In addition, the particular characteristics of context-aware systems, such as determining the ownership of context information, and the enforcement of access control according to context-dependent privacy preferences (Henricksen, Wishart et al. 2005) need to be considered. Variability Modelling  : capturing and representing variability in requirements models is anessential part of the DiVA work at all the steps of the intended methodology. One of the maingoals of DiVA is to tame the complexity of dynamically adaptive systems by managing thecombinatorial explosion of variants. This can be done by leveraging concepts from the SoftwareProduct Lines (SPL), Aspect-Oriented Software Development (AOSD), and Model-DrivenEngineering (MDE) communities. Some initial ideas for managing dynamic variability atdesign- and run-time in DiVA methodology have already been sketched out (Morin, Fleurey etal. 2008). However, since support for dynamic variability identification, representation, andmanagement, as well as some reduction of alternatives for system adaptation paths should be provided earlier in the development lifecycle, this activity will be amongst those of the primaryfocus for the DiVA RE work. Thus, support for variability identification and representation isto be carefully studied for the DiVA RE approach.  Modularity and Composability (or  Composability for Systems of Systems) : DiVA systems aredistributed not only in sense of one system running on more than one computer, but also as“systems of systems” emerging from combination of independent systems. Thus, as indistributed systems, DiVA systems do not have “a central system responsible for the creation,deployment and maintenance of data and services, in particular context descriptions” (Rigole2007) and system models must be composable. From the Requirements Engineering perspective this implies that it has to be possible to analyse requirement  of an individual DiVAsub-system in isolation and support run-time composition of such requirements models intolarger models. Version 0.1: Draft 20.10.2008D1.1: Deliverable title Page 9 of 48 “Furthermore, the context model should be separated from the application components and the parts of the system concerned with sensing and actuation, so that the context model can evolveindependently, without requiring application components to be re-implemented” (Rigole 2007). Conceptual modelling  (or Support for semantic understanding) : To realise the aboverequirement for composability, there needs to be a check that two context-aware systemscomposed into a DiVA system have compatible interpretation of the context and changeinformation, i.e., they must have “semantic interoperability” (Rigole 2007). For instance, whenasked to maintain “good response time” all participating sub-systems should have consistentinterpretation of “good”. This relates to the notion of   shared understanding  (Rigole 2007)which is modelled, for instance, via ontologies for semantic web (Berners-Lee, Hendler et al.  2001; Chen, Finin et al. 2003; Gu, Wang et al. 2004; Preuveneers, Bergh et al. 2004; Paslaru2005; Bruijn and al 2008).  Incompleteness, Ambiguity and Uncertainty : although incompleteness and ambiguity arecharacteristics most often associated with requirements engineering, in the area of adaptivesystems these characteristics also arise due to difficulty of capturing the relevant information(for instance, a data update may be lost due to poor network conditions). Consequently,incompleteness and uncertainty should be accounted for by the requirements modellingtechniques (e.g., by using probabilistic methods).  Support for Scalability : since a DiVA system may be composed of a number of large systems,it is important for the DiVA requirements modelling approach to scale up adequately. This, for instance, may mean that alternative representations should be allowed, e.g., a graphical as wellas textual notations should be available, etc.  Alternative configuration selection: DiVA systems require a mechanism for evaluatingalternative configurations against some given preferences. This mechanism should allow aneasy, preferably automated, way of ranking the available alternative configurations. Thoughsome user input may be necessary for this task (e.g., if new requirements have come up therelation of which to the existing ones was not previously known) it should be kept to minimum,since alternative configuration selection is a run-time process. Moreover, once a DiVA systemhas identified the need to update its configuration and has selected an alternative configurationto which it must migrate, it requires support for realising such a migration, relating to the needfor  run-time re-configurability , which, in turn requires the ability of the system to detect andresolve conflicts between requirements. Version 0.1: Draft 20.10.2008D1.1: Deliverable title Page 10 of 48 3 Requirements engineering approaches for handling dynamicchange Since addressing dynamic change in requirements is a new research area for RequirementsEngineering, currently there is only a small body of work directly addressing this problem(Berry, Cheng et al. 2005; Lapouchnian, Liaskos et al. 2005; Lapouchnian, Yu et al. 2006; Yu,Lapouchnian et al. 2008). The main available work is discussed below. Since the maincounterparts of this work are discussed in the following section (section 4) the work discussedin this section is not evaluated against the comparison criteria of section 1, but is provided asan overview of the current state of the art. 3.1 Reflection on Requirements Engineering for Dynamic Change Berry et al. (Berry, Cheng et al. 2005) provide a reflective view on requirements engineeringfor adaptive systems. They suggest that there are four levels of RE associated with an adaptivesystem:1. level one, carried out by humans, is on eliciting and analysing the domain of theadaptive systems, their features and the programmes to be used within these systems;2. level two, carried out by running system, is on identifying unexpected input, matchingit to the appropriate domain and adapting the system behaviour accordingly;3. level 3, done by humans to determine the adaptation elements of the adaptive system inorder for the system to be able at run time to carry out the required adaptations (i.e., theadaptations of level 2).4. level 4, done by humans to understand the adaptation mechanisms in general, i.e.,learning about detection and monitoring techniques for adaptation triggering events,decision making techniques upon adaptation triggering events, and the actualmechanisms for adaptation realisation.In this paper it is further noted that since for the foreseeable future software will not be trulyintelligent, it will be up to humans to determine how and what the adaptive systems must do to
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks