Skip to content

Commit 6356d33

Browse files
committed
site: finish variability document
1 parent e1f660f commit 6356d33

File tree

2 files changed

+28
-28
lines changed

2 files changed

+28
-28
lines changed

docs/mde_and_variability_modeling.org

+26-27
Original file line numberDiff line numberDiff line change
@@ -300,23 +300,23 @@ the literature, even in the context of feature modeling. Nonetheless, since
300300
features provide an adequate level of granularity for our needs, we need not
301301
concern ourselves with Pohl /et al./'s criticism. We do, however, require a
302302
clearer pictured of the relationship between feature models and the kinds of
303-
models that are typically found within acrshort:mde.
303+
models that are typically found within [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]].
304304

305305
* Integrating Feature Modeling with MDE
306306
:properties:
307307
:id: 7D780B3E-2821-2674-8F4B-AE29097B739D
308308
:custom_id: ID-7D780B3E-2821-2674-8F4B-AE29097B739D
309309
:end:
310310

311-
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]
320320

321321
Therefore, the availability of concise and interlinked representations of
322322
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,
339339
is described using creative construction DSLs, whereas non-structural
340340
variability can be described using configuration languages." We name these two
341341
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
344344
models for products, with the final aim being to "[...] use a configuration
345345
model to define variants of a structural model." According to them, these
346346
variants can be generated in two ways:
@@ -386,9 +386,9 @@ UML via a UML Profile, as suggested by Clauß's early work
386386
and variants. Ziadi /et al./ [cite:@ziadi2003towards] build on from this idea,
387387
expanding the focus to product line concepts. More recently, in
388388
[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
392392

393393
Others have looked elsewhere. In [cite:@czarnecki2005mapping], Czarnecki and
394394
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
398398
be thought of as a superset of all possible models, containing model elements
399399
that are associated with features by means of /presence conditions/. Model
400400
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
402402
expressed in the target notation." The approach is reminiscent of Groher and
403403
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
405405
the evaluation of presence conditions.
406406

407407
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
426426
to extend their tools to support superimposed variants is not feasible due to
427427
the engineering effort required.
428428

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."
439438

440439
For their part, Greifenberg /et al./ [cite:@greifenberg2016modeling] reflected
441440
on the role of code generators within [[id:76DC5C70-AAC0-86A4-3EEB-4187367002BA][SPLE]] --- particularly those that are

docs/models_and_transformations.org

+2-1
Original file line numberDiff line numberDiff line change
@@ -199,6 +199,7 @@ dimensions:
199199
:properties:
200200
:id: 8E393033-45DD-B9C4-1903-D99CB54BBBD1
201201
:custom_id: ID-8E393033-45DD-B9C4-1903-D99CB54BBBD1
202+
:roam_aliases: metamodel
202203
:end:
203204

204205
Given these concepts, we can now elaborate further on Bezivin's definition
@@ -343,7 +344,7 @@ operations performed on models have become key to the modeling approach.
343344
:properties:
344345
:id: 707BD590-1E59-56B4-D333-33525E43A78A
345346
:custom_id: ID-707BD590-1E59-56B4-D333-33525E43A78A
346-
:roam_aliases: MT
347+
:roam_aliases: MT transform
347348
:end:
348349

349350
The second most significant component of [[id:C29C6088-B396-A404-9183-09FE5AD2D105][MDE]] , after models, are Model

0 commit comments

Comments
 (0)