Software product line engineering (SPLE) seeks to reduce time-to-market development as well as platform and mass customization of software-intensive systems. Under SPLE, the automation of product-specific architecture derivation is the major engineering activity. Therefore, a strategic prefabrication and reuse of shared properties among application-specific architecture models within product lines is targeted. The authors of this paper focus on an engineering approach to handling the construction of properties (domain requirements, interdependencies between building elements, quality, efficiency, and complexity) into product architectures--an ambiguous challenge.

The paper is intended for an audience familiar with the structural and operational properties of software architectures. It offers a systematic explanation of its topics, and applies a commonly known modeling technology. After an introduction to the intention and focus of the paper, section 2 covers the structuring and (cross) referencing of feature and architecture models. As the engineering approach, the derivation process is described explicitly in chapter 3. The paper concludes with a discussion of pros and cons, and with a delimitation referencing related work. As outlined in Figures 1 and 2, the methodological use of SPLE as a systematic transformation of feature and architecture models throughout the entire construction process (specialization by narrowing unions of metamodels) is well illustrated.

What is described in this paper, using appropriated language (morphemes, semi-formal models, and program fragments), is a very debatable approach. First, it is based on abstracted experience-based knowledge gained from several massive, software-intensive construction projects within specific product lines (field studies). Second, it ignores gained, substantiated knowledge of architecture-based software product line development. The latter issue becomes obvious from the description of the configuration of software-intensive systems, deriving specialized application architecture models and (artificially) separating domain engineering from domain architecture. Furthermore, in architecture-based software development (as common to all engineering disciplines), the systematic derivation of specialized application architecture models is achieved from abstracted equivalent models (classes of building block elements, such as components, connectors, and systems). This results in an enrichment of application semantics along the derivation hierarchy, and marks a fundamental discrepancy in engineering and architecture theory: while metamodels are unions of all possible application architecture models, their derived product-specific architecture models are a selection of copied properties only. Furthermore, the lack of substantiated configuration operation as well as managing metadata is obvious.

Thus, the explained approach is not a strategic, systematic, or engineering approach. To my knowledge, there is no substantiated number of successfully implemented software-intensive projects available that apply the SPLE methodology in such a way. The proof as well as the substance of practical efficiency and applicability (namely, performance of construction) are major pitfalls of the paper and its engineering efforts.