# Product Model Derivation from Feature Model and Formal Specification
## 3 Product Derivation Based on Feature Model and Specification Approach
### Product Model Derivation Approach
#### 3.3.2 Behavior Preserving Integration  
Serving as the most basic integration operation for each feature pair, behavior preserving integration will be repeatedly applied for the selected features to be integrated in order. Regarding functional scenario path as the representation of the feature behavior, we perform the behavior preserving integration on this basis. Behavior preserving integrates every declaration and process that occurs in the module to cover all possible functional scenario paths, where a start conditional process is a conditional process whose input data stream is not the output of any other conditional process in the same module. It can also be a source (a conditional process without any input data stream). A termination conditional process is a conditional process, whose output data stream is not input to any other conditional process in the same module. It includes _declaration integration_, _functional scenario path generation_, and _function integration based on path matching_. The steps of the method are shown in Figure 5. The first step integrates all types of variable declarations according  
Figure 4: The outline of the product derivation approach. to the integration rules. The second step derives all possible functional scenarios from the formal specification of the pair and then connects functional scenarios into scenario paths. Finally, the last step performs path matching according to the scenario paths, and the matching result guides the generation of integrated modules. ```
Input: feature module \(fm\), configuration \(c\) Output: pair sequence \(ps\)
1\(selected\)\(feature\gets c\);
2\(juniorNodeSets\gets fm\);
3// find all non-leaf nodes
4\(juniorTreeNode\gets fm-selected\)/\(feature\);
5 forjuniorTreeNode\(\in juniorNodeSets\)do
6 while\(\exists LeafNode\in juniorTreeNode\)do
7// merge leaf nodes under the same parent node
8\(juniorTreeNode\gets juniorTreeNode\cup leafNode\);
9
10 end if
11
12 end for
13\(nearestNeighbor\leftarrow\emptyset\);
14 while\(leafNodeSets.count\geq 2\)do
15// nearest neighbor search
16 for\(\exists leafTreeNode\in leafNodeSets\)do
17// find the leaf node with the closest relationship
18\(nearestNeighbor\gets leafTreeNode.find\)/\(juniorNodes.findLeafNodes\);
19// merge leaf nodes of nearest relatives
20\(leafTreeNode\gets leafTreeNode\cup nearestNeighbor\);
21\(ps\gets leafNodeSets\);
22
23 end for
24 return\(ps\)
```  
**Algorithm 1** Integration Ordering  
**Declaration integration**. Declarations contain mainly types and variables. Variables can represent values of basic or compound types (e.g., sets, sequences, maps, or composite types). Two type declarations with the same name and base type are overwritten, and only one is left. Composite types have many data items. We focus on composite types with intersecting data items. First, the declaration of the data items is analyzed in any two modules and then integrated according to the rules we give. Table 1 describes our proposed declaration integration rules to generate the same compound type variables as the original semantic from the relevant conditions involving the operation as mentioned above. Let s, s1, and s2 be any type, respectively. If the conditions in the table are satisfied, the actions will be executed. For example, the first and second rows of Table 1 indicate that if the domain/range of map s1 is satisfied by s2, then dom(s1) = s2 or rng(s1) = s2; the third row indicates if there is an intersection between map s1 and map s2, a new s will be generated, which is the union of s1 and s2; the fourth row indicates if there is an intersection between set s1 and set/com s2, the set s is the union (s1, s2); the fifth row indicates if sequence s1 and s2 partially overlap, the sequence s is conc(s1, s2); if set s1 and s2 partially overlap, then the composite s is the union(s1, s2). Figure 5: Integration of feature pairs. For type variables where two modules overlap exactly, we choose to retain one of them.