Software Product Line Engineering Basics - Model-Driven and Software Product Line Engineering - page 35

organizations, and interactions of the products in the
product line.
Itsroleistocollect,inonesingleartifact,theoverallcommon
and variable knowledge related to the functionality of the
products. It can also express the structural organization,
qualities, and the connections between the different
components of the products. It is architecture, and as
such, can be specified in various ways ranging from
formal architectural languages to light weight notations
and natural languages. One of the main notations is UML
with additional stereotypes or constructions such as the
UML merging operator. MDE in this context is also used
and several metamodels exist [GOM 04, RAS 11]. The
reference architecture should represent the product line
scope; validation or evaluation has to be performed to ensure
this representation. Another aspect is that, like all other
re-usable artifacts, the reference architecture can be subject
to evolution.
2.5.1. Component-based software engineering
One important idea to improve re-usability, which dates
back to the McIlroy paper [McI 68], is software components.
One can say that component-based software engineering
(CBSE) is the root of domain engineering. This principle
is extensively exploited in software product lines to define
applications by assembling assets. This is suitable in all the
development steps where new assets are preferably built from
existing assets, and this is also true for final products. To
take into account variability, new assets and new links can be
added, removed, or changed in a given configuration. Various
models of components and composition are of interest; for
instance, template, module, software component, architectural
description language [MED 00], model and weaving [JÉZ 08],
or aspect oriented programming [KIC 97]. As an example,
one of the first experiments of software product lines was