Feature-Oriented Techniques

Azzam Maraee Software-intensive systems come in many variants

Feature-Oriented Approaches

• Successful software reuse requires the systematic discovery and exploitation of commonality across related software systems. • Feature Oriented is an emerging discipline in which feature models are used to model the commonality and variability in a product family. • A feature is a prominent or distinctive user-visible aspect, quality, or characteristic of a software system or systems

Iris Reinhartz-Berger & Arnon Sturm © 5 2010 Feature

• Features are the concerns of primary interest in product-line engineering. • The concept of a feature is inherently hard to define precisely as it captures • intentions of the stakeholders of a product line, including end users • design and implementation-level concepts used to structure, vary, and reuse software artifacts. • Consequently, there are many definitions: • a product characteristic that is used in distinguishing programs within a family of related programs (Batory et al 2004) • a logical unit of behavior specified by a set of functional and non-functional requirements (Bosch (2000)) Feature

• A feature is a characteristic or end-user-visible behavior of a software system. • Features are used in product-line engineering to: • specify and communicate commonalities and differences of the products between stakeholders, and • to guide structure, reuse, and variation across all phases of the software life cycle. Feature-oriented software development (FOSD) • FOSD is a paradigm for the construction, customization, and synthesis of large-scale software systems. • The concept of a feature is at the heart of FOSD Thinking of your product line in terms of the features offered Examples of a Feature (Graph Product Line)

http://stg-tud.github.io/sedc/Lecture/ws16-17/6-SPL.pdf Feature Selection

• The product portfolio of a product line is defined by its features and their relations • A specific product is identified by a subset of features, called a feature selection • Not all feature selections are valid and specify meaningful products • A constraint on the feature selection is called a feature dependency

http://stg-tud.github.io/sedc/Lecture/ws16-17/6-SPL.pdf Product

A product of a product line is specified by a valid feature selection (a subset of the features of the product line). A feature selection is valid if and only if it fulfills all feature dependencies

http://stg-tud.github.io/sedc/Lecture/ws16-17/6-SPL.pdf Valid Products

http://stg-tud.github.io/sedc/Lecture/ws16-17/6-SPL.pdf A Process for Product-Line Development

• Most processes of traditional software engineering target the life cycle of a single software system. • Independent of the specifics of the process used, developers collect requirements for the target system, and design and implement the system, either in separate, consecutive phases or in agile cycles • For software product lines we have to look at a variety of desired systems that are similar but not identical. Overview of an engineering process for software product lines Overview of an engineering process for software product lines • Domain engineering: is the process of analyzing the domain of a product line and developing reusable artifacts. • Application engineering: has the goal of developing a specific product for the needs of a particular customer • It corresponds to the process of single application development in traditional software engineering, but reuses artifacts from domain engineering where possible Overview of an engineering process for software product lines • Domain analysis is a form of for an entire product line. Here, we need to decide the scope of the domain • Requirements analysis investigates the needs of a specific customer as part of application engineering. • In the simplest case, a customer’s requirements are mapped to a feature selection, based on the features identified during domain analysis. • Domain implementation is the process of developing reusable artifacts that correspond to the features identified in domain analysis • Product derivation (or product generation or product configuration or product assembly) is the production step of application engineering, where reusable artifacts are combined according to the results of requirement analysis. Domain scoping

• Domain scoping is the process of deciding on a product line’s extent or range. • Typically, management decides which of all possible requirements arising in a domain should be considered. • The scope describes desired features or specific products that should be supported. • For example, the focus may be on embedded database systems for a particular hardware architecture, instead of supporting multiple architectures. Embedded Data Management

• A product line should cover basic data management functionalities targeting different operating systems for embedded devices. • Management identifies transactions, recovery, encryption, basic queries, and data aggregation as the features that are most frequently requested • Neither SQL-style query optimization nor remote storage outside the device (for example, cloud storage) are considered • In a database product line, the feature for transaction management is selectable only if the database supports writing access since in a read- only database no transactions are needed Domain Modeling

• Domain modeling captures and documents the commonalities and variabilities of the scoped domain. • As a first approximation, stakeholders could give examples for possible products, as well as counter examples documenting which products are and which are not in the scope of the product line. • Typically, commonalities and differences between desired products are identified and documented in terms of features and their mutual dependencies What is variability

• Commonality The features shared by a set of products • Variability The features that differ between some pair of products https://www.slideserve.com/aimee/software-product-line-testing-part-ii-variability-modeling

Feature and variability Examples: the domain of embedded data management • We identify Storage, Transactions, Operating System, Encryption as features to support. • Only Storage and Operating System are mandatory • All other features are optional. • An example for restricting the possible products is that we cannot select more than one supported operating system at the same time. Examples: the graph library

• We consider feature GraphLibrary as the base feature • Then, we have two features DirectedEdges and UndirectedEdges • mutually exclusive. • we could think of features Search, either BFS or DFS, Weighted for weighted edges, and Algorithms. • As algorithms, we consider multiple optional features that are used in many but not all applications, such as Cycle detection, Shortest Path, minimal spanning trees (MST), and Transpose. Feature Modeling Feature Modeling

• A documents the features of a product line and their relationships • A feature represents typically a domain abstraction • Potential information that domain experts can collect on features: • Description of a feature and its corresponding (set of) requirements • Relationship to other features, especially hierarchy, order, and grouping • External dependencies, such as required hardware resources • Estimated or measured cost of realizing a feature • Potential feature interactions • .... • In feature-oriented design and implementation, feature diagrams are a standard visual representation, whose semantics is specified by a translation into propositional logic Feature

A filled bullet denotes a one-out-of many choice. This some-out-of-many mandatory feature choice corresponds to a choice. This choice corresponds An empty bullet denotes an generalized XOR operator to the logical or operator optional feature Feature modeling: An example Conflicting Feature

Two Features that cannot exist in the same product Dependent Feature

One Feature requires another Feature modeling: An example Feature modeling: An example Feature Modeling

C

Optional and Mandatory Features f1 f2 f3 f4 The root node represents concept, the remaining nodes represent features A mandatory feature is included in the description of a f5 f6 f7 f8 concept instance if its parent is included Mandatory Optional An optional feature may be included in the description feature feature of a concept instance if its parent is included in the description. {C, f1, f5, f2, f6, f3} {C, f1, f5, f2, f6, f3, f4} {C, f1, f5, f2, f6, f3, f7} {C, f1, f5, f3, f4, f8} {C, f1, f5, f3} …

Iris Reinhartz-Berger & Arnon Sturm © 36 2010 Feature-Oriented Domain Analysis (FODA) Domain Modeling – Feature Analysis

• Alternative and Or-Features C • Alternative features (one-of): If the parent of a set of alternative features is included in the description of a concept instance, then exactly f1 f2 f3 f4 f5 one feature from this set of alternative features is included. {C, f1, f3}, {C, f1, f4}, {C, f1, f5}, {C, f2, f3}, {C, f2, f4}, {C, f2, f5} • Or-features (more-of): If the parent of a set of or-

features is included in the description of a C concept instance, then any nonempty subset from the set of or-features is included.

f1 f2 f3 f4 f5 {C, f1, f3}, {C, f1, f2, f3}, {C, f1, f3, f4}, {C, f1, f3, f5}, {C, f1, f2, f4, f5}, {C, f1, f2, f3, f4, f5}, …

Iris Reinhartz-Berger & Arnon Sturm © 37 2010 33 optional features

A unique variant for every person in this planet More variants than estimated atoms in the 320 optional features universe

Configuration

• Configuration A feature configuration is a set of features which describes a member of an SPL: the member contains a feature if and only if the feature is in its configuration. • A feature configuration is permitted by a feature model if and only if it does not violate constraints imposed by the mode Semantics

• A model (Instance) of a FD is a subset of its nodes • A legal model, is a model that satisfies the FM constraints Semantics

• The semantics of a feature model is the set of feature configurations that the feature model permits. • The most common approach is to use propositional l logic to capture the semantics of a feature diagram. • Each feature corresponds to a Boolean variable and the semantics is captured as a propositional formula.

Feature-Oriented Domain Analysis (FODA) Domain Modeling – Feature Analysis The number of possible cars is 1*2*2*2*3=24

Iris Reinhartz-Berger & Arnon Sturm © 49 2010 Feature Diagram Legal Instances Feature-Oriented Domain Analysis (FODA) Domain Modeling – Feature Analysis Car Invalid Configuration instantiation Valid instantiation Car

Car Body Transmission Engine Horse Power Air Conditioning

Car Body Transmission Engine Horse Power

manual electric Medium Power

automatic manual electric Medium Power Valid Car instantiation

Car Invalid

Car Body Transmission Engine Horse Power Air Conditioning instantiation

Car Body Transmission Engine Horse Power

manual electric High Power

automatic manual electric Medium Power Low Power

Iris Reinhartz-Berger & Arnon Sturm © 51 2010 https://www.slideshare.net/schogglad/modeldriven-development-in-the-context-of-software-product-lines https://www.slideshare.net/schogglad/modeldriven-development-in-the-context-of- software-product-lines https://www.slideshare.net/schogglad/modeldriven-development-in-the-context-of- software-product-lines https://www.slideshare.net/schogglad/modeldriven-development-in-the-context- of-software-product-lines Analysis operations

• FM analysis helps in : • detecting inconsistencies • identifying dead features • identifying redundancies • optimizing FMs

Analysis operations on feature models

An inconsistent feature model Inconsistent features (Dead features, Grey features are inconsistent)

Some examples of false optional features. Grey features are false optional: all gray features are mandatory Redundancy problems: Grey constraints are redundant

Benavides, D., Segura, S. and Ruiz-Cortés, A., 2010. Automated analysis of feature models 20 years later: A literature review. Information Systems, 35(6), pp.615-636

Cardinality-based Feature Models- Extending Feature Diagrams with UML Multiplicities

Purchasing

1 1 1..* 0..1 1 Issue Purchase Purchase Request Validate Request Request Approval Purchase Order Order Request ControlSystem

1..* 1..* 1 1 0..1 * 1 Logger Sensor Controller ControlledDevice ControlledElement Monitoring Controlling

requires Domain Implementation Implementation Sven Apel, Christian K¨astner: An Overview of Feature-Oriented Software Development, in Journal of Object Technology, vol. 8, no. 4, July–August 2009, pages 1–36, http://www.jot.fm/issues/issues 2009 /

Domain Implementation

• Underlying code must be variable • Dimensions of implementation techniques • Binding times: compile-time binding, load-time binding and run-time binding. • Representation: annotation vs composition Domain Implementation