ACCIDENTES DE TRABAJO CON Y SIN BAJA MÉDICA

Section 3.1.1 presented a variety of different evolutions for the feature model in the problem space. The following section inspects these evolutions and gives reasons for their classifica-tion. For this purpose, a brief recapitulation of the functionality of each evolution is presented.

Furthermore, the steps required for the remapping of the identified interspatial evolutions are explained.

The evolution Transform to Optional Feature modifies the cardinality of a feature to make it optional. Likewise, Transform to Mandatory Feature changes the cardinality of a feature to make it mandatory. Both evolutions alter the variation type of a feature and are thus considered intraspatial evolutions as they merely modify parameters of a feature, which has no effect on the mapping. In consequence, no remapping is required for Transform to Optional Feature and Transform to Mandatory Feature.

The Insert Feature evolution adds an entirely new feature to an existing group. It is classified as an intraspatial evolution. The reason is that the newly created feature has no relation to previously existing elements of the feature tree that might have a mapping. As a consequence, no remapping is required for the Insert Feature evolution.

On the other hand, the Duplicate Feature evolution is classified as an interspatial evolution of the first degree. The reason is the connection of the newly created feature and the originally selected feature. As the original feature is duplicated, there is clearly a relation to previously existing elements in the feature model. Should the original feature be part of at least one mapping, a remapping operation is required to update the feature mapping. In the case of duplicating a feature, it seems sound to also clone any existing mapping. Hence, the Copy Feature Mapping operator is used on the original feature for remapping. Furthermore, cloned child elements also have to be remapped. The ratio is the same as for the original feature so that Copy Feature Mapping is used in this case as well.

It is worth noting the elementary difference between Insert Feature and Duplicate Feature.

Even though both evolutions add a new feature to a group, they are classified as intraspatial and interspatial evolution respectively. The reason is that Insert Feature creates a completely new feature while Duplicate Feature clones an existing one. This shows that inspecting mere structural changes does not suffice for an appropriate classification that captures the effects on a product line. Instead, the intent of the changes has to be included in the process of classifying an evolution.

The Split Feature evolution refines a selected feature by dividing it into several parts. Ob-viously, the split parts have a logical connection to the original feature so that the original mapping has to be distributed as well. This makes Split Feature an interspatial evolution of the first degree. The subsequent remapping is performed by means of the Split Feature Mapping operator. In fact, the remapping decides the major part of the semantics of the Split Feature evolution. If solution space elements should appear in a variant only when features are selected

Table 3.10: Overview of classification and remapping of problem space evolutions.

Copy the mapping of the original feature to the new feature.

Split Feature interspatial (first degree)

Use split mapping to distribute the map-ping of the original feature to its constituent parts.

Merge Features interspatial (first degree)

Use merge mapping to combine the map-ping of the consituent parts on the target feature of the merge.

Pull Up Feature intraspatial

-Remove Feature interspatial (first degree)

Remove the mapping of the deleted fea-ture.

Remove Feature and Owned Assets

interspatial (second degree)

Remove the mapping of the deleted fea-ture, all owned assets and dependent el-ements in the solution space.

When features are duplicated with the groups, copy the mapping of the original features to the new features.

Merge Groups intraspatial

-in comb-ination, the split mapp-ing has to be connected by the AND operator. However, if the solution space elements should appear if either one (or even all) of a set of features is selected, the split mapping has to be connected by the OR operator. Furthermore, it is also possible that solution space elements are assigned to a single feature individually. In either case, these decisions depend on the desired outcome of the evolution and can not be automated. Instead, users are given the possibility of configuring the remapping. It is assumed that the sum of all individual parts satisfies the same requirements as the original feature did. Therefore, the default setting for the remapping operator is to reformulate the feature mappings by connecting all split parts with the AND operator. However, users may decide the details on how to redirect existing mappings.

During the course of melding two or more features as part of the Merge Features evolution, a new feature is created and the selected ones are removed. When merging with the parent feature, only the second step has to be performed. This type of modification has an effect on the mapping model as mappings to no longer existing elements must not remain in the model without being adapted. As a consequence, the Merge Features evolution is classified as an interspatial evolution of the first degree and thus requires remapping. The remapping operator that is used is Merge Feature Mapping, which can combine separate mappings. With the first

type of merge, the target of the remapping operator is the newly created feature. In the second case, it is the parent feature of the selected features.

Performing the Pull Up Feature evolution makes a feature independent of its parent by elevating it to the next highest level in the feature tree. To categorize the evolution, its modifi-cations to the feature model have to be inspected. During the evolution, features are relocated within the feature tree by detaching them from their old group and adding them to a new group.

Subsequently, the cardinality of the affected groups is altered. Neither of these two operations is problematic for the mapping as all features continue to exist in their original form. Further-more, the evolution might remove groups from the feature model if they are empty after the feature has been moved upwards. As groups are not allowed to have a mapping, this procedure is unproblematic for the mapping model as well. In consequence, Pull Up Feature is classified as an intraspatial evolution and thus does not require any remapping.

The Remove Feature evolution deletes a number of selected features from the feature tree. As the deleted features might have a mapping assigned to them, the evolution potentially affects the mapping model. If a mapped feature is removed, the mapping remaining in the system would be invalid because it applied to a no longer existing feature. Due to this fact, Remove Feature is considered an interspatial evolution of the first degree. Consequently, remapping is required in order to keep the mapping model intact. Therefore, Remove Feature Mapping is used on the originally selected as well as all child features. This remapping procedure ensures that no invalid mappings remain in the mapping model so that the consistency of the product line is maintained.

Applying Remove Feature and Owned Assets first removes a feature and all its descendants from the feature tree and then deletes the solution space elements that were assigned exclusively to those features as well. In other words, the evolution modifies both the problem and the solution space. Furthermore, the removal of elements from either space requires adapting the mappings of the deleted objects. In consequence, Remove Feature and Owned Assets is classified as an interspatial evolution. Due to its effect on both spaces, it is further considered to be of the second degree. The subsequent remapping employs Remove Feature Mapping to rid the mapping model of the no longer relevant mappings. As the deletion in the solution space also removes realization elements depending on the owned assets, a further object remapping might be necessary. For example, associations depending on the deleted elements are removed as well.

Therefore, the Remove Object Mapping step is employed for the additionally deleted solution space artifacts. Performing these remapping steps ensures the validity of the mapping model.

Besides the evolutions performed on features, there also is a number of evolutions for groups of a feature tree. For example, the evolutions Transform to Or Group, Transform to And Group and Transform to Alternative Group modify the variation type of a group. All of these evolutions are considered intraspatial for two reasons. First, they merely modify an existing element, which does not affect the mapping. Second, in the feature model of FeatureMapper, groups are not allowed to have a mapping assigned to them. As a consequence, changes that merely affect groups can not affect the mapping. Therefore, no remapping is required when using evolutions to change the variation type of groups.

The evolution Duplicate Group copies a selected group and its contents. In FeatureMapper, groups may not have a mapping, which means that modifications to them can never cause an

evolution to become interspatial. As a consequence, Duplicate Group might easily be perceived as an intraspatial evolution. However, a group may contain features that in turn are part of a mapping. When using the Duplicate Group evolution, contained features are copied as well. In this case, the evolution behaves similar to Duplicate Feature. This characteristic of Duplicate Group makes it an interspatial evolution of the first degree. In consequence, the evolution requires remapping. For this purpose, Copy Feature Mapping is used for all pairs of original and duplicate features in order to maintain the consistency of the product line.

Finally, the Merge Groups evolution relocates all features contained in the selected groups to one common group. Through this, it alters both groups and features. Thus, an individual inspection of both types of modifications is required for an appropriate classification. Chang-ing groups is generally unproblematic as groups can not have a mappChang-ing in FeatureMapper.

However, altering features might have an effect on the mapping model. In the particular case of Merge Groups, the modification to the features is unproblematic as merely their position in the feature tree is changed, which does not affect the mapping. Thus, Merge Groups is consid-ered an intraspatial evolution and thus does not require remapping. An overview of classifying evolutions in the problem space can be found in Table 3.10.