Model-Driven and Software Product Line Engineering - Model-Driven and Software Product Line Engineering - page 120

one that represents variants of architectural (software) design.
Thus, product designers are able to configure products by
creating feature configurations including choices of Smart-
Homes facilities and (software) architecture. These feature
configurationsareinputtotheproductderivationprocess.They
are used to select the transformation rules to be used in each
stage of the model transformation chain.
The facilities feature model. As we introduced in
section 2, we take into account the need to incorporate to the
house, automation facilities that are orthogonal to the house
structure. We consider particularly two groups of facilities:
access control facilities and environmental control facilities.
Figure 4.11 presents our Smart-Homes facilities feature
model. One FeatureGroup appears for each group of
facilities. The Lock Door Control feature groups the
features Fingerprint and Keypad and has cardinality
[0..1] , which implicitly means that Door elements can
have either keypad, fingerprint, or none of them as lock
door control mechanism. The Environmental Control
feature groups the features Air Conditioning and
Automatic Windows and also has cardinality [0..1] ,
which implicitly means that Room elements can have
either automatic windows, air conditioning, or none of
them as lock environmental control mechanism. We say
implicitly because there is neither semantics in traditional
feature models, nor in metamodels, to formally denote that
features represent variants that affect particular model
elements.
The architecture feature model. Figure 4.12 presents our
architecture feature model. Given that we have classified
software components according to their type, and their
instantiation mode, we create one FeatureGroup for each
classification. The Component Type feature groups the
features Periodic and Service and has cardinality [1..1] ,
which implicitly meansthat Component elementscanbeeither