You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The crux of the problem is then on how to integrate ACRshortpl:mde modeling
312
-
techniques with variability management --- or, more specifically for our
313
-
purposes, with feature modeling. Clearly, having a feature model simply as a
314
-
stand-alone artefact, entirely disconnected from the remaining engineering
315
-
activities is just a form of acrshort:mbe, as Czarnecki and Antkiewicz explain
316
-
(/emphasis ours/): "Although a feature model can represent commonalities and
317
-
variabilities in a very concise taxonomic form, /features in a feature model are
318
-
merely symbols/. Mapping features to other models, such as behavioral or data
319
-
specifications, gives them semantics." [cite:@czarnecki2005mapping]
311
+
The crux of the problem is then on how to integrate [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] modeling techniques with
312
+
variability management --- or, more specifically for our purposes, with [[id:76DC5C70-AAC0-86A4-3EEB-4187367002BA][feature
313
+
modeling]]. Clearly, having a feature model simply as a stand-alone artefact,
314
+
entirely disconnected from the remaining engineering activities is just a form
315
+
of [[id:79EC741E-8818-3494-8B1B-2B27C182B160][MBE]], as Czarnecki and Antkiewicz explain (/emphasis ours/): "Although a
316
+
feature model can represent commonalities and variabilities in a very concise
317
+
taxonomic form, /features in a feature model are merely symbols/. Mapping
318
+
features to other models, such as behavioral or data specifications, gives them
319
+
semantics." [cite:@czarnecki2005mapping]
320
320
321
321
Therefore, the availability of concise and interlinked representations of
322
322
variability across models is a prerequisite to attain this semantically rich
@@ -339,8 +339,8 @@ of variability found in models and proposed dividing it into two kinds,
339
339
is described using creative construction DSLs, whereas non-structural
340
340
variability can be described using configuration languages." We name these two
341
341
kinds /input variability/ since they reflect variation within the input models.
342
-
In their view, the feature model becomes a metamodel for the product
343
-
line[fn:feature_model_as_meta_model], and their instances are the configuration
342
+
In their view, the feature model becomes a [[id:8E393033-45DD-B9C4-1903-D99CB54BBBD1][metamodel]] for the [[id:C1172AEA-F94B-73D4-FDAB-A105D7FEA389][product
343
+
line]][fn:feature_model_as_meta_model], and their instances are the configuration
344
344
models for products, with the final aim being to "[...] use a configuration
345
345
model to define variants of a structural model." According to them, these
346
346
variants can be generated in two ways:
@@ -386,9 +386,9 @@ UML via a UML Profile, as suggested by Clauß's early work
386
386
and variants. Ziadi /et al./ [cite:@ziadi2003towards] build on from this idea,
387
387
expanding the focus to product line concepts. More recently, in
388
388
[cite:@possompes2010uml] [cite:@possompes2011design], Thibaut /et al./ created a
389
-
UML Profile for feature modeling concepts. Extending acrshort:uml is
390
-
advantageous due to its universal nature, but alas, it also inherits all of the
391
-
challenges associated with the modeling suite.
389
+
UML Profile for feature modeling concepts. Extending UML is advantageous due to
390
+
its universal nature, but alas, it also inherits all of the challenges
391
+
associated with the modeling suite. FIXME link to adoption
392
392
393
393
Others have looked elsewhere. In [cite:@czarnecki2005mapping], Czarnecki and
394
394
Antkiewicz propose a template-based approach to map feature models to different
@@ -398,10 +398,10 @@ family/. The model template is written in the [[id:1D15099E-7294-6724-3343-A6C71
398
398
be thought of as a superset of all possible models, containing model elements
399
399
that are associated with features by means of /presence conditions/. Model
400
400
templates can be instantiated given a feature configuration: "The instantiation
401
-
process is a model-to-model transformation with both the input and output
401
+
process is a [[id:707BD590-1E59-56B4-D333-33525E43A78A][model-to-model transformation]] with both the input and output
402
402
expressed in the target notation." The approach is reminiscent of Groher and
403
403
Völter's positive variability, in that the template provides the overall model
404
-
and [[id:707BD590-1E59-56B4-D333-33525E43A78A][MT]] are then responsible for pruning unwanted model elements on the basis of
404
+
and [[id:707BD590-1E59-56B4-D333-33525E43A78A][MTs]] are then responsible for pruning unwanted model elements on the basis of
405
405
the evaluation of presence conditions.
406
406
407
407
An interesting feature of superimposed variants are IPC (Implicit Presence
@@ -426,16 +426,15 @@ largely on the availability of good tooling. Asking individual [[id:C29C6088-B39
426
426
to extend their tools to support superimposed variants is not feasible due to
427
427
the engineering effort required.
428
428
429
-
As part of our review of the literature we also investigated the application of
430
-
variability management techniques to code generators. In
431
-
[cite:@roth2015towards], Roth and Rumpe motivate the need for the application of
432
-
product line engineering techniques to code generation. Their paper provides a
433
-
set of conceptual mechanisms to facilitate the product-lining of code
434
-
generators, and outlines a useful set of requirements: "The main requirements
435
-
for a code generator product line infrastructure are support for incremental
436
-
code generation, specification of code generator component interfaces, support
437
-
for validation of generated code, and support for individual semantics of a
438
-
composition operator."
429
+
The application of variability management techniques to code generators was also
430
+
investigated, as part of this literature review. In [cite:@roth2015towards],
431
+
Roth and Rumpe motivate the need for the application of [[id:C1172AEA-F94B-73D4-FDAB-A105D7FEA389][product line engineering]]
432
+
techniques to code generation. Their paper provides a set of conceptual
433
+
mechanisms to facilitate the product-lining of code generators, and outlines a
434
+
useful set of requirements: "The main requirements for a code generator product
435
+
line infrastructure are support for incremental code generation, specification
436
+
of code generator component interfaces, support for validation of generated
437
+
code, and support for individual semantics of a composition operator."
439
438
440
439
For their part, Greifenberg /et al./ [cite:@greifenberg2016modeling] reflected
441
440
on the role of code generators within [[id:76DC5C70-AAC0-86A4-3EEB-4187367002BA][SPLE]] --- particularly those that are
0 commit comments