-
Notifications
You must be signed in to change notification settings - Fork 2
Configuration Generation
This page explains how the configurations are generated to test the transformation depending on the framed features. This solution is a simplified method inspired by [1]. It uses requirements that can be seen in the table Requirements below. The requirements are tied to a configuration of its dependant feature. Features on which the require dont depend are not shown in the table. An algorithm goes through a list of the requirements and constructs complete configurations of requirements that dont contradict each other. This is done until every requirement is used once. The algorithm uses a set of a reduced number of features. This list can be seen in the table Reduced feature list. The value of the column Index indicates the position of the feature in the string representation which is used in the source code.
##Reduced feature list
| Index | Feature |
|---|---|
| 0 | Role_Properties/ Role_Behavior |
| 1 | Role_Inheritance |
| 2 | Compartments |
| 3 | Dates |
| 4 | Role_Implication |
| 5 | Role_Prohibtion |
| 6 | Role_Equivalence |
| 7 | Group_Constraints |
| 8 | Occurence_Constraints |
| 9 | Relationship |
| 10 | Relationship_Cardinality |
| 11 | Intra_Relationship_Constraints |
| 12 | Inter_Relationship_Constraints |
| 13 | Compartment_Types |
| 14 | Compartment_Properties/ Compartment_Behavior |
| 15 | Compartment_Inheritance |
| 16 | Playable_By_Defining_Compartment |
| 17 | Data_Types |
| 18 | Data_Type_Inheritance |
##Requirements
| Requirement | Description | Dependant Configuration |
|---|---|---|
| R1 | Role properties and operation are transformed | Role_Properties/ Role_Behavior |
| R2 | Role properties and operation are not transformed | !(Role_Properties/ Role_Behavior) |
| R3 | Role inheritances are transformed | Role_Inheritance |
| R4 | Role inheritances are not transformed | !(Role_Inheritance) |
| R5 | Fulfillments with compartment types as player are transformed | Compartments & Compartment_Types |
| R6_1 | Fulfillments with compartment types as player are not transformed | !(Compartments) & !(Compartment_Types) |
| R6_2 | !(Compartments) & Compartment_Types | |
| R7 | Fulfillments with data types as player are transformed | Dates & Data_Types |
| R8_1 | Fulfillments with data types as player are not transformed | !(Dates) & !(Data_Types) |
| R8_2 | !(Dates) & Data_Types | |
| R9 | Role implications are transformed | Role_Implication & Role_Equivalence |
| R10_1 | Role implications are not transformed | !(Role_Implication) & !(Role_Equivalence) |
| R10_2 | !(Role_Implication) & Role_Equivalence | |
| R11 | Role prohibitions are transformed | Role_Prohibtion |
| R12 | Role prohibitions are not transformed | !(Role_Prohibtion) |
| R13 | Role equivalences are transformed | same as R9 |
| R14_1 | Role equivalences are not transformed | same as R10_2 |
| R14_2 | same as R10_1 |
| R14_2 | | same as R10_1 | | R14_2 | | same as R10_1 | | R14_2 | | same as R10_1 | | R14_2 | | same as R10_1 | | R14_2 | | same as R10_1 | | R14_2 | | same as R10_1 |
[1] K.D. Scheidemann, Optimizing the selection of representative configurations in verification of evolving product lines of distributed embedded systems, in: Proceedings of the 10th International Software Product Line Conference (SPLC’06), 2006, pp. 75–84.