The Product Line Architecture (PLA) can be improved by taking into account key factors such as feature modularization, and by continuously evaluating its design according to metrics. Search-Based Software Engineering (SBSE) principles can be used to support an informed-design of PLAs. However, existing search-based design works address only traditional software design not considering intrinsic Software Product Line aspects. This paper presents MOA4PLA, a search-based approach to support the PLA design. It gives a multi-objective treatment to the design problem based on specific PLA metrics. A metamodel to represent the PLA and a novel search operator to improve feature modularization are proposed. Results point out that the application of MOA4PLA leads to PLA designs with well modularized features, contributing to improve features reusability and extensibility. It raises a set of solutions with different design trade-offs that can be used to improve the PLA design.

Several projects have been discontinued in the history of the software industry due to the presence of software architecture problems. The identification of such problems in source code is often required in real project settings, but it is a time-consuming and challenging task. Some authors assume that architectural problems are reflected in source code through individual code anomalies. However, each architectural problem may be realized by multiple code anomalies, which are intertwined in several program elements. The relationships of these various code anomalies and their architecture problems' counterparts are hard to reveal and characterize. In fact, there is little knowledge about the manifestation of code-anomaly agglomerations in software projects and when they adversely impact (or not) the software architecture. To overcome this limitation, we propose studying the architecture impact of a wide range of code-anomaly agglomerations. An agglomeration is a group of code anomalies that are related to each other for some reason - e.g. all of them affect syntactically-related code elements in the program. In our study, we analyzed a total of 5418 code anomalies and 2229 agglomerations within 7 systems. We observed that architectural problems are much more often reflected as anomaly agglomerations rather than individual anomalies in the source code. More importantly, we also revealed when code-anomaly agglomerations were (or not) good indicators of architectural problems. For instance, the result of our study suggests that certain topologies of code-anomaly agglomerations are better indicators than others.

The modernization of monolithic legacy systems with microservices has been a trend in recent years. As part of this modernization, identifying microservice candidates starting from legacy code is challenging, as maintainers may consider many criteria simultaneously. Multi-objective search-based approaches represent a promising state-of-the-art solution to support this decision-making process. However, the rationale to adopt each microservice candidate automatically identified by these approaches is poorly investigated in industrial cases. Furthermore, studies with these approaches have not carefully investigated how maintainers reason and make decisions when designing microservice architectures from legacy systems. To address this gap, we conducted an on-site case study with maintainers of an industrial legacy system to investigate the usefulness of automatically generated microservice architectures. We analyze design decisions pointed out by the maintainers when reasoning about microservice candidates using several criteria at the same time. Our study is the first to assess a search-based approach involving actual maintainers conceiving microservice architectures in an industrial setting. Therefore, firstly, we considered individual evaluation of microservice candidates to understand the rationale for identifying a service. Secondly, we conducted a focus group study with maintainers with the goal of investigating design decisions at an architectural level. The results show that: (i) the automated approach is able to identify useful microservices; (ii) the criteria observed by previous studies are, in fact, considered by maintainers; and (iii) the maintainer profiles, i.e., the preferred granularity for microservice, highly affect design decisions. Finally, we observed the maintainers needed little effort in adjusting the automatically identified microservices to make them adoptable. In addition to indicating a promising potential of search-based approaches to generate microservice architectures, our findings highlight the need for: (i) interactive and/or customizable approaches that enable maintainers to include their preferences during the search process, and (ii) flexible or automated selection of criteria that fits the scenario in which the modernization is taking place.