A Feature-Oriented Modelling Language and a Feature-Interaction Taxonomy for Product-Line Requirements
MetadataShow full item record
Many organizations specialize in the development of families of software systems, called software product lines (SPLs), for one or more domains (e.g., automotive, telephony, health care). SPLs are commonly developed as a shared set of assets representing the common and variable aspects of an SPL, and individual products are constructed by assembling the right combinations of assets. The feature-oriented software development (FOSD) paradigm advocates the use of system features as the primary unit of commonality and variability among the products of an SPL. A feature represents a coherent and identifiable bundle of system functionality, such as call waiting in telephony and cruise control in an automobile. Furthermore, FOSD aims at feature-oriented artifacts (FOAs); that is, software-development artifacts that explicate features, so that a clear mapping is established between a feature and its representation in different artifacts. The thesis first identifies the problem of developing a suitable language for expressing feature-oriented models of the functional requirements of an SPL, and then presents the feature-oriented requirements modelling language (FORML) as a solution to this problem. FORML's notation is based on standard software-engineering notations (e.g., UML class and state-machine models, feature models) to ease adoption by practitioners, and has a precise syntax and semantics to enable analysis. The novelty of FORML is in adding feature-orientation to state-of-the-art requirements modelling approaches (e.g., KAOS), and in the systematic treatment of modelling evolutions of an SPL via enhancements to existing features. An existing feature can be enhanced by extending or modifying its requirements. Enhancements that modify a feature's requirements are called intended feature interactions. For example, the call waiting feature in telephony intentionally overrides the basic call service feature's treatment of incoming calls when the subscriber is already involved in a call. FORML prescribes different constructs for specifying different types of enhancements in state-machine models of requirements. Furthermore, unlike some prominent approaches (e.g., AHEAD, DFC), FORML's constructs for modelling intended feature interactions do not depend on the order in which features are composed; this can lead to savings in analysis costs, since only one rather than (possibly) multiple composition orders need to be analyzed. A well-known challenge in FOSD is managing feature interactions, which, informally defined, are ways in which different features can influence one another in defining the overall properties and behaviours of their combination. Some feature interactions are intended, as described above, while other feature interactions are unintended: for example, the cruise control and anti-lock braking system features of an automobile may have incompatible affects on the automobile's acceleration, which would make their combination inconsistent. Unintended feature interactions should be detected and resolved. To detect unintended interactions in models of feature behaviour, we must first define a taxonomy of feature interactions for the modelling language: that is, we must understand the different ways that feature interactions can manifest among features expressed in the language. The thesis presents a taxonomy of feature interactions for FORML that is an adaptation of existing taxonomies for operational models of feature behaviour. The novelty of the proposed taxonomy is that it presents a definition of behaviour modification that generalizes special cases found in the literature; and it enables feature-interaction analyses that report only unintended interactions, by excluding interactions caused by FORML's constructs for modelling intended feature interactions.
Cite this version of the work
Pourya Shaker (2013). A Feature-Oriented Modelling Language and a Feature-Interaction Taxonomy for Product-Line Requirements. UWSpace. http://hdl.handle.net/10012/8100