Abstract Today, a considerable number of Architectural Languages (ALs) have been proposed for specifying and analyzing the architecture of software systems. Despite the popularity of different ALs, how ALs influence software system maintainability has not received much attention. One of the most important tasks in software maintenance is requirements traceability. Requirements traceability establishes links between requirements and other software artifacts, facilitating system maintenance. In this paper, we analyze the influence of ALs on requirements traceability. Taking into account the ALs used by the industry, we analyze how ALs influence traceability among requirements and architecture models. We conducted an evaluation with our industrial partner CAF. The results show significant differences in AL performance. We also analyze the results in terms of AL concepts, requirements model elements, and AL type in order to understand the performance differences. General‐Purpose/Research Languages achieve the best results for all of the performance indicators, providing a mean precision value of 0.51, a recall value of 0.38, a combined F‐measure of 0.40, and an Matthews Correlation Coefficient value of 0.33. Those ALs that influence engineers to use more generic and domain‐independent terms to specify their architectures obtain the best results during requirements traceability. Our results have the potential to help AL designers to improve their languages and also to help practitioners make a more informed decision about whether or not a given AL meets their traceability needs.

Model Fragment Location (MFL) aims at identifying model elements that are relevant to a requirement, feature, or bug. Many MFL approaches have been introduced in the last few years to address the identification of the model elements that correspond to a specific functionality. However, there is a lack of detail when the measurements about the search space (models) and the measurements about the solution to be found (model fragment) are reported. Generally, the only reported measure is the model size. In this paper, we propose using five measurements (size, volume, density, multiplicity, and dispersion) to report the location problems. These measurements are the result of analyzing 1,308 MFLs in a family of industrial models over the last four years. Using two MFL approaches, we emphasize the importance of these measurements in order to compare results. Our work not only proposes improving the reporting of the location problem, but it also provides real measurements of location problems that are useful to other researchers in the design of synthetic location problems.

Clone-and-Own (CAO) is a common practice in families of software products consisting of reusing code from methods in legacy products in new developments. In industrial scenarios, CAO consumes high amounts of time and effort without guaranteeing good results. We propose a novel approach, Computer Assisted CAO (CACAO), that given the natural language requirements of a new product, and the legacy products from that family, ranks the legacy methods in the family for each of the new product requirements according to their relevancy to the new development. We evaluated our approach in the industrial domain of train control software. Without CACAO, software engineers tasked with the development of a new product had to manually review a total of 2200 methods in the family. Results show that CACAO can reduce the number of methods to be reviewed, and guide software engineers towards the identification of relevant legacy methods to be reused in the new product.

The aim of domain engineering process is to define and realise the commonality and variability of a Software Product Line. In the context of a family of models, spotting the commonalities and differences may become cumbersome and error prone as the number of models and its complexity increases. This work presents an approach to automate the formalization of variability in a given family of models. As output, the variability is made explicit in terms of Common Variability Language. The model commonalities and differences are specified as placements over a base model and replacements in a model library. The resulting Software Product Line (SPL) enables the derivation of new product models by reusing the extracted model fragments. Furthermore, the SPL can be evolved by the creation of new models, which are in turn automatically decomposed as model fragments of the SPL. The approach has been validated with our industrial partner (BSH), an induction hobs company. Finally, we present five different evolution scenarios encountered during the validation.