Beruflich Dokumente
Kultur Dokumente
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 faade 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 contribute towards the tasks of: identifying requirements relevant for Requirements Engineering in presence of variability and dynamic changes understanding requirements configuration management and configuration dependency analysis techniques in presence of dynamic variability; sketching the initial outlining for addressing challenges pertaining to analysis for dynamic variability requirements and co-existing, co-dependent configurations of variants at runtime in 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 Software Development (ASOD) and Model-Driven Development (MDD) techniques, work on Requirements 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 presence of dynamic change using AOSD and MDD techniques, this report needs to survey the current work related to the individual components contributing to this issue. These components are work on: 1. Requirements Engineering for Variability which is being addressed in the area of Software Product Lines; 2. Requirements Engineering for Dynamic Change which is being actively addressed in the area 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 in these two respective areas.
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 to interpretation. (Buhr and Casselman 1996). From perspective of DiVA, domain analysis, elicitation, negotiation and agreement and evolution are the most critical activities, as they relate to problem identification, definition of solution variants, variant selection, and further change adaptation in the selected solution respectively.
2 Characteristics to be supported for DiVA systems: dynamically changing 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 characteristics are also native to mobile and ubiquitous computing systems. In this section we draw on the related surveys (Strang and Linnhoff-Popien 2004; Henricksen, Indulska et al. 2005; Rigole 2007) 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 sense that 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, the context histories of some activities could be used for forecasting certain events e.g., steady decline 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 history modelling should be considered explicitly (Henricksen, Indulska et al. 2005; Rukzio, Hamard et al. 2006). The Quality of Context (QoC) is relevant since context information might be unavailable, or out of date, and additional crosscutting requirement arises in adaptive systems demanding that they evaluate the quality of context information at system run-time and to resolve 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 an essential part of the DiVA work at all the steps of the intended methodology. One of the main goals of DiVA is to tame the complexity of dynamically adaptive systems by managing the combinatorial explosion of variants. This can be done by leveraging concepts from the Software Product Lines (SPL), Aspect-Oriented Software Development (AOSD), and Model-Driven Engineering (MDE) communities. Some initial ideas for managing dynamic variability at design- and run-time in DiVA methodology have already been sketched out (Morin, Fleurey et al. 2008). However, since support for dynamic variability identification, representation, and management, 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 primary focus for the DiVA RE work. Thus, support for variability identification and representation is to be carefully studied for the DiVA RE approach. Modularity and Composability (or Composability for Systems of Systems): DiVA systems are distributed 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 in distributed systems, DiVA systems do not have a central system responsible for the creation, deployment and maintenance of data and services, in particular context descriptions (Rigole 2007) 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 DiVA sub-system in isolation and support run-time composition of such requirements models into larger models.
Version 0.1: Draft 20.10.2008 D1.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 evolve independently, without requiring application components to be re-implemented (Rigole 2007). Conceptual modelling (or Support for semantic understanding): To realise the above requirement for composability, there needs to be a check that two context-aware systems composed into a DiVA system have compatible interpretation of the context and change information, i.e., they must have semantic interoperability (Rigole 2007). For instance, when asked to maintain good response time all participating sub-systems should have consistent interpretation 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; Paslaru 2005; Bruijn and al 2008). Incompleteness, Ambiguity and Uncertainty: although incompleteness and ambiguity are characteristics most often associated with requirements engineering, in the area of adaptive systems 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 modelling techniques (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 well as textual notations should be available, etc. Alternative configuration selection: DiVA systems require a mechanism for evaluating alternative configurations against some given preferences. This mechanism should allow an easy, preferably automated, way of ranking the available alternative configurations. Though some user input may be necessary for this task (e.g., if new requirements have come up the relation 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 system has identified the need to update its configuration and has selected an alternative configuration to which it must migrate, it requires support for realising such a migration, relating to the need for run-time re-configurability, which, in turn requires the ability of the system to detect and resolve conflicts between requirements.
Version 0.1: Draft 20.10.2008 D1.1: Deliverable title Page 10 of 48
adapt. However, since humans do not even understand how they adapt, the software they design will be even less adaptive than humans themselves. This limitation of adaptability with human capacity to design for adaptability is termed adaptability envelope. It is this adaptability envelope that needs to be expanded to achieve better adaptability in systems.
should be enriched with additional notations, such as ; between AND goals to indicate left to right temporal order, or || to indicate parallel execution. Furthermore, in a separate work (Yu, Lapouchnian et al. 2008) the authors discuss how a goal model may be transformed into a set of feature models, statecharts, and component and connector models. Thus, they argue that the goal model may be used to represent stakeholdermotivated alternative solutions. These solutions can then transformed into initial set of design elements, which can be utilised for run-time adaptation of the system in accordance with the solution alternatives pre-designed in the goal model.