Multi attribute architecture design decision for core asset derivation

Software Product Line (SPL) is an effective approach in software reuse in which core assets can be shared among the members of the product line with an explicit treatment of variability. Core assets, which are developed for reuse in domain engineering, are selected for product specific derivation in application engineering. Decision making support during product derivation is crucial to assist in making multiple decisions during product specific derivation. Multiple decisions are to be resolved at the architectural level as well as the detailed design level, address the need for assisting the decision making process during core asset derivation. Architectural level decision making is based on imprecise, uncertain and subjective nature of stakeholder for making architectural selection based on non- functional requirements (NFR). Furthermore, detail design level involves the selection of suitable features which have the rationale behind each decision. The rationale for the selection, if not documented properly, will also result in loss of tacit knowledge. Therefore, a multi-attribute architecture design decision technique is proposed to overcome the above mentioned problem. The technique combines Fuzzy Analytical Hierarchy Process (FAHP) with lightweight architecture design decision documentation to support the decision making during core asset derivation. We demonstrate our approach using the case study of Autonomous Mobile Robot (AMR). The case study implementation shows showed that the proposed technique supports software engineer in the process of decision making at the architecture and detail design levels

Supporting the grow-and-prune model for evolving software product lines

207 p.Software Product Lines (SPLs) aim at supporting the development of a whole family of software products through a systematic reuse of shared assets. To this end, SPL development is separated into two interrelated processes: (1) domain engineering (DE), where the scope and variability of the system is defined and reusable core-assets are developed; and (2) application engineering (AE), where products are derived by selecting core assets and resolving variability. Evolution in SPLs is considered to be more challenging than in traditional systems, as both core-assets and products need to co-evolve. The so-called grow-and-prune model has proven great flexibility to incrementally evolve an SPL by letting the products grow, and later prune the product functionalities deemed useful by refactoring and merging them back to the reusable SPL core-asset base. This Thesis aims at supporting the grow-and-prune model as for initiating and enacting the pruning. Initiating the pruning requires SPL engineers to conduct customization analysis, i.e. analyzing how products have changed the core-assets. Customization analysis aims at identifying interesting product customizations to be ported to the core-asset base. However, existing tools do not fulfill engineers needs to conduct this practice. To address this issue, this Thesis elaborates on the SPL engineers' needs when conducting customization analysis, and proposes a data-warehouse approach to help SPL engineers on the analysis. Once the interesting customizations have been identified, the pruning needs to be enacted. This means that product code needs to be ported to the core-asset realm, while products are upgraded with newer functionalities and bug-fixes available in newer core-asset releases. Herein, synchronizing both parties through sync paths is required. However, the state of-the-art tools are not tailored to SPL sync paths, and this hinders synchronizing core-assets and products. To address this issue, this Thesis proposes to leverage existing Version Control Systems (i.e. git/Github) to provide sync operations as first-class construct

Haasteet ja muunneltavuus ohjelmistotuoteperheiden rakentamisessa: rautateiden sähköenergian selvitysjärjestelmä

According to European Union, all member countries shall have a settlement system in use by 2020. The settlement system shall receive energy consumption data from meters installed in trains, validate the data and allocate it for the right user. In this way, the energy consumption can be invoiced from the right user precisely. Erex is a such energy settlement system. The system needs to be adopted for each country to meet their different needs with regards to laws, systems and practices. This means that the system shall allow at least some flexibility. When new partners have entered the partnership and new instances have been created and modified for them with ad-hoc methods, the manageability of the systems has decreased. For this reason, a need to improve the management of the systems as whole has been raised. It would be easier, if the systems would have a shared core and systematically managed variability. This would mean creating a product family with systematically managed commonality and variability. The objective of this thesis was to study, what are the challenges of creating such product family, where all systems share the same principles but some degree of flexibility is allowed. To achieve these objectives, experts from partner countries and the administration and developers of the systems were interviewed. Thereafter, challenges related to product families and their variability were studied from the literature. Then, the challenges found in empirical and theoretical parts were compared. The objective was to see if the results of empirical study support the current literature. The comparison had three key results. Firstly, many of the current challenges are rather typical for software that is derived with ad-hoc methods. These challenges were found both in empirical and theoretical parts. Secondly, there were a group of challenges that were found only in the theoretical part and did not appear in the interviews but were considered as potential for this case. Thus, these challenges can be of great worth when the product family is developed. Lastly, there were challenges discovered only in the empirical part. These challenges are highly case and domain specific and were not investigated in the theoretical part due to their subjects. Experience from domain should be used to address these case specific challenges as they may not be found from any literature. There were only three challenges that could have been addressed in theoretical part by their subject. Compared to the whole amount of challenges found, these three challenges had only little role. Overall, this means that challenges found in the case are rather typical for product families. Thus, experience from the literature and industry can be used to solve these challenges