"Object-Oriented Programming (OOP), in the past two decades, has become the most influential and dominant programming paradigm for developing large and complex software systems. With OOP, developers can rely on design patterns that are widely accepted as solutions for recurring problems and used to develop flexible, reusable and modular software. However, recent studies have shown that Objected-Oriented Abstractions are not able to modularize these pattern concerns and tend to lead to programs with poor modularity. Feature-Oriented Programming (FOP) is an extension of OOP that aims to improve the modularity and to support software variability in OOP by refining classes and methods. In this thesis, based upon the work of integrating an online tutor systems, ASSISTments, with other online learning management systems, we evaluate FOP with respect to modularity. This proof-of-concept effort demonstrates how to reduce the effort in designing integration code."

Thesis (M.S.)--Worcester Polytechnic Institute. / Keywords: theorem proving; modular verification; software verification; feature-oriented programming; feature interaction. Includes bibliographical references (p. 131-136).

Thesis (M.S.)--Worcester Polytechnic Institute. / Keywords: modular verification; feature-oriented software development; model checking; assume-guarantee reasoning. Includes bibliographical references (p. 72-73).

Feature-oriented software architecture is a way of organizing code around the features that the program provides instead of the program's objects and components. In the development of a feature-oriented software system, the developers, supplied with a set of features, select and organize features to construct the desired system. This approach, by better aligning the implementation of a system with the external view of users, is believed to have many potential benefits such as feature reuse and easy maintenance. However, there are challenges in the formal verification of feature-oriented systems: first, the product may grow very large and complicated. As a result, it's intractable to apply the traditional formal verification techniques such as model checking on such systems directly; second, since the number of feature-oriented products the developers can build is exponential in the number of features available, there may be redundant verification work if doing verification on each product. For example, developers may have shared specifications on different products built from the same set of features and hence doing verification on these features many times is really unnecessary. All these drive the need for modular verifications for feature-oriented architectures. Assume-guarantee reasoning as a modular verification technique is believed to be an effective solution. In this thesis, I compare two verification methods of this category on feature-oriented systems and analyze the results. Based on their pros and cons, I propose a new modular model checking method to accomplish verification for sequential feature compositions with cyclic connections between the features. This method first builds an abstract finite state machine, which summarizes the information related to checking the property/specification from the concrete feature design, and then applies a revised CTL model checker to decide whether the system design can preserve the property or not. Proofs of the soundness of my method are also given in this thesis.

"Feature-oriented programming is a way of designing a program around the features it performs, rather than the objects or files it manipulates. This should lead to an extensible and flexible "product-line" architecture that allows custom systems to be assembled with particular features included or excluded as needed. Composing these features together modularly, while leading to flexibility in the feature-set of the finished product, can also lead to unexpected interactions that occur between features. Robert Hall presented a manual methodology for locating these interactions and has used it to search for feature interactions in email. Li et al. performed automatic verification of Hall's system using model-checking verifications tools. Model-checking verification is state-based, and is not well-suited for verifying recursive data structures, an area where theorem-proving verification tools excel. In this thesis, we propose a methodology for using formal theorem-proving tools for modularly verifying feature-oriented systems. The methodology presented captures the essential steps for using modular techniques for modeling and verifying a system. This enables verification of individual modules, without examining the source code of the other modules in the system. We have used Hall's email system as a test case for validating the methodology."

The Feature-Oriented Requirements Modelling (FORM) combines the requirement engineering style structuring of requirements documents with the feature-orientation of the Feature Oriented Software Development, resulting in a feature-oriented model of the functional requirements of a system-under-development (SUD). A feature is a distinguishable unit of added value to the SUD. The objectives of FORM are to model features as independent modules, to allow the addition of new features with minimal changes to the existing features, and to enable automatic generation and checking of properties like correctness, consistency, and non-determinism. FORM structures requirements into three models: a domain model, a collection of behavioural models, and a collection of functional models. A feature is modelled by a distinct behavioural model. This dissertation evaluates FORM by applying it to a new application that can be thought of in terms of features, namely an online trading system (OTS) that receives requests from customers about buying or selling securities on a stock market. The OTS offers variability in terms of the types of orders that customers can request, (e.g. market order, limit order and stop order). The case study revealed six deficiencies of the FORM notation, three of which were easily overcome. The dissertation presents the results of the case study, resolutions to three of the six deficiencies, and an outline of an approach to resolve the other three deficiencies.

A Software Product Line (SPL) is a family of related programs, which of each is defined by a combination of features. By developing related programs together, an SPL simultaneously reduces programming effort and satisfies multiple sets of requirements. Testing an SPL efficiently is challenging because a property must be checked for all the programs in the SPL, the number of which can be exponential in the number of features. In this dissertation, we present a suite of complementary static and dynamic techniques for efficient testing and runtime monitoring of SPLs, which can be divided into two categories. The first prunes programs, termed configurations, that are irrelevant to the property being tested. More specifically, for a given test, a static analysis identifies features that can influence the test outcome, so that the test needs to be run only on programs that include these features. A dynamic analysis counterpart also eliminates configurations that do not have to be tested, but does so by checking a simpler property and can be faster and more scalable. In addition, for runtime monitoring, a static analysis identifies configurations that can violate a safety property and only these configurations need to be monitored. When no configurations can be pruned, either by design of the test or due to ineffectiveness of program analyses, runtime similarity between configurations, arising due to design similarity between configurations of a product line, is exploited. In particular, shared execution runs all the configurations together, executing bytecode instructions common to the configurations just once. Deferred execution improves on shared execution by allowing multiple memory locations to be treated as a single memory location, which can increase the amount of sharing for object-oriented programs and for programs using arrays. The techniques have been evaluated and the results demonstrate that the techniques can be effective and can advance the idea that despite the feature combinatorics of an SPL, its structure can be exploited by automated analyses to make testing more efficient. / text

Frames sind parametrisierte Elemente zur Erzeugung von Programmen in einer beliebigen Zielprogrammiersprache. Ihre Handhabung ist einfach und schnell zu erlernen. Allerdings findet bei Verwendung von Frames eine “Verunreinigung” des Programmcodes, der als Basis für die Generatorentwicklung dient, mit Befehlen der Generatorsprache statt. Dies erschwert die Weiterverwendung der gewohnten Entwicklungsumgebung für die Zielprogrammiersprache. Eine eventuelle Weiterentwicklung der Programmbasis muss anschließend in Form von Frames erfolgen. Im Rahmen dieser Arbeit erfolgt die Beschreibung noninvasiver Frames, bei denen Informationen zur Position der Frames getrennt vom Programmcode aufbewahrt werden. Ihre Vermischung erfolgt in einem separaten Schritt zur Darstellung oder zur eigentlichen Codeerzeugung. Der Prozess der Generatorentwicklung auf der Basis noninvasiver Frames passt sich gut in die Prozesse von Merkmal-orientierter (FOSD) und Generativer Softwareentwicklung (GSE) ein, weil noninvasive Frames die automatisierte Prüfung aller mit dem Generator erzeugbaren Programme hinsichtlich Syntax und bestimmter semantischer Eigenschaften unterstützen und die Generierung durch Auswahl der gewünschten Programmeigenschaften ermöglichen. Die Machbarkeit der Entwicklung von Softwaregeneratoren mit noninvasiven Frames wird anhand zweier Fallstudien demonstriert.

Background: A key idea of feature orientation is to decompose a software product line along the features it provides. Feature decomposition is orthogonal to object-oriented decomposition it crosscuts the underlying package and class structure. It has been argued often that feature decomposition improves system structure (reduced coupling, increased cohesion). However, recent empirical findings suggest that this is not necessarily the case, which is the motivation for our empirical investigation. Aim: In fact, there is little empirical evidence on how the alternative decompositions of feature orientation and object orientation compare to each other in terms of their association with observable properties of system structure (coupling, cohesion). This motivated us to empirically investigate and compare the properties of three decompositions (object-oriented, feature-oriented, and their intersection) of 28 feature-oriented software product lines. Method: In an exploratory, observational study, we quantify internal attributes, such as import coupling and cohesion, to describe and analyze the different decompositions of a feature-oriented product line in a systematic, reproducible, and comparable manner. For this purpose, we use three established software measures (CBU, IUD, EUD) as well as standard distribution statistics (e.g., Gini coefficient). Results: First, feature decomposition is associated with higher levels of structural coupling in a product line than a decomposition into classes. Second, although coupling is concentrated in feature decompositions, there are not necessarily hot-spot features. Third, the cohesion of feature modules is not necessarily higher than class cohesion, whereas feature modules serve more dependencies internally than classes. Fourth, coupling and cohesion measurement show potential for sampling optimization in complex static and dynamic product-line analyses (product-line type checking, feature-interaction detection). Conclusions: Our empirical study raises critical questions about alleged advantages of feature decomposition. At the same time, we demonstrate how the measurement of structural attributes can facilitate static and dynamic analyses of software product lines. (authors' abstract) / Series: Technical Reports / Institute for Information Systems and New Media

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.