During the course of the example project, the applicability of the evolution system of this thesis was demonstrated for a practical scenario. Modifications were performed for the feature tree in the problem space as well as various models in the solution space. In particular, three different types of solution space models were used: UML design models, Java source code and DocBooklet documentation. These models serve as examples of three essential types of artifacts in the software development process. Each of the demonstrated models was subject to change over the course of time so that the possibility arose to apply the evolutions presented in the thesis. The evolutions were used in a number of different scenarios including the creation of new content as well as the modification and removal of existing elements. Where feasible, the evolutions were configured using parameter pages to match the concrete use case. In consequence, only few manual modifications of the models were required to perform the projected alterations. Furthermore, applying the evolutions for the variation type of features to multiple features at once avoided having to use the same evolution multiple times, which proved to increase productivity.
Besides the general usefulness of the evolution system, the applicability of particular evolu- tions was demonstrated as well. During the course of the thesis, a total of 37 evolutions was introduced. However, 14 evolutions for DocBooklet are largely similar in nature and thus can be grouped. With the 4 groups of DocBooklet evolutions presented in Section 3.1.2.3, this leaves 27 unique modifications. Their application areas reach from the feature tree in the problem space to UML models, Java source code and DocBooklet documentation in the solution space. Out of the 27 unique evolutions, 16 were demonstrated in the example project encompassing all four types of target model. The remaining 11 evolutions were not used because the need for these particular modifications did not arise during the regular course of the example. Thus, it would have been necessary to extend the scope of the project to require additional evolutions. Most likely, the construction of further scenarios would have made the project seem artificial, which is in contrast to the original goal of creating an example that is close to real world application. Furthermore, the evolutions applied during the project suffice to provide an insight into the usage and usefulness of the evolution system so that it was refrained from demonstrating every single introduced evolution. Nonetheless, the remaining 11 evolutions are fully operational and can be applied if the need arises.
During the course of the example project, the evolution system successfully coped with different use cases and multiple evolutions were applied. To overcome the challenges posed by
Table 5.16: Complete feature mapping for the automotive multimedia product line at the end of the 2011 revision.
AudioPlayer UML:Class[AudioPlayer]
AudioPlayer UML:Association[UserInterface-AudioPlayer] AudioPlayer OR PersonalNavigation UML:Class[Speakers]
AudioPlayer UML:Association[AudioPlayer-Speakers] AudioPlayer OR PersonalNavigation UML:Class[VolumeControl]
AudioPlayer OR PersonalNavigation UML:Association[VolumeControl-Speakers] AudioPlayer Manual:Chapter[AudioPlayer] AudioPlayer Java:Class[UIBuilder]:Method[createUI]:Call[2] AudioPlayer Java:Class[UIBuilder]:Method[createAudioPlayerMenu] Radio UML:Class[RadioTuner] Radio UML:Association[AudioPlayer-RadioTuner] CDPlayer UML:Class[CDPlayer] CDPlayer UML:Association[AudioPlayer-CDPlayer] CDPlayer Manual:Section[AudioCDPlayback] CDPlayer UML:Association[CDPlayer-MP3Decoder] CDPlayer Manual:Section[MP3CDPlayback] OnBoardComputer UML:Class[OnBoardComputer] OnBoardComputer UML:Association[OnBoardComputer-Display] OnBoardComputer UML:Association[UserInterface-OnBoardComputer] OnBoardComputer Manual:Chapter[OnBoardComputer] OnBoardComputer Java:Class[UIBuilder]:Method[createUI]:Call[1] OnBoardComputer Java:Class[UIBuilder]:Method[createOnBoardComputerMenu] PersonalNavigation UML:Class[PersonalNavigation] PersonalNavigation UML:Association[PersonalNavigation-Speakers] PersonalNavigation UML:Association[PersonalNavigation-Display] PersonalNavigation UML:Association[UserInterface-PersonalNavigation] PersonalNavigation Java:Class[UIBuilder]:Method[createUI]:Call[3] PersonalNavigation Java:Class[UIBuilder]:Method[createPersonalNavigationMenu] VoiceRecognition UML:Class[VoiceRecognition] VoiceRecognition UML:Association[VoiceRecognition-VoiceControllable] VoiceRecognition UML:Class[VoiceControllable]:Method[receiveVoiceCommand] VoiceRecognition UML:Class[VoiceControllable] Europe NavMap:Country[Germany] Europe NavMap:Country[Poland] NorthAmerica NavMap:Country[USA] NorthAmerica NavMap:Country[Canada] CentralAmerica NavMap:Country[Mexico] CentralAmerica NavMap:Country[Costa Rica] SouthAmerica NavMap:Country[Argentina] SouthAmerica NavMap:Country[Brazil]
Asia NavMap:Country[Japan]
the project, it was not necessary to modify the implementation presented in Section 4.2. Due to these points and the extensive nature of the example, the evolution system is regarded as being applicable to real world scenarios.
Chapter 6
Conclusion
This final chapter concludes the work of the thesis. First, a summary of the theoretical and practical part as well as the example project will be presented. Then, limitations of the evolution system at its current stage of development will be discussed. After that, possibilities for future work will be introduced. Finally, the chapter will close with an explanation of the theoretical and practical contributions of the thesis.
6.1
Summarized Findings
The theoretical work featured extensive explanations of a wide variety of evolutions for various target models. For one, there are 14 evolutions defined in the problem space, which modify the feature tree. Furthermore, three different types of models were targeted in the solution space, which serve as examples of typical artifacts of the software development process. For UML models, 5 evolutions were provided. For the Java programming language, 4 modifications were defined and for the DocBooklet documentation format, 14 evolutions were specified, which can be put into 4 groups. This wide variety of different evolutions provides a basis for the modification of software product lines.
Besides introducing individual evolutions, a number of classification systems for evolutions was discussed. It was argued that grouping evolutions by whether they maintain behavior or not is unsatisfactory when trying to capture the effect on the product line. Furthermore, a variety of additional classification systems was found to be equally unsuitable for this purpose for various reasons. In consequence, a new classification was introduced to capture the effect of evolutions on a software product line, which features two major groups of evolutions. Intraspatial evolutions have an effect that is contained within the space the evolution was triggered from so that the mapping of the product line is not affected. On the other hand, interspatial evolutions perform modifications whose logical extent reaches beyond the originating space. The latter group is further divided into interspatial evolutions of the first and second degree. Evolutions of the first degree affect the originally targeted space whereas evolutions of the second degree modify both spaces. Additionally, each interspatial evolution affects the mapping, which connects the adjacent spaces. Thus, for interspatial evolutions, the mapping has to be adapted in order to maintain the consistency of the product line.
For this purpose, a total of 8 remapping operators was specified. As the remapping procedure
differs in the problem and solution space, individual operators for either side were provided. In the problem space, there are operators to move, copy and remove as well as to split and merge mappings. For the solution space, operators to move, copy and remove were defined analog to those in the problem space. Finally, all presented evolutions were inspected to identify them as either intraspatial or interspatial evolutions so that they could be attributed to their respective group in the classification system. For interspatial evolutions, the individual steps necessary for remapping were explained in detail. With the provided remapping steps, it is possible to apply evolutions to software product lines without jeopardizing the consistency of the mapping.
In addition to the theoretical part of the thesis, the practical realization of the evolution system was discussed. An architectural overview of the implementation provided information on the structure of the subsystems. For each of the subsystems, individual classes with their responsibilities were explained. Furthermore, the test suite used to validate the implementa- tion was discussed. Within the remapping subsystem, the object remapping specification was introduced. It allows to adapt evolutions to the use within software product lines even if the original modification was not designed for this purpose. Finally, the practical part gave detailed instructions on how to extend the evolution system with further modifications for the problem as well as the solution space if the need should arise.
Both the theoretical and practical results were put to test in an extensive example project, which described the change of an automotive multimedia system over the course of time. The majority of the presented evolutions was applied to perform the required modifications. Each of the evolutions was executed successfully and a modification of the existing implementation was not required. Besides the evolutions, only few manual modifications were required. Overcoming the challenges posed by the example project showed the applicability and usefulness of the evolution system.