A Second Comprehensive Application Example - Model-Driven and Software Product Line Engineering - page 193

product, the end-user has one format to export the data. Each
product will be configured to allow the choice of the exporting
format.
- GUI Variability. The product designer can select from
severalalternativeviewstopresentthedatainthe information
view. The first one is a simple view with labels and text fields
for each characteristic related to the domain concept managed
by the product. Instances are displayed one-by-one.The second
one uses a grid component. The grid component facilitates the
display of many instances of the problem space concept at the
same time.The third one uses a tree representation. Figure 7.1
presents the GUI of a collection manager system managing
information of students and using a tree information view.
7.3. The overall process
Accordingtoourapproach,weorganizethelifecyclecreation
of MD-SPLs in a framework, FieSta, which incorporates the
main principles of Model-Driven and SPL Engineering. There
aretwomajorprocessesonwhichourframeworkisfocused:one
is the process of capturing and expressing variability in MD-
SPLs,whichimpactsconsequentlyontheprocessofconfiguring
product line members, and the other is the process of deriving
products by re-using and composing model transformations
basedonproductconfigurations.Figure7.2presentsanactivity
diagram summarizing the processes involved in FieSta.
7.3.1. Domain engineering
During the domain engineering process, a product line
architect creates metamodels, feature models, and constraint
models to capture the variability and commonalities of
MD-SPLs. As we have presented, constraint models make it
possible for product line architects to capture and express the
valid fine-grained variations between product line members
by using the concepts of constraint , cardinality property ,