Figure 2 - uploaded by Catherine Dubois
Content may be subject to copyright.
Feature diagram of bank account product line 

Feature diagram of bank account product line 

Source publication
Article
Full-text available
Software Product Line Engineering (SPLE) is a software engineering paradigm that focuses on reuse and variability. Although feature-oriented programming (FOP) can implement software product line efficiently, we still need a method to generate and prove correctness of all product variants more efficiently and automatically. In this context, we propo...

Contexts in source publication

Context 1
... the distinction between mandatory and optional features is not relevant here. As a running example, we consider the bank account product line described in [17] whose feature diagram is shown in Figure 2. It illustrates a family of products allowing the management of bank accounts. ...
Context 2
... to the feature diagram of the bank account product line given in Figure 2, the feature module BA implements the root feature BA. Feature modules DL, LL, and Currency are mapped from the features DL, LL, and Currency respectively. ...
Context 3
... proposed language GFML is a solution to write the feature modules together with their artifacts more easily. We have followed with success this translation scheme for all the features appearing on the feature diagram of Figure 2. For the moment, the translation is done manually. ...

Citations

... The problematic is not new: in 1976 Parnas [Parnas 1976] named this kind of products "a program family" which is defined as "a set of programs whose common properties are so extensive that it is advantageous to study the common properties of the programs before analyzing individual members". Later, a program family is called Software Product Line (SPL) which is introduced by Bass et al. [Bass et al. 1998] as "a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way". ...
... Back [1978]. Similarly to this method, Parnas proposed another one, called sequential development [Parnas 1976], in which the variability is defined as the common properties of programs should be carried out before analyzing others of individual members. These authors also suggested to use generator(s) for program generation instead of implementing 1.1. ...
... Based on the survey publications about the analysis strategies used for theorem proving, we recognize that there are fewer publications for theorem proving than for model checking. Most of the publications, such as [ [Pham et al. 2015], have applied family-based strategy for theorem proving. It means that this research field should be still explored. ...
Thesis
We began the thesis by survey literature on SPLE and CbyC approaches in the State of the Art. Based on the overview and the insights obtained, we have analyzed the existing problems and suggested ways to solve them for our main goal. We have proposed in Chapter 2 a methodology to develop product lines such that the generated products are correct-by-construction. Our main intention is that a user does not need to know the product generation process but can receive a correct final product from selecting a configuration of features. Using the methodology, the final products are generated automatically and their correctness is guaranteed. Following this proposal, we have moved in Chapter 3 to define the FFML language that is used for writing modules. The reuse and modification mechanism, defined for the language and applied to all kinds of artifacts (specification, code and correctness proof), reduce the programming effort. In Chapter 4, we have focused on defining the composition mechanisms for composing FFML modules and embedded them into the FFML Product Generator tool. The evaluation of our methodology is performed through the development of two software product lines, the Bank Account SPL and the Poker SPL, the latter being a bit more complex than the former. In the evaluation, we have highlighted the advantages and the limitation of our methodology.
Article
Model composition is a crucial activity in Model Driven Engineering both to reuse validated and verified model elements and to handle separately the various aspects in a complex system and then weave them while preserving their properties. Many research activities target this compositional validation and verification (V & V) strategy: allow the independent assessment of components and minimize the residual V & V activities at assembly time. However, there is a continuous and increasing need for the definition of new composition operators that allow the reconciliation of existing models to build new systems according to various requirements. These ones are usually built from scratch and must be systematically verified to assess that they preserve the properties of the assembled elements. This verification is usually tedious but is mandatory to avoid verifying the composite system for each use of the operators. Our work addresses these issues, we first target the use of proof assistants for specifying and verifying compositional verification frameworks relying on formal verification techniques instead of testing and proofreading. Then, using a divide and conquer approach, we focus on the development of elementary composition operators that are easy to verify and can be used to further define complex composition operators. In our approach, proofs for the complex operators are then obtained by assembling the proofs of the basic operators. To illustrate our proposal, we use the Coq proof assistant to formalize the language-independent elementary composition operators Union and Substitution and the proof that the conformance of models with respect to metamodels is preserved during composition. We show that more sophisticated composition operators that share parts of the implementation and have several properties in common (especially: aspect oriented modeling composition approach, invasive software composition, and package merge) can then be built from the basic ones, and that the proof of conformance preservation can also be built from the proofs of basic operators.