Ferruccio Damiani

Delta-oriented programming of software product lines

Feature-oriented programming (FOP) implements software product lines by composition of feature modules. It relies on the principles of stepwise development. Feature modules are intended to refer to exactly one product feature and can only extend existing implementations. To provide more flexibility for implementing software product lines, we propose delta-oriented programming (DOP) as a novel programming language approach. A product line is represented by a core module and a set of delta modules. The core module provides an implementation of a valid product that can be developed with well-established single application engineering techniques. Delta modules specify changes to be applied to the core module to implement further products by adding, modifying and removing code. Application conditions attached to delta modules allow handling combinations of features explicitly. A product implementation for a particular feature configuration is generated by applying incrementally all delta modules with valid application condition to the core module. In order to evaluate the potential of DOP, we compare it to FOP, both conceptually and empirically.

Fickle: Dynamic Object Re-classification

Re-classification changes at run-time the class membership of an object while retaining its identity. We suggest language features for object re-classification, which could extend an imperative, typed, classbased, object-oriented language.We present our proposal through the language Fickle. The imperative features combined with the requirement for a static and safe type system provided the main challenges. We develop a type and effect system for Fickle and prove its soundness with respect to the operational semantics. In particular, even though objects may be re-classified across classes with different members, they will never attempt to access nonexisting members.

More dynamic object reclassification: Fickle p

Reclassification changes the class membership of an object at run-time while retaining its identity. We suggest language features for object reclassification, which extend an imperative, typed, class-based, object-oriented language.We present our proposal through the language Fickle⋄⋄. The imperative features, combined with the requirement for a static and safe type system, provided the main challenges. We develop a type and effect system for Fickle⋄⋄ and prove its soundness with respect to the operational semantics. In particular, even though objects may be reclassified across classes with different members, there will never be an attempt to access nonexisting members.

Formal Verification of Object-Oriented Software

This book presents the thoroughly refereed post-conference proceedings of the International Conference on Formal Verification of Object-Oriented Software, FoVeOOS 2010, held in Paris, France, in June 2010 - organised by COST Action IC0701. The 11 revised full papers presented together with 2 invited talks were carefully reviewed and selected from 21 submissions. Formal software verification has outgrown the area of academic case studies, and industry is showing serious interest. The logical next goal is the verification of industrial software products. Most programming languages used in industrial practice are object-oriented, e.g. Java, C++, or C#. FoVeOOS 2010 aimed to foster collaboration and interactions among researchers in this area

Pure delta-oriented programming

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 DOP) that is a conceptual simplification of traditional DOP. In Pure DOP, the requirement of one designated core product is dropped. Instead, program generation only relies on delta modules comprising program modifications such that Pure DOP is more flexible than traditional DOP. Furthermore, we show that Pure DOP is a true generalization of FOP and supports proactive, reactive and extractive product line engineering.

Compositional type-checking for delta-oriented programming

Delta-oriented programming is a compositional approach to flexibly implementing software product lines. A product line is represented by a code base and a product line declaration. The code base consists of a set of delta modules specifying modifications to object-oriented programs. The product line declaration provides the connection of the delta modules with the product features. This separation increases the reusability of delta modules. In this paper, we provide a foundation for compositional type checking of delta-oriented product lines of Java programs by presenting a minimal core calculus for delta-oriented programming. The calculus is equipped with a constraint-based type system that allows analyzing each delta module in isolation, such that that also the results of the analysis can be reused. By combining the analysis results for the delta modules with the product line declaration it is possible to establish that all the products of the product line are well-typed according to the Java type system.

Polymorphic bytecode: compositional compilation for Java-like languages

We define compositional compilation as the ability to typecheck source code fragments in isolation, generate corresponding binaries,and link together fragments whose mutual assumptions are satisfied, without reinspecting the code. Even though compositional compilation is a highly desirable feature, in Java-like languages it can hardly be achieved. This is due to the fact that the bytecode generated for a fragment (say, a class) is not uniquely determined by its source code, but also depends on the compilation context.We propose a way to obtain compositional compilation for Java, by introducing a polymorphic form of bytecode containing type variables (ranging over class names) and equipped with a set of constraints involving type variables. Thus, polymorphic bytecode provides a representation for all the (standard) bytecode that can be obtained by replacing type variables with classes satisfying the associated constraints.We illustrate our proposal by developing a typing and a linking algorithm. The typing algorithm compiles a class in isolation generating the corresponding polymorphic bytecode fragment and constraints on the classes it depends on. The linking algorithm takes a collection of polymorphic bytecode fragments, checks their mutual consistency, and possibly simplifies and specializes them. In particular, linking a self-contained collection of fragments either fails, or produces standard bytecode (the same as would have been produced by standard compilation of all fragments).

Compositional type checking of delta-oriented software product lines

Delta-oriented programming is a compositional approach to flexibly implementing software product lines. A product line is represented by a code base and a product line declaration. The code base consists of a set of delta modules specifying modifications to object-oriented programs. A particular product in a delta-oriented product line is generated by applying the modifications contained in the suitable delta modules to the empty program. The product-line declaration provides the connection of the delta modules with the product features. This separation increases the reusability of delta modules. In this paper, we provide a foundation for compositional type checking of delta-oriented product lines of Java programs by presenting a minimal core calculus for delta-oriented programming. The calculus is equipped with a constraint-based type system that allows analyzing each delta module in isolation, such that the results of the analysis can be reused. By relying only on the analysis results for the delta modules and on the product line declaration, it is possible to establish whether all the products of the product line are well typed according to the fragment of the Java type system modeled by the calculus.

Implementing software product lines using traits

A software product line (SPL) is a set of software systems with well-defined commonalities and variabilities that are developed by managed reuse of common artifacts. In this paper, we present a novel approach to implement SPL by fine-grained reuse mechanisms which are orthogonal to class-based inheritance. We introduce the Featherweight Record-Trait Java (FRTJ) calculus where units of product functionality are modeled by traits, a construct that was already shown useful with respect to code reuse, and by records, a construct that complements traits to model the variability of the state part of products explicitly. Records and traits are assembled in classes that are used to build products. This composition of product functionalities is realized by explicit operators of the calculus, allowing code manipulations for modeling product variability. The FRTJ type system ensures that the products in the SPL are type-safe by type-checking only once the records, traits and classes shared by different products. Moreover, type-safety of an extension of a (type-safe) SPL can be guaranteed by checking only the newly added parts.

DeltaJ 1.5: delta-oriented programming for Java 1.5

Delta-oriented programming (DOP) is a modular, yet flexible approach to implement software product lines. In DOP, a product line is implemented by a set of deltas, which are containers of modifications to a program. A delta-oriented product line is specified by its code base, i.e., the set of delta modules, and a product line declaration specifying the set of possible product variants. In this paper, we present DOP for Java 1.5 extending previous proof-of-concept realizations of DOP for simple core Java-like languages. The novel prototypical implementation DeltaJ 1.5 provides full integrated access to the object-oriented features of Java. The extensions include delta operations to fully integrate the Java package system, to declare and modify interfaces, to explicitly change the inheritance hierarchy, to access nested types and enum types, to alter field declarations, and to unambiguously remove overloaded methods. Furthermore, we improve the specification of the product line declaration by providing a separate language. We have evaluated DeltaJ 1.5 using a case study.