Figure 1 - uploaded by Ferruccio Damiani
Content may be subject to copyright.
Source publication
Delta-oriented programming (DOP) is a modular approach for implementing software product lines. Delta modules generalize feature modules by allowing removal of functionality. However, DOP requires to select one particular product as core product from which all products are generated. In this paper, we propose pure delta-oriented programming (Pure D...
Contexts in source publication
Context 1
... features Add, Neg and Eval are optional. Figure 1 shows the feature model [16] of the EPL. ...
Context 2
... that we have already developed a prod- uct containing the Lit, Neg and Print features and a product con- taining the Lit, Add and Print features. Now, we want to transform these existing legacy applications into a product line according to the feature model in Figure 1. ...
Context 3
... 10 shows the extractive implementation of the product line described by the feature model in Figure 1 starting from a prod- uct with features Lit, Neg and Print and a product with features Lit, Add, and Print introduced by the delta modules DLitNegPrint and DLitAddPrint in the first and second partitions, respectively. Their application conditions are exclusive such that for any feature configuration product generation starts with one of them. ...
Similar publications
![Figure 1. Calculator Application [10]](profile/Saad-Bin-Abid/publication/234799462/figure/fig22/AS:393501046001664@1470829368056/Calculator-Application-10_Q320.jpg)
Features implementing the functionality in a software product line (SPL) often interact and depend on each other. It is hard to maintain the consistency between feature dependencies on the model level and the actual implementation over time, resulting in inconsistency during product derivation. We describe our initial results when working with feat...
Citations
... Lam et al. [14] emphasize the need for tool support to manage package modifications and the importance of analyzing compatibility through program analysis. Delta-oriented programming [24][25][26] could complement this approach by facilitating the way modularizing addition, overriding, and removal of programming elements and include application conditions for those modifications. This could result in a sophisticated package system that provides granular compatibility information. ...
Programming with versions is a paradigm that allows a program to use multiple versions of a module so that the programmer can selectively use functions from both older and newer versions of a single module. Previous work formalized $$\lambda _{\textrm{VL}}$$ λ VL , a core calculus for programming with versions, but it has not been integrated into practical programming languages. In this paper, we propose VL, a Haskell-subset surface language for $$\lambda _{\textrm{VL}}$$ λ VL along with its compilation method. We formally describe the core part of the VL compiler, which translates from the surface language to the core language by leveraging Girard’s translation, soundly infers the consistent version of expressions along with their types, and generates a multi-version interface by bundling specific-version interfaces. We conduct a case study to show how VL supports practical software evolution scenarios and discuss the method’s scalability.
... ABS is a specification for modeling the behavior of concurrent and distributed processes of software systems in a Java-like syntax. Following SPLE and delta-oriented programming [69,70], functional variability is modeled using a feature model for a delta-oriented base model. Selected features are linked to deltas which are applied to the base model to derive the desired product. ...
For automating the deployment of composite applications, typically, declarative deployment models are used. Depending on the context, the deployment of an application has to fulfill different requirements, such as costs and elasticity. As a consequence, one and the same application, i.e., its components, and their dependencies, often need to be deployed in different variants. If each different variant of a deployment is described using an individual deployment model, it quickly results in a large number of models, which are error prone to maintain. Deployment technologies, such as Terraform or Ansible, support conditional components and dependencies which allow modeling different deployment variants of a composite application in a single deployment model. However, there are deployment technologies, such as TOSCA and Docker Compose, which do not support such conditional elements. To address this, we extend the Essential Deployment Metamodel (EDMM) by conditional components and dependencies. EDMM is a declarative deployment model which can be mapped to several deployment technologies including Terraform, Ansible, TOSCA, and Docker Compose. Preprocessing such an extended model, i.e., conditional elements are evaluated and either preserved or removed, generates an EDMM conform model. As a result, conditional elements can be integrated on top of existing deployment technologies that are unaware of such concepts. We evaluate this by implementing a preprocessor for TOSCA, called OpenTOSCA Vintner, which employs the open-source TOSCA orchestrators xOpera and Unfurl to execute the generated TOSCA conform models.
... Each delta comprises delta operations that can add, modify or remove named elements in the base program (e.g. for Java programs, a delta can add, remove or modify class interfaces, fields and methods [34]). As pointed out in [44], thanks to this flexible operations, DOP supports proactive (i.e. planning all products in advance), reactive (i.e. ...
... 6.1] SPL implementation approach can be described as a restriction of DOP where deltas are associated one-to-one with features and have limited expressive power: they can add and modify program elements; however, they cannot remove them (see, e.g. [44] for a detailed comparison between DOP and FOP). Refactoring algorithms for FOP have been proposed in [2,39]. ...
Delta-oriented programming (DOP) is a flexible transformational approach to implement software product lines (SPLs). In delta-oriented SPLs, variants are generated by applying operations contained in delta modules to a base program. These operations can add, remove or modify named elements in a program (e.g. classes, methods and fields in a Java program). This paper presents two notions of normal form for delta-oriented SPLs. Both normal forms do not contain the remove operation. Additionally, the second normal form enforces a limitation on the use of the method-modify operation. For each of the proposed normal forms an algorithm for refactoring a delta-oriented SPL into one that satisfies that normal form is described. The algorithms are formalized for a core calculus for delta-oriented SPLs of Java programs.
... Feature-context interfaces [22] are aimed at preventing type errors in SPLs developed according to the FOP approach which, as pointed out in Section 1, is encompassed by DOP (see [23] for a detailed comparison between FOP and DOP). A feature-context interface supports preventing type errors in the context of a set of features FC. ...
A Software Product Line (SPL) is a family of similar programs generated from a common artifact base. A Multi SPL (MPL) is a set of interdependent SPLs that are typically managed and developed in a decentralized fashion. Delta-Oriented Programming (DOP) is a flexible and modular approach to implement SPLs. This paper presents new concepts that extend DOP to support the implementation of MPLs. These extensions aim to accommodate compositional analyses. They are presented by means of a core calculus for delta-oriented MPLs of Java programs. Suitability for MPL compositional analyses is demonstrated by compositional reuse of existing SPL analysis techniques.
... A delta module encapsulates modifications to an object-oriented program. A particular product in a deltaoriented SPL is generated by applying the modifications contained in the suitable delta modules to a core program that, without loss of generality, can always be assumed to be empty [55]. A dynamic delta-oriented SPL adds to these a dynamic reconfiguration graph defining which configurations the system can adapt to at runtime and describing how existing objects need to be reconfigured in case they are instances of classes changed by the reconfiguration. ...
... Before or after the original construct, other statements can be introduced to wrap the existing method implementation. In addition to proactive product line development (building a product line entirely anew), DOP also supports extractive product line development [45], starting from an existing legacy product [55]. ...
... Therefore, it could be used to model dynamic feature composition at run time. As DOP is an extension of FOP [55], the mechanism for runtime adaptation and dynamic evolution of product lines proposed in this article can also be applied to FOP product lines. ...
Delta-oriented programming (DOP) is a flexible approach to the implementation of software product lines (SPLs). Delta-oriented SPLs consist of a code base (a set of delta modules encapsulating changes to object-oriented programs) and a product line declaration (providing the connection of the delta modules with the product features). In this paper, we present a core calculus that extends DOP with the capability to switch the implemented product configuration at runtime. A dynamic delta-oriented SPL is a delta-oriented SPL with a dynamic reconfiguration graph that specifies how to switch between different feature configurations. Dynamic DOP supports also (unanticipated) software evolution such that at runtime, the product line declaration, the code base and the dynamic reconfiguration graph can be changed in any (unanticipated) way that preserves the currently running product, which is essential when evolution affects existing features. The type system of our dynamic DOP core calculus ensures that the dynamic reconfigurations lead to type safe products and do not cause runtime type errors.
... In particular, they outline the notion of syntactical interfaces to provide a view of reusable programming artifacts, as well as behavioral interfaces that build on syntactical interfaces to support formal verification. Schröter et al. [25] propose feature-context interfaces aimed at supporting type checking SPLs developed according to the FOP approach which, as pointed out in Sect. 1, is encompassed by DOP (see [21] for a detailed comparison between FOP and DOP). A feature-context interface supports type checking of a feature module in the context of a set of features FC. ...
Software Product Lines (SPLs) are an established area of research providing approaches to describe multiple variants of a software product by representing them as a highly variable system. Multi-SPLs (MPLs) are an emerging area of research addressing approaches to describe sets of interdependent, highly variable systems, that are typically managed and developed in a decentralized fashion. Current approaches do not offer a mechanism to manage and orchestrate multiple variants from one product line within the same application. We experienced the need for such a mechanism in an industry project with Deutsche Bahn, where we do not merely model a highly variable system, but a system with highly variable subsystems. Based on MPL concepts and delta-oriented oriented programming, we present a novel solution to the design challenges arising from having to manage and interoperate multiple subsystems with multiple variants: how to reference variants, how to avoid name or type clashes, and how to keep variants interoperable.
... Feature-context interfaces [26] are aimed at supporting type checking SPLs developed according to the FOP approach which, as pointed out in Sect. 1, is encompassed by DOP (see [22] for a detailed comparison between FOP and DOP). A feature-context interface supports type checking a feature module in the context of a set of features FC. ...
A Software Product Line (SPL) is a family of similar programs generated from a common artifact base. A Multi SPL (MPL) is a set of interdependent SPLs that are typically managed and developed in a decentralized fashion. Delta-Oriented Programming (DOP) is a flexible and modular approach to implement SPLs. This paper presents new concepts that extend DOP to support the implementation of MPLs. These extensions aim to accommodate compositional analyses. They are presented by means of a core calculus for delta-oriented MPLs of Java programs. Suitability for MPL compositional analyses is demonstrated by compositional reuse of existing SPL analysis techniques.
... Delta tables are used to define a notion of "delta module for FineFit specifications" (i.e., a construct that describes how to modify the FineFit specification of a product to obtain the FineFit specification of another product), that we call delta-table module. Delta tables are illustrated 1 A straightforward embedding of FOP into DOP is illustrated, e.g., in [11]. and evaluated (in terms of their support to conciseness and readability of SPL specifications) by considering a small SPL as a case study that is used as a running example throughout the paper. ...
... Products { ... / * Same as in Listing 4 * / } 12 } Listing 10: DeltaJ 1.5 product-line declaration for the complex-core implementation of the Album PL features (see [8,11]). More general, DOP is well suited to support the following SPL development approaches: proactive (i.e., all reusable artifacts are planned and developed in advance), reactive (i.e., only a basic set of products is planned and developed-when new customer requirements arise, the existing SPL is evolved), and extractive (i.e., turning a set of existing applications into an SPL); whereas FOP supports only the proactive approach. ...
... , c k . 11 The values of c i are denoted by op(c i ). We omit writing "c 0 :" when possible. ...
Model-based testing relies on a model of the system under test. FineFit is a framework for model-based testing of Java programs. In the FineFit approach, the model is expressed by a set of tables based on Parnas tables. A software product line is a family of programs (the products) with well-defined commonalities and variabilities that are developed by (re)using common artifacts. In this paper, we address the issue of using the FineFit approach to support the development of correct software product lines. We specify a software product line as a specification product line where each product is a FineFit specification of the corresponding software product. The main challenge is to concisely specify the software product line while retaining the readability of the specification of a single system. To address this, we used delta-oriented programming, a recently proposed flexible approach for implementing software product lines, and developed: (1) delta tables as a means to apply the delta-oriented programming idea to the specification of software product lines; and (2) DeltaFineFit as a novel model-based testing approach for software product lines.
... Finally, the core product can be an empty product. In this case, the approach is called Pure Delta Oriented Programming [18]. ...
... Second, to deal with domain implementation we propose a compositional approach based on the Pure Delta-oriented programming [18], in which process derivation relies on the application of process delta modules over an empty process. Process delta modules are connected to the feature model by means of the attached application conditions. ...
... Moreover, the modification proposed by a process delta module consists of the addition and/or removals of process fragments. Additionally, by using process delta modules we can define the partially-ordered sequence in which process fragments will appear in the process variant: process delta modules are grouped in fixed-ordered partitions, and process delta modules in the same partition can be applied in any order, as suggested in [17] [18]. Therefore, by adopting the Pure Delta-oriented programming our approach covers an important issue of software process derivation: software processes are represented as a partially-ordered sequence of work, as mentioned in Section II. ...
... Instead, DOP allows to use arbitrary code as a base program. For example, the base program can be empty and different variants can be used as base delta modules with pairwise disjoint activation conditions [20]. Therefore, DOP supports both proactive SPL development (i.e., planning all products/variants in advance) and extractive SPL development [15] (i.e., starting from existing programs). ...
A Software Product Line (SPL) is a set of similar programs generated from a common code base. Delta Oriented Programming (DOP) is a flexible approach to implement SPLs. Efficiently type checking an SPL (i.e., checking that all its programs are well-typed) is challenging. This paper proposes a novel type checking approach for DOP. Intrinsic complexity of SPL type checking is addressed by providing early detection of type errors and by reducing type checking to satisfiability of a propositional formula. The approach is tunable to exploit automatically checkable DOP guidelines for making an SPL more comprehensible and type checking more efficient. The approach and guidelines are formalized by means of a core calculus for DOP of product lines of Java programs.
